It’s all about change, is that where we start?

Of all the boundaries between silos none is more critical than that between Development and Operations. “It’s raining changes” one service manager told me. Another said “We’re lucky if 50% of the changes go through release control, to be honest we don’t really know how many bypass the process.” When your release management processes are this immature finding the place to begin is as daunting as the task itself.

So a good place to start is to extend the code repository into the DevOps area by using a Release Vault. As the developers promote code through their test areas we can add DevOps test areas, pre-production staging areas and production itself. Using modern, release centric repositories to manage the code promotions reduces, error, effort and risk and adds audit trails, access control and notifications. The best in class tools provide blackout capabilities too.

If developers use more than one repository insist that their last step is to check the final version into the Release Vault. This way DevOps controls the code through testing and deployment and avoids those little “surprises” that often come late in the process.

A common ticketing tools is a must. All tasks for all teams that directly interact with DevOps must be on the same system. It is critical for effective collaboration that items can be passed back and forth quickly in order to ensure completeness and accuracy of the tasks. Common reporting, alerts and approval mechanisms mean nothing gets missed. It is time to consolidate multiple ticketing systems into one.

Test automation tools make regression testing possible and practical. If your release process allows for late delivery of new code and fixes right up to go-live it is essential to regression test those code deliveries. By investing in extensive automated test code coverage for your application you can test the entire battery against each delivery. This increases confidence in the release and reduces overall risk.

We should also look to automating the production build and deployments too. By reusing the scripts the developers use we can ensure that low-touch, even no-touch, deployments are possible. Keeping the development environment in sync with production environment helps reduce the customization needed each time the script is employed to move code from Dev to Test, from SIT to UAT, from staging to production.

And if you are in a place where Agile development is taking place you should look at matching their cadence in your own Agile DevOps team. Look at the releases coming as  a chance to fast track code to production, have daily standup meetings with your Agile release team, track the activities against the plan and monitor completeness against the glide slope and use automation to track all the activities.

Now, if only we could get some of the DevOps disciplines merged into the ALM tools.