devopsy.kinsta.cloud

Tag: change management

  • How Change Management Serves the Developer

    How Change Management Serves the Developer

    Change management first comes to mind as a means to keep errant, untested, unapproved code from entering production. But did you know that what is good for IT operations is good for developers, too?

    Developers appreciate change management. They enjoy the change management benefits of Linus Torvald’s popular Git version control system http://git-scm.com/, which maintains successive versions of the code in question, and spawned GitHub https://github.com/ where developers share and network with their community. Perforce is another version management tool http://www.perforce.com/.

    But what are the benefits to developers from change management as taken in the former sense? How does the same change management that protects the production environment help the coder?

    Lightening Developer Workload

    Change management saves developers a lot of work. Developers benefit by focusing on the work that stakeholders agreed on when discussing and scoping the project. These are the tasks that come from their lead developer, who receives it through proper channels.

    When developers do this instead of accepting countless requests from managers for adds / changes that fall outside the scope of the project that leadership agreed on, they save themselves from potentially repeating their work to replace those unauthorized changes with the coding implementations that the team leader originally tasked them with. Developers save themselves and the customer many headaches by completing planned, authorized project items rather than the requests that undermine the corporate vision.

    “Change that is not properly managed is destabilizing. Unapproved changes send ripples through every aspect of project task assignments. The ultimate outcomes are unpredictable,” says Steve McConnell, the oft-quoted author of “Code Complete” (Microsoft Press). And by the time upper-management hears of the scope creep and project dilution, the damage is far reaching.

    Yet, even stakeholders who felt they clearly communicated what they needed will come back at a project landmark or at mid-project to say that they require some feature that the development team is not addressing. This creates scope creep and additional person-hours that are out of the development team member’s hands. Clearly, developers see enough challenges such as this without managers visiting the developer’s cubicle once the project is in full swing, seeking adjustments for their users.

    “But this duality is a specific phenomenon that I and the industry have seen. There is the official workload and then there is the unofficial plan and workload consisting of favors garnered from individual developers, which undermines the project manager, creating work that causes work to go on with the PM unaware,” says McConnell. Following change management protocols and project structure is necessary so the right hand (PM) knows what the left hand (developer) is doing.

    Avoiding the Crossfire

    “Developers get caught in the crossfire between unofficial requests and change management. The proper chain of command funnels down blame to the developer when their task X is not done. Yet that only happened because the VP of Sales came directly to the developer, saying he needed another feature,” says McConnell. Because the developer saw the VP as his superior, he felt he couldn’t say no. Suddenly, the developer has several bosses. As a result, development staff don’t get project tasks out on time. “This leads to prioritization of work that does not reflect the priorities of the organization,” says McConnell.

    When a developer remains firm, however, sending the VP to the project manager or development team leader with any new requests, that can limit some of the crossfire.

    The Joy of Completed Work

    Another benefit to the developer in following change management protocols is the satisfaction of finished work, which is possible when they are not constantly changing direction. “Developers have a high desire to complete work successfully,” says McConnell. To not have to frequently change focus and to rather get work done day-to-day and week-to-week is very fulfilling for developers. “The Holy Grail for developers is to receive clear direction throughout the course of the project,” says McConnell. Developers like their work to move in a straight line. It is frustrating to change focus so often.

    Developers are most motivated by the work itself. They are task-oriented people who enjoy the relief that comes with task completion. If the work is constantly redefined, that can be demotivating for them.

    Coming Full Circle

    “There are benefits to the developer from change management including improvements in productivity and morale. But the largest benefits accrue to the business. Change management gets things done by investing more time in moving in the right direction,” says McConnell.

  • Change your thinking about Change Management

    Change your thinking about Change Management

    Change Management, let’s face it, it’s usually a checklist item and a CYA tool. But in the world of DevOps where change is part of the culture and processes.  Change Management needs to be more than a cost center, and really a way to improve what you are doing. And there is no excuse not to.

    (more…)

  • Hacking Your Auditor

    Hacking Your Auditor

    No, not that kind of hacking, give me a little credit…

    Recently I was having a conversation with a consulting friend about DevOps, and he found himself in a bit of a tough situation. The organization he was working with was a pure cloud/DevOps shop, but one that was stepping into having the meet compliance obligations. Needless to say, things weren’t going well with the auditor.

    For those of you who haven’t had to deal with the miasma of audits, one of the strongest requirements, for nearly any regulation/contract/agreement, is strong change management. This is especially true after those Enron guys screwed everything up for the rest of us.

    Change management makes a ton of sense from both an operational and compliance standpoint. I, myself, have blown things up in production but not being smart about my change management. For compliance, it is absolutely essential. If you are dealing with anything with financial or privacy implications, you sure as heck want to get it into a stable, secure, compliant state and ensure that state is kept over time.

    There is a big misconception out there that DevOps-style organizations don’t have change management. That when you push multiple changes per developer per day into production, there is no accountability or control. Now, while you can certainly build things this way, that sure isn’t how I see successful teams doing it. Not even close.

    The problem isn’t that DevOps necessarily skips change management, it’s that it looks different. Much of change management becomes automated, and the fundamental nature of changes themselves is different. But think about how you describe DevOps to your traditional IT-focused friends. Now imagine trying to explain this to an auditor working off set standards that are still figuring out if cloud includes a co-hosted Mac Mini duct taped to a rack.

    Here are some tips on how to both adjust your process, and explain it to the auditors:

    • First, figure out which pieces of your application and operations are in-scope for the regulation. Odds are only financial and privacy related bits are, and you can then apply more-granular controls or logging to these if you need.
    • Make sure your continuous integration tool (if you have one) includes some security checks and logs all updates/changes. If you push right from your code repository to production, get a CI tool.
    • Keep records of all changes as they flow from dev to test to prod (or whatever you use). Again, this should be trivial to automate and dump the records to a secure log repository someplace.
    • Unless your cloud provider tracks all API calls (like CloudTrail does on AWS, although that only works for some services and regions) use an API or web UI proxy like Netflix’s Asgaard. This really is a good security practice anyway, and can actually speed up infrastructure and platform management processes anyway. Keep the logs from this to make the auditor happy.
    • If you SSH into instances, you need to log that activity and dump the logs to a central repository.
    • Make sure you keep revisions of both all code changes and infrastructure automation changes (e.g. your CloudFormation templates, Chef/Puppet scripts/etc.). This is often built-in, but make sure you configure it correctly.
    • Those suggestions now give you logs of all application changes, infrastructure changes, and direct access to instances. These are the things the auditor wants to know exist.
    • Filter them based on your in-scope compliance requirements. Such as payment systems components only.
    • Explain to your auditor that all changes go through an automated approval system that checks the code, tests it (detail the tests), tracks the change, and then moves it into production. That all server logins and infrastructure changes are logged, as is the complete history of the structure of your entire environment. And that you can provide all the documentation, filtered for the pieces within compliance scope.

    This might look like a lot, but odds are very high you are already doing most of this. You keep code revisions, run changes through test suites before they go into production, and track all infrastructure changes. You might not have your own Ops portal/proxy, but you really should for a lot of reasons that have nothing to do with compliance.

    The trick is explaining this to your auditor in their terms. They expect manual checks and records. You need to show them that you still have these checks and balances, but they are automated. You still might need to add some pieces, such as an alert if certain parts of your code are changed (e.g. the file with payment processing or account reconciliation), but these will hopefully be minimal.

    A good DevOps environment actually has a much better compliance infrastructure in place than traditional infrastructure. The automation and template-driven models give us much better control and insight as compared to manually fixing everything, even when we push more day to day changes. The trick is to document this, add a couple pieces if you need it, and then explain it all to someone with… less than refined technical skills.