As the precursor to DevOps, and therefore to continuous integration, delivery and deployment (CI/CD), Agile has a close relationship to these approaches. Understanding the philosophy behind Agile can help you get more out of CI/CD while implementing a CI/CD pipeline that puts Agile into practice.
Unfortunately, years of frameworks, strategies and consultants have obscured the core tenets of Agile and reduced it to a rigid set of rules. But without understanding the principles, it’s much harder to apply them effectively.
Above all else, Agile is a mindset – a way of thinking about the process of developing software.
Agile recognizes that the goal is to deliver working software and that embracing change and encouraging collaboration between individuals is a more effective way of getting there than rigidly following a plan for a contracted set of requirements.
The principles set out in the Agile manifesto expand on these values and offer techniques to enact them. These include building empowered and collaborative teams and delivering working software in frequent, iterative cycles, which allow the team to respond to change.
The rationale is simple: if you set requirements in stone at the outset and rigidly follow a plan to deliver them, you lose the flexibility to adapt what you’re building as you learn more and as your users’ context and needs evolve. The Agile approach is to have an end goal and work out the specifics of how to reach it incrementally.
These Agile principles informed the DevOps movement, which in turn gave rise to CI/CD methodologies.
Whereas the focus of Agile, at least in the early days, was on the workings of the development team, DevOps extended the remit to look at the downstream processes and the work involved to get from code being written to released.
DevOps emphasizes the importance of breaking down silos and collaborating across teams to achieve a common goal – getting working, useful software into users’ hands. Continuous integration, delivery and deployment are DevOps practices that aim to speed the software delivery without compromising on quality.
By automating as many steps in the process as possible, continuous integration environment provides rapid feedback to shorten the time it takes to release software to users.
Given Agile and DevOps’ history, it’s probably no surprise to learn that several of the elements involved in a build pipeline will also help you to work in an Agile way. For starters, the recommended CI practice of “committing early and often” encourages you to work in small batches.
Breaking features down into smaller pieces is essential for an iterative build and release process. As the aim is to ensure that any commit can progress through the CI/CD workflow and potentially be released, each commit should result in something that works. As such, adopting this approach helps you to remain focused on delivering working software.
Both Agile and DevOps emphasize the value of collaboration and communication. Although the initial focus of DevOps was on collaboration between development and operations, the benefits can extend much further.
By including staging environments in your build pipeline and providing visibility of what has changed in each build via dashboards, you can share progress with and solicit feedback from other parts of your organization, such as marketing, design, or security teams.
A central part of any CI/CD pipeline is the automated tests that deliver rapid feedback on code changes and provide confidence in build quality. Running automated tests on each commit is an important step in ensuring that you deliver working software.
The importance of releasing software to users frequently ranks high on the Agile agenda, and a CI/CD pipeline is a key enabler of that principle. Automating steps in the release process has allowed teams to speed up their releases significantly and deploy changes daily or even hourly – far more frequently than was envisaged when the manifesto was written.
Finally, the continuous feedback cycles that form the heart of the CI/CD pipeline and enable continuous improvement, both of the software being built and of the process that enables it, also reinforce the Agile principle that the team should regularly reflect on their process and adjust accordingly. Building in and listening to feedback loops will help establish the sustainable development pace advocated in the manifesto.
Although implementing a CI/CD pipeline can foster an agile mindset, it’s no more a silver bullet than the various Agile frameworks and solutions that have proliferated since Agile was first defined.
That said, some of the common anti-patterns in CI/CD methodologies can also serve as indicators that your organization is not as agile as you might like.
A frequent obstacle to both operating an effective build pipeline and adopting Agile principles for a continuous integration environment is the introduction of various manual stages to the release process. This can include changing advisory boards, or a requirement to supply detailed change notifications and risk assessments, before a new build can be deployed to production (or even to staging).
The intention behind these procedures is usually to ensure there is some oversight and control over releases. However, these significantly slow down the process and ignore the purpose of an automated testing regime, which should give you confidence in the build.
Demonstrating the robustness of the CI/CD pipeline using metrics can help alleviate concerns. Simultaneously, dashboards and automated notifications can cut down on a lot of manual work in keeping stakeholders apprised of changes coming through the pipeline.
Another common warning sign is the appearance of requests to slow down the process and batch up changes into less frequent releases.
While grouping changes into weekly or fortnightly updates is appropriate for some products, anything less frequent means you risk losing out on the benefit of seeing your changes in production and using that feedback to inform your next steps.
Communicating the rationale behind Agile continuous integration, DevOps and CI/CD practices and getting buy-in from all levels of your organization for this process will help to smooth the transition.
One of the underlying blockers to both CI/CD and Agile is a lack of trust, which results in teams not being empowered to do what’s needed. Requiring multiple levels of approval for decisions or changes will slow down the process and undermine the benefit of rapid feedback.
An empowered team requires team members to deliver working software and management to give teams the right tools and environment to enable them to do the job.
Agile is sometimes misrepresented as a fixed set of rules that must be applied in a specific way. By understanding the rationale and adapting the principles to your organization – while watching out for anti-patterns – you can promote an Agile continuous integration mindset.
Adopting CI/CD methodologies will help you put Agile values into practice and realize the benefits of iterative development cycles and frequent releases.