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 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.
A Brief History
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.
Breaking Down Walls
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.
Automation as a Cornerstone
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:
- Continuous Integration relies on a build process that is automatically performed whenever code is checked into the repository. There may be restrictions on this so it’s run at specific points and not necessarily with every single ‘git commit’.
- Continuous Testing is performed within development, QA, and staging environments as automated scripts. In dev this would be considered unit and integration testing; in QA it would cover functional, API, and other kinds of testing; and in staging there would be additional soak tests and load/performance scripts.
- Continuous Monitoring occurs in production, placing a watchful eye on performance and usage metrics to ensure no surprise issues.
- Continuous Delivery is the overarching principle covering the entire continual process – every process examined and the tools and scripts put in place for smooth, efficient, automated delivery with minimal manual intervention and maximum reliability and confidence.
- Continual Deployment is the more specific practice of actually releasing to production every new feature that made it through the pipeline, potentially even several times a day. Many teams choose to not include such frequent releases for purely business reasons.
A Few Additional Points
To successfully integrate a continuous testing, delivery, etc practice into your team, 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!