Continuous Deployment vs. Continuous Delivery - Which is Better?
They may have the same initials (CD), but continuous deployment and continuous delivery are not the same. Let’s look at what makes them different - and how to work out which one is right for your organization.
There are many different terms used in the world of cloud-native software delivery – and the lexicon seems to be growing all the time. From continuous integration to continuous delivery and continuous deployment, they can certainly be confusing to novices – and in some cases, to experts too. In this article, we go back to basics and explain what is commonly meant by some of the most frequently used terms.
In the cloud-native era, software delivery is achieved via pipelines – processes via which teams write, build and deploy code, with varying degrees of automation. These pipelines are often described as CI/CD pipelines – yet even the meaning of that acronym is open to debate. While there is no argument about the fact that CI stands for continuous integration (which we’ll explain next), some will tell you that CD stands for continuous delivery and others will say continuous deployment (it turns out the differences between the two are as subtle as they are important – but more on that below). Even when we agree on the terminology, there are disagreements about whether a particular pipeline or set of processes really qualifies as one or the other.
But before we delve into the nuances, let’s take a quick look at continuous integration (CI).
What exactly is continuous integration?
Continuous integration is the process of merging code changes back into the main branch very often, by automating builds of the code that has been written or updated. The more developers there are working on a particular code base, the more you stand to gain from automating some or all of this process.
To understand the benefits of continuous integration, it helps to understand how software development was conducted before the cloud-native age, when there was less pressure to deliver software updates at speed. The process was slower, more manual, and, arguably, more considered – a paradigm inherited from the days of packaged software when teams were given time to ensure that everything was right before shipping.
Cut to the cloud age and things are very different: software is distributed, users are remote and, crucially, applications are expected to be online 24/7/365. Not only are updates and improvements issued more frequently, but there is less time to manually test and perfect each one. Continuous integration (CI) was developed in answer to these pressures. It introduced the idea of a software pipeline, made possible by automated tests.
So instead of developers writing their code and building it on their individual machines, prior to a process of manual testing before merging with the main application, the code went into a pipeline, where it would be built and tested automatically, prior to merging – or integrating – with the main code base. This, in turn, made it possible to integrate these updates much more frequently – often several times per day – rather than wait until just before an arbitrary ship date to merge them all at once.
What is continuous delivery?
So CI introduced the idea of automated pipelines. But it concerned itself only with building and testing of code updates, usually culminating in a notification of test success or failure being sent back to the developer. It still stopped short of automating delivery itself.
Continuous delivery can be considered the logical next step. Instead of concluding things with a notification to the developer, the automated process continues, deploying the update automatically (if it passes its build tests). Naturally, there is a risk in applying this kind of automation to a production environment, in that the update could then fail in a live setting. So continuous delivery usually involves deployment to a staging environment, where the updates can be tested in an environment that is theoretically identical to production. Deployment into production remains a manual process – you and your team retain the power to decide when and how frequently to do this. Nevertheless, you can fairly claim at this point to have a functioning CI/CD pipeline (the ‘D’ in this context stands for delivery).
So what’s the difference between continuous delivery and continuous deployment?
So you’re doing CI/CD. But what’s the difference between that CI/CD and the other CI/CD – the one that includes continuous deployment?
In continuous deployment, automation goes yet another step further. Instead of taking you to the point where you can manually decide when to deploy your updates to production, it automates that part too.
Naturally, this necessitates further automated testing, to prevent buggy code that nevertheless passed its build tests from being deployed in production, where it could potentially do real damage.
Automating software delivery with GitOps
One way you can achieve this level of CI/CD is to adopt the GitOps model. GitOps allows you to introduce automation at every stage of the pipeline, using whatever tools you feel familiar with. But it also does more than simply automating the shift of code from one stage of the pipeline to the next. By centralizing not just the application code but also all the information regarding deployment in Git, and using a reconciliation agent (Weave GitOps, Flux) to continuously monitor the production environment for any digression from the configuration described in Git, your pipeline can effectively test new code at build, at deployment into staging, at deployment into production and continuously from then on.
Digression from the ‘single source of truth’ stored in Git prompts alerts to your platform team, who can then take remedial action – and that’s where things get even more impressive. Because all the code and all the instructions as to how it should be deployed are stored in Git, rollbacks can be performed in seconds or minutes, ensuring that your application’s users are not inconvenienced. GitOps is certainly not the only way to achieve true CI/CD, but in the cloud-native age, there is no more effective way to ensure that uptime is maximized.
Figure: GitOps - A Git-centric framework for continuous deployment
You can learn more about automating your CI/CD pipeline with GitOps here
Continuous delivery and deployment with Weave GitOps
Weave GitOpsis a packaged GitOps solution from Weaveworks, pioneers of the model and creators of the term ‘GitOps’ itself. Powered by the CNCF project Flux, it allows you to set up a software pipeline or bring an existing pipeline under GitOps control, in order to deliver new software features and updates much faster, without compromising on compliance, security or stability.
One of the easiest ways to try GitOps, Weave GitOps offers a range of benefits, including:
-
Improved security, thanks to the elimination of manual kubectl commands for applying updates.
-
Reduced configuration drift, because the production cluster is always monitored against your application’s desired state in Git.
-
Increased consistency and standardization, with consistent, end-to-end workflows.
Weave GitOps is open source, allowing you to explore the potential of GitOps without licensing or support fees. Weave GitOps Enterprise adds commercial support and additional features for organizations planning to use GitOps at scale.
Learn more about the two versions of Weave GitOps here.
Find out more about the easiest and most cost-effective way to manage your CI/CD pipeline. For a live demo and to discuss how GitOps could transform the way that your organization delivers software, contact a member of our team today.
Contact us nowWhitepaper: How GitOps Enables A Continuous Application Lifecycle
Discover what you need to start building a GitOps pipeline today.
