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.
Software automation calls for SecOps unicorns
Where software testers fit in with DevOps
Related Q&A from Kevin Parker
Add controls to the business of delivering software, and teams will scream about delays. However, fast development is often the result. Continue Reading
Kevin Parker discusses the pros and cons of industry analyst reports and advises when it might be best to trust your own instincts. Continue Reading
Actually, application development veteran Kevin Parker says ALM is really a part of the APM process when you look at it from a distance. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.