This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
4. - Testing in the DevOps environment: Read more in this section
Explore other sections in this guide:
What ALM tools and test automation tools are useful in a DevOps environment?
Of all the boundaries between silos, none are 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 tool 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, 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.