Let us look together at the concepts of Continuous Integration, Delivery and Deployment, which are fundamental to doing DevOps, SRE or Agile work.
Producing applications today is not a one-size-fits-all process. Recent years have seen the emergence of different approaches and working methodologies that can make a difference, transforming traditional manual processes to improve not only time-to-market, but also team collaboration and overall product quality.
What is the difference between Continuous Integration, Delivery and Deployment?
In order to untangle the choice of strategies and tools, however, it is necessary to understand what the terms Continuous Integration, Continuous Delivery and Continuous Deployment refer to, defining their boundaries and the differences between them. The application of these concepts to business work pipelines, in fact, is crucial for working in DevOps, Agile or for an effective SRE (Site Reliability Engineering) approach, as they introduce the necessary automation steps to adopt these modern working methodologies.
Before we get into it, do you want to read more about CI/CD and DevOps? Here are a couple of useful resources:
What is meant by Continuous Integration?
Continuous Integration (CI) refers to a software development practice in which all developers make code changes by committing them to a centralised and shared repository such as, for example, Git. Each change (commit or pull request) triggers an automatic build and test procedure that provides immediate feedback to the developer on its implementation.
In this way, developers can integrate small portions of finished code into the application without having to wait for integration at the end of the project. This is precisely what the name refers to, the possibility of fast and frequent integrations thanks to fast and effective problem detection.
If brought in-house, as with any change, this practice requires effort, especially initially. In particular, the team will have to write automated tests for each new feature, bug fix or enhancement, and it will be necessary to provide itself with a Continuous Integration tool capable of monitoring the repository and automatically initiating tests with each commit pushed to the repository. Moreover, for the approach to become truly efficient, there must be a high frequency of commits to the repository: without this requirement, the desired results will not really be achieved.
This effort, however, is repaid by taking into account the benefits that Continuous Integration can bring: the presence of a CI server drastically reduces the costs of the testing phase and leaves teams free to use their time to focus on product quality.
Furthermore, the automation of the testing process is the first stage of QA (Quality Assurance) automation and significantly reduces the number of bugs reaching the production stage by catching them early.
What is Continuous Delivery?
Continuous Delivery (CD) is the next step after CI, a software engineering approach that favours production in short cycles that guarantee the possibility of releasing software reliably at any time.
Continuous Delivery, in fact, does not see the development, release, feedback and quality management phases as irretrievably separate, but as a continuous cycle applicable to each change that, as Continuous Integration dictates, will be small, receive instant feedback and be released often.
Continuous Delivery therefore prefers atomic (small) and less risky software changes, released continuously instead of waiting for a single simultaneous release. In short, if CI deals with automating the build process, Continuous Delivery automates the release of code that has already been tested in a staging environment, ready to be released in production: this is why it is important to have implemented CI before moving to Continuous Delivery.
What will you need to do Continuous Delivery, then?
As already mentioned, it is important to implement Continuous Integration processes and that your codebase is adequately tested. Furthermore, it is necessary that the release process is automated: the trigger will remain manual, but once started, the process should not require human intervention. Finally, to avoid customer problems in production, it would be a good idea for teams to make use of feature flags, a development technique that allows features to be activated and deactivated at runtime without having to release new code.
Thanks to this practice, releasing software will be much easier: releasing more often will eliminate the complexity of preparing large releases for days at a time, and customer feedback will be obtained much more often and quickly.
What is Continuous Deployment?
Continuous Deployment (CD) is the latest step towards full automation of development processes, going beyond Continuous Delivery by automatically releasing each change into production once it has passed all code testing stages.
This practice obviously relies heavily on the presence of quality test automation, since the only obstacle there might be to releasing code into production is a failed test. In this way, code can potentially be released into production even minutes after it has been written, taking all the manual delivery tasks off the developers' shoulders and allowing them to concentrate only on writing quality code.
To be able to reap the benefits that CD can bring to your company, as mentioned above, you will have to make sure that the testing suites are up to the task: always remember that the quality of the tests will depend on the quality of the released product.
It is also important to remember that in a Continuous Deployment context your documentation processes will have to be able to keep up with your release processes. Moreover, at this stage feature flags become necessary when significant changes to the application are released, so that the development team can better coordinate with other departments.
Once Continuous Deployment is integrated into your pipeline, however, you will be able to develop faster and release to production in a less risky manner; by releasing one small change at a time, in fact, it will be easier to remedy errors. Last but not least, this way of working will bring the customer a continuous flow of improvements and a product whose quality will increase day by day, without having to wait weeks or months for an update.
By this point in the article, you should be clear about the distinction between Continous Integration, Delivery and Deployment. If you are interested in a more concise definition, you might find the CNCF Glossary, a community project in which SparkFabrik participates, useful. But now let's move on, in the next section we talk about tools.
How to choose CI/CD tools?
The choice of tools depends on numerous variables, especially with regard to the Continuous Delivery phase. The choice of one tool rather than another will depend on the expertise the team has with the various tools, the special functions provided by each of them, the execution environment of the CI/CD processes and the deployment strategy to be implemented.
In general, it may be useful for teams to consider using CI/CD tools provided by different providers. Major public cloud providers offer CI/CD solutions, as do Atlassian Bamboo, GitLab, CircleCI and many others.
Let's look at some examples of the most popular open source tools for CI/CD:
- Argoflow: allows CI/CD pipelines to run natively on Kubernetes.
- Jenkins: the automation server that can be installed on-premise or in the cloud, designed to manage every CI aspect, thanks to its wide range of plug-ins.
- Tekton Pipelines: a CI/CD framework for Kubernetes platforms, which provides a standard Cloud Native experience for CI/CD with containers.
- GoCD: a CI/CD server focused on modelling and visualisation.
- Spinnaker: a Continuous Deployment platform for multi-cloud environments.
- Screwdriver: a build platform for Continuous Deployment.
- Concourse: a continuous open-source resource.
Apart from specific tools, it must be considered that other solutions, although not strictly CI/CD related, are often present in many CI/CD workflows, such as:
- strumenti DevOps;
- CD tools for Kubernetes (Argo CD, Flux, Argo);
- deployment control tools (Keptn, OpenKruise);
- configuration automation tool (Puppet, Ansible e Chef);
- container runtime(Docker);
- container orchestration tools (Kubernetes).
How to get from Continuous Integration to Continuous Deployment?
Introducing novelties in business working methods is never easy: the risk of subverting the working balance is always present, but with some shrewdness it is possible to modernise working approaches effectively.
We have previously talked about how to introduce DevOps culture in the company while avoiding friction, but how to apply the fundamentals of this working methodology?
The easiest way to introduce CI/CD pipelines in the company would, of course, be to start with a completely new project. Starting by automating the release of the alpha version of the application at a production stage, with no active users, and reinvigorating your test suite as you develop your application is in fact the easiest way to test the entire CI/CD pipeline.
In reality, however, it is likely that you will also have to apply CI/CD techniques to projects that are already underway: in this case, it is better not to rush. Implementing a complex system of automated tests right away that revolutionises the end-to-end process not only leaves no time for development teams to consolidate each phase before moving on to the next, but also risks finding other departments unprepared for a much faster release process, to the detriment of the product.
Ideally, you should start by automating the build and release processes in a staging environment, so that you can manage production releases manually and thus ensure that all teams are coordinated. Already at this step you can begin to see the benefits that Continuous Integration and Delivery can bring: automating the processes will allow the team to no longer have to stop periodically to coordinate a release, saving time that can be used to focus on product quality and, in view of the next step, increasingly refine the test suite.
The final step is to do Continuous Deployment, i.e. to automate even the last step of delivery by making it completely automatic. By doing so, you eliminate any manual steps taken by the DevOps team and can enjoy all the benefits that adopting these practices can bring, for your company and for the satisfaction of your customers.
Written bySparkFabrik Team
