Bill Dickenson, Independent Consultant, Strategy On The Web
As DevOps becomes increasingly mainstream, it is essential that expectations are met for each group involved in the process. Part 1 of this blog focused on what operations should expect from the developers in DevOps while this part (Part 2) will focus on what developers should expect from Operations. Managing both sides is essential to a successful flow.
To be successful, software must operate efficently on the target platform, handle exceptions without intervention, and be easily changed while remaining secure. It must deliver the functionality at the lowest cost possible. CISQ has evolved a set of quality characteristic measures that when combined with automated software tools, provide a way to make sure that the code delivered, delivers. To deliver on this, Operations must provide the right tools and the right processes to succeed.
Specifications for Continuous Release
DevOps dramatically increases the speed that application code is developed and moved into production and the first requirement is to design for speed. Specifications should be designed to be delivered in work “packets” that are smaller than typical waterfall design. CISQ research has shown that designing even long projects as a series of smaller fixed scope projects in the 1-3 month range dramatically improves stability and cost control. When staggered to allow continuous releases, the smaller packet design can make DevOps easier. As releases get “bigger” the corresponding risk management problems also get bigger. The success rate for the projects also increases with the reduced time frame.
Tools, Tools, Tools
As speed increases, there is no room for manual processes which are not only unpredictable but inefficient as well. One of the goals of streamlining the process is to deliver business value rapidly and that requires a better approach. The code delivery “pipeline” must be optimized to deliver an increasingly rapid flow.
- Software Quality: In the previous blog we discussed CISQ recommendation for software quality. These should be part of the developer’s toolkit. Select a tool that can look at the whole portfolio as many security violations are in the spaces between programs. While there are some worthy open source analysis tools, this is an area where getting the best tool not only reduces the risk but also makes the process smoother. While the open source tools are evolving rapidly, the business case will more that support high quality tools. The entire pipeline should start with quality objectives.
- Source Code Control/Packet Repository: One area where DevOps implementations report issues is in the software control process. Increasing the speed of development puts source code control at risk especially in legacy environments where the release cycle was measured in months. The faster “packet” design will stress the existing toolset. The Packet repository should hold the products of the entire process. Deployment tools become more important.
- Codified and Comprehensive Risk Management: Many DevOps implementations fail when an unusually large amount of risk is introduced rapidly. Data center operations are not typically application risk aware and there is usually no codified process beyond the dangerous High-Medium-Low scale. In addition to investing in a better risk management process, the approach must contemplate both application and infrastructure.
As the pace quickens, environments need to be defined and available at a far more aggressive pace. Cloud-based services shine at this but hybrid environments work also.
- Test environments: Testing will increase in volume as the more continuous flow drives repetitive testing. The process will drive considerably higher testing needs.
- Test Data Management: Unlike quarterly and even longer cycles, it becomes almost
impossible to manually manage test data. The “golden transaction” process where the data necessary to test is preloaded into the image, becomes increasingly critical. The test system images now need to include replicated environments that can be tested rapidly.
From Operations, Developers should expect specifications designed to be implemented more frequently, tools to support the process, and environments designed for application services. Both groups benefit from understanding each others’ needs.