What is CI/CD in DevOps?
Continuous integration, delivery and deployment (CI/CD from here on in) are DevOps practices. In other words, they are techniques that implement the DevOps ideals. If you’re unfamiliar with the term you may be wondering: what exactly is DevOps? And how does it relate to Agile software development? Understanding the wider context of how software development practices have evolved and the problems that Agile and DevOps try to address can help you get more out of your CI/CD process.
How Agile changed the game
Thanks to the digital revolution, software and IT have shifted from being a mere supporting function for many organizations (software publishers aside) to becoming an integral part of many business sectors.
Across a whole swathe of industries, from banking and finance to retail, and from government through to travel and entertainment, software development is becoming a core part of many organizations’ work. Products and services are accessed via and supported by apps and online services, while internal computer systems are essential to the smooth running of a business.
In 2001, as this trend was starting to pick up pace, a group of software developers drew up the Agile manifesto. It was their response to some of the problems they saw in the way that software was being developed at the time. The manifesto provides a set of values and principles for developing software and has given rise to various frameworks – Scrum being one of the most well-known – that put these into practice.
Agile recognizes that the focus should be on delivering working software and that people – communicating and collaborating effectively – are central to achieving that goal. Developed in response to the lengthy timescales of waterfall projects at the time, where software was typically delivered years after requirements had been locked in and by which time user needs and context may have changed significantly, the Agile approach is to welcome changing requirements.
Agile frameworks and methodologies center around working iteratively, delivering small chunks of working software regularly, collecting feedback and adapting in response to it. This was a significant departure from the waterfall approach of working in distinct linear phases of design, development, test and release.
Understanding DevOps
While development teams were changing the way they approached software development by adopting Agile principles, there tended to be little collaboration with teams further downstream in the process.
It wasn’t uncommon for operations teams – those responsible for managing infrastructure and handling deployment of software to live – to be working in a completely different way and effectively speaking a different language to the developers writing the code.
Even though the developers might be working more efficiently within their own team, once the build was handed over to operations to deploy to staging the process would often bottleneck. Missing dependencies, environment configuration issues, and bugs that couldn’t be replicated on developers’ local machines created endless back and forth between teams and disagreements over which side was responsible for fixing the problem.
Often that was combined with a waterfall release strategy; although changes were delivered incrementally by development, the subsequent steps continued to batch up changes into large, infrequent releases, thereby removing the opportunity for rapid feedback from users.
A cultural shift
Combining “development” and “operations”, the term “DevOps” stresses the need to integrate the activities of both teams in order to deliver working software efficiently. That said, the scope is not limited to just these functions; all those involved in the development and delivery of software need to align around the common goal of delivering working software to users.
Central to DevOps is creating a culture of shared responsibility, mutual trust and open communication. It’s not enough for development teams to check work off as done once it works on a local build. To deliver code that is ready for production, developers need visibility of the steps between them and release. That means breaking down silos and collaborating with quality assurance, security and infrastructure teams to understand their part in the process.
DevOps Tools and Automation
While closer cooperation between teams can be achieved with manual processes, it’s much more efficient to use tools to automate as much of the work as possible. Automating build, test and deployment steps allows the work to be done more quickly which in turn means that results from those stages are available much sooner. Automation is central to a DevOps approach because it enables the tight feedback loops that are essential to building quality in and eliminating waste.
Efficient processes
DevOps emerged at a time when Lean manufacturing principles were starting to be applied to software development. Lean focuses on eliminating waste by optimizing each stage in a process, building quality in and respecting people.
DevOps incorporates much of this thinking and seeks to make software development more efficient by optimizing the end-to-end process and providing feedback on what is being built as early as possible with tight feedback loops.
This involves doing the activities that were downstream of development earlier and addressing the issues raised by this work as soon as they are found – whether that’s failing tests, security vulnerabilities or build issues.
Because everyone shares responsibility for delivering software to users, the time-worn response of “it works on my machine” is not sufficient. With a DevOps approach, developers have far more visibility of how software is used and the challenges that arise, which means they are better placed to fix them.
Adopting DevOps extends the benefits of Agile beyond the development team. Adapting to the pace of work coming from developers and working in smaller chunks makes it easier to spot and isolate problems as there are fewer variables at play. Similarly, generating feedback promptly avoids wasting effort on testing and staging a build that will later be thrown away. In turn, that ensures the organization as a whole gets the full benefit of working in smaller increments.
Putting DevOps into practice
Building an automated CI/CD pipeline puts these DevOps ideals into practice.
The continuous integration practice of committing frequently encourages small batch sizes which can move through the pipeline quickly. An automated build and test system makes it possible to verify each change and provide feedback far more quickly than a manual process.
As a developer, getting rapid feedback on what you’ve just written is more efficient as you are less likely to have lost the context for the change – you can maintain what Lean refers to as “flow”. Frequent automated testing also helps to improve quality as catching and fixing bugs early avoids other code being built on top of them.
Automating deployment to pre-production servers makes the process consistent and reliable, providing opportunities to make more use of staging environments for testing and feedback. Deploying small changes to production regularly rather than batching them up into large, infrequent releases reduces the risk of something going wrong in live environments, as there are fewer variables to combine into unintended consequences.
If a bug does emerge, isolating and fixing it is quicker, thanks to the smaller batch size. Releasing updates incrementally means you’re delivering value to users regularly and you can use the feedback on those changes to inform what you build next, thus continuing to improve the product.
Conclusion
The aim of CI/CD and of DevOps more generally is to speed up the process of delivering valuable software to users without compromising on quality. DevOps principles overlap with and complement Agile and Lean ideas. By looking at the whole software development journey and optimizing each stage, you can deliver more quickly and therefore get feedback faster, enabling a cycle of continuous development and improvement.