For years the benefits of "Continuous Delivery" have been touted and with it the corresponding practice of DevOps has grown significantly, but as with many software development methodologies, a plethora of variations exist. Continuous Integration, Continuous Testing, and Continuous Monitoring round out the complete "Continuous Everything" picture, but what does all of this mean? Where do they all fit into the overall development picture of Continuous Delivery best practices and how does development, DevOps, and testing relate to these activities?
Let's make some sense of the Continuous Delivery movement and the various players involved.
Traditionally, developers would receive requirements from business analysts or product managers. More evolved or advanced teams might also have a group review with QA, dev, and others to clarify ambiguities and set expectations. The developers would go off and code, the QA engineers would build their plans, and when functionality became complete it would be pushed into QA for testing. As the sprint neared completion any story not on track would get pushed to the next sprint, a complete regression test would take place (with or without software testing automation), and with the thumbs-up signal from QA the release would go live and the next sprint commence. Operations would manage the production environment and associated troubles therein with performance, architecture, and updates.
The Continuous Delivery revolution naturally grew out of the need for fast, regular, reliable releases, which placed a strain on the traditional roles of the software development team - the silos that developers, QA, and operations naturally existed within became a barrier to efficiency. How could releases become both faster and more stable if operations blamed development for performance issues, QA was frustrated with operations for environment issues, and both operations and development thought QA was the release bottleneck? Clearly, the walls between the groups needed to come down and quality must be owned by everyone, from start to finish.
The evolution of rapid development and agile methodologies have stressed that automation be introduced into every previously manual step... from start to end of the software lifecycle. Unit testing that was 'best practice' before is required practice now. Automated builds are standard procedure and integration tests are no longer simply good ideas but are aligned with the build process to execute upon each successful build. If every previously manual step in the movement of code is now automated, what does that mean for the Continuous Delivery process?
The pieces of the continuous practice are not surprisingly quite sensible:
To successfully integrate a continuous testing, delivery, etc practice into your team and into your planning, it must be embraced by everyone on the tech side and supported by management. There can't be a separate DevOps group solely responsible for production issues or a QA tester for a missed bug... everyone owns the quality, from start to finish. This may necessitate a deep cultural shift.
As for automation, it is imperative this is in place for each transition from environment to environment, whether it's code or data or infrastructure. The tools and systems must be integrated for efficient setup, breakdown, and transfer. That's the only way that the CTO can step into the room and make the surprise announcement "we're releasing...TODAY" and folks don't scramble for the door. Quality has been baked into the process, and with a couple decisive actions the release is on its way into prod with confidence.
And finally, flexibility and change is still the key while these processes and tools mature. Even with each member of the team working together and automation easing the verification efforts, technology continues to evolve and issues are bound to arise. Embracing Continual Learning and Continual Change is still necessary in order to keep your releases on track and users happy!