ITIDO

Typically, CI/CD refers to Continuous Integration and Continuous Delivery in the software development life cycle (SDLC), however, the “CD” can also stand for Continuous Deployment. The purpose of Continuous Delivery is to make it easy to deploy new code. The purpose of Continuous Deployment is to allow teams to be hands-off in the process by automating the deployment stage. As you can already tell, both Continuous Delivery and Continuous Deployment refer to the automation of different stages of the CI/CD pipeline, however, Continuous Deployment goes a step further.

Introducing a CI/CD pipeline into our SDLC allows us to efficiently implement automation and monitor code changes, new features, potential bug fixes, and more. It also allows development teams to frequently deliver and publish applications and to accelerate the application development process.

Let’s look in some more detail at what the different CI/CD stages are.

Continuous Integration

Continuous Integration refers to the build / integration stage of the software release process. In this stage developers consistently merge their changes into the main repository of a version control system (for example Git). Before code changes are committed, you can run unit tests to verify the code before integrating it into the main repository. After the new code is merged into the main repository, automated builds and tests are run in order to verify that there are no errors or bugs.

Continuous Delivery

Continuous Delivery further expands upon Continuous Integration. With a continuous delivery pipeline, we can further automate testing beyond just unit tests and perform UI tests, integration tests, load tests, and more. When we thoroughly test the codebase, we can verify that the application is error-free and ready for deployment. With Continuous Delivery, the operations team triggers the deployment instead of it happening automatically (this is where continuous deployment comes in).

Continuous Deployment

It’s common to mistake continuous deployment for continuous delivery. Continuous deployment goes a step beyond continuous delivery. It’s a software release process that refers to the automatic deployment of applications into production. Continuous deployment releases the application from the repository to production, which eliminates the need for human interference. Since tests are still implemented throughout the process, problematic code will not be deployed to production. Development teams are notified when tests fail so they can take the necessary steps to fix the problem before deployment.
Continuous deployment is beneficial because it speeds up the delivery of the application and the feedback loop with users. It allows teams to increase productivity and efficiency and rapidly push their software to the market. Verified and tested applications can be instantaneously deployed, which allows developers to focus on other tasks, including new features, updates, bug fixes, and more. While there are many advantages to implementing continuous deployment, the initial implementation itself can be expensive. The continuous deployment pipeline may require ongoing maintenance and updates to ensure it runs as smoothly as possible.

Some of the more popular tools for creating and managing CI/CD pipelines are Jenkins, TeamCity, GitLab CI, Travis CI, GitHub Actions, Azure DevOps, AWS Pipeline, etc. We will take a look, in a bit more detail, into these tools in part 2 of this blog post.

Benefits of CI/CD

As you can see above, the benefits of implementing a CI/CD pipeline are many, so let’s explore some of them here:

• Increased speed: With an automated CI/CD pipeline, teams can ship changes at a much faster rate, and we can optimize each stage of the process. New changes and features can be launched quickly, which allows you to respond to new trends and address any issues that come up.
• Improved collaboration and visibility: A CI/CD pipeline allows many people to get involved in the process, which promotes visibility and collaboration across different teams and organizations.
• Real-time feedback: Shipping regular updates allows you to receive more immediate feedback from users. It also allows you to experiment with different features and fixes, and then hear about their performance shortly after deployment.
• Continuous reliability and continuous testing: Continuous reliability, or test reliability, improves in a CI/CD pipeline. This is because incremental changes are implemented one at a time, which allows for more precise and accurate tests to be conducted continuously.
• High-quality code: With CI/CD, your code is tested regularly. This means that you’ll discover bugs sooner and fix them more quickly.

Now let’s take a look into an example where implementing such a pipeline will be beneficial.

Bringing it all together

Let’s imagine that we have an application which is constantly being developed and there are frequent commits to the master branch of the repository.

Scenario 1: Without a CI/CD chain

In an organization without an implemented CI/CD process, this will mean that for every commit the code needs to be manually tested and compiled, then manually deployed to the development/test environment in order for the compiled application to be tested once more, again – manually. This will, without a doubt, be a very time consuming process, as all the steps are manual, which will delay the implementation of new features, which will, in turn, cause a lot of technical debt for the development team.

Scenario 2: CI/CD in place

Now let’s look at the same example case, but with an implemented CI/CD pipeline. In this case, the best way to start the process would be with an automated start of the build process upon commit. That way the moment a developer commits their code, the pipeline will trigger and start the automated tests and build of the application. Once this is done, if everything is successful, the pipeline will proceed to the next step. In case of errors or the build fails, the developer will be able to see the logs and go back and rectify any mistakes immediately. After a successful build, the next step would be for the pipeline to deploy the application to the development/test environment. There, upon successful deployment, all the preconfigured tests will be run against the newly deployed application. Here again if the tests pass, the pipeline will proceed to the next step. Which could be a) storing the built application to a repository from which the Ops team can deploy it to Production (Continuous Delivery), or b) if configured for Continuous Deployment, the pipeline will proceed to deploy and test it until it reaches the Production environment. If any errors occur or any tests fail during the run of the pipeline, the developer will be notified and will be able to take action immediately.

As you can see in both scenarios, we follow the same steps of build, deploy and test, however, in the second scenario the whole process takes much less time and involvement due to the automation introduced via the CI/CD pipeline. The other benefit which is obvious from the second scenario is the constant feedback which is almost instantaneous, thanks to the continuous monitoring of the process and the environments.

Hopefully, the above overview will be enough to convince you of the benefit of implementing a CI/CD pipeline for your development team. The end goal will always be to have a stable application with frequent updates, and the introduction of a CI/CD pipeline in the SDLC is one of the best ways to achieve that.

In part 2 of Getting started with CI/CD the DevOps experts of ITIDO dive deeper by discussing the plethora of CI/CD tools available on the market.