Demystifying continuous integration versus continuous delivery versus continuous deployment
By using automation, it is possible to build more robust software and release it faster. Thanks to containers and orchestration platforms, it is also easier to build microservices that can be published with minimal impact on a larger system. These automation processes are generally known as CI/CD.
These processes are generally defined as three separate steps that compose a more extensive pipeline. These steps are continuous integration, continuous delivery, and continuous deployment.
The following diagram shows the various stages of CI/CD:
Figure 1.2 – Continuous integration / continuous delivery / continuous deployment
Let's take a look at each in more detail.
Continuous integration
The first step in the pipeline – CI – refers to continuous integration. This first automation process is typically meant for the developers and usually runs as part of the development environment.
In this step, the code is automatically analyzed to catch any issues that might come up before the application is released. Initially, this step mostly referred to running a series of unit tests, but it can now include many other processes. Those processes include (and are not limited to) the following:
- Installing dependencies: To validate all the code and check for potential vulnerabilities, the CI process would need to install all the project's dependencies.
- Auditing for security vulnerabilities: Once all the dependencies have been resolved, it is essential to check that each module from third-party vendors does not have security vulnerabilities. This process can be done automatically with various tools that match the current versions of those modules against a database of known security breaches.
- Code linting: Software developers tend to have their unique signatures. Think spaces versus tabs or single versus double-quotes. It is essential to have coding standards in a complex code base to increase code readability and reduce errors. Code linting will ensure the code that was written matches the defined standards for this application.
- Type checking: Many programming languages, such as JavaScript and PHP, are loosely typed. While the absence of typing can be a powerful feature of the language itself, it can also introduce hard-to-find bugs. To help find those bugs, some tools can be executed against source code to reveal potential flaws.
- Unit testing: To test out the business logic of the code, unit tests can be run on individual functions. The purpose of a unit test is only to validate the outcome of a single, standalone function. Those tests are generally quick and can be run against a large code base in a matter of seconds. Unit testing has been around since the 1960s but was popularized with the agile movement's rise in the early 2000s. Kent Beck, one of the fathers of the agile manifesto, was a prone supporter of writing tests before even writing code. This approach was known as test-driven development or TDD.
- Merging: Once all the code has been validated with the automated tools, the CI process can merge the code into a branch for a potential release to a staging environment.
The end goal of continuous integration is to automate and submit the code that an individual developer contributed to, to a shared repository. Once all the testing and code analysis has been performed, the code is trusted enough to be automatically merged. With automatic merges in place, the number of branches that need to be manually incorporated into the code base is smaller. This ultimately reduces the potential conflicts between various branches affecting the same code.
Continuous delivery
The CD component can be divided into two distinct steps. The first one, continuous delivery, refers to preparing an application to be delivered. It encapsulates all the steps required to prepare for application deployment. Those steps typically run for longer and are not necessarily executed every time there is a code change. Instead, they run automatically when some code is merged into a repository to prepare for the deployment. This could include doing the following:
- Integration testing: Once the business logic of each function has been tested, it's time to test that each component is working with the other as expected. This process, called integration testing, typically tests a real network response to see if the small units of software work as expected with an authentic response. Those tests usually run longer and are only performed for the components involved in the current development cycle.
- E2E testing: End-to-end testing (also known as E2E testing) tests all the user journeys in an application. These tests extend to the UI, all the way to the network responses from a backend. They take much longer to perform, but they can usually help find regression bugs by testing the application as a whole.
- Compile and build: When applications need to be compiled, such as mobile or native desktop applications, this needs to be done. The output would be an executable or package that can then be installed and tested out by a QA team or a customer to provide feedback.
- Package and containerize: With some applications, it makes sense to prepare a container for distribution. Building this container and pushing the resulting image to a registry would be done at this phase.
Ultimately, the result of the continuous delivery phase is to provide the team or the customers with a version that can be tried and tested quickly. Continuous delivery was created in response to slower application delivery, which used to rely on manual processes. With faster delivery comes faster feedback, which is the goal of agile methodologies.
Continuous deployment
Finally, it is possible to automate the whole process even more. Now that the application has been packaged and ready for release in the continuous delivery phase, why not go one step further and automate deploying into production automatically?
Depending on the definitions, continuous deployment will often be part of the continuous delivery stage, but some people prefer to split those two to emphasize the amount of automation that can happen.
The deployment can take multiple forms and can be further automated using blue/green deployment methods, as an example.
CI/CD in the real world
Most software engineering teams will use some automation processes to help with their application delivery, usually referred to as CI/CD. The amount of automation they use can vary greatly. Some enterprises will only automate processes in the development environment. In contrast, others will automate the whole process and deploy to production as soon as a change has been pushed to a repository. The series of steps that are performed as part of that CI/CD process is called the pipeline.
In this book, you will learn how to build some of those pipelines using Tekton to automate your own processes. These examples will provide you with some simple to understand concepts, and will also help you eventually migrate to more practical examples that can be used in your regular responsibilities as a software developer.
