What is a Continuous Integration and Delivery Pipeline, and Why Is It Important?

What are CI and CD?

Just to set our baseline, It would be useful to define what CI and CD are before getting into the value they can provide. Instead of redefining these terms, let me cite the “official” definitions from the guys at ThoughtWorks, who literally wrote the books on these topics:

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

Continuous Delivery (CD) is the natural extension of Continuous Integration: an approach in which teams ensure that every change to the system is releasable and that we can release any version at the push of a button. Continuous Delivery aims to make releases boring, so we can deliver frequently and get fast feedback on what users care about.

What is a pipeline?

A deployable piece of code is called a pipeline

Pipeline functions are called when the code is committed and pushed to a repository like GitHub. A build system like Jenkins listens to events that new code is pushed to the repository. Build system compiles the code and runs Unit Tests. If your units tests pass then next step is Integration tests otherwise build process stops and raises a flag saying one or more Unit/Integration tests failed.

Once all your tests pass. Then you archive a build (zip or other formats) and save.At this stage, your archive can be deployed to your servers. In some cases, this step is automated for your test servers to always test the latest application.

Pros of CI pipelines

For the good parts of pipelines. There is lots and lots of good about pipelines when they are done the right way. Some of the highlights of a well-assembled pipeline are:

• Developers can just worry about their code and dependencies, not runtime configuration.
• Testers can see what tests have been automatically run, and then either automate more, investigate trouble areas, or simply spend their time on the new functionality to validate it against client requirements.
• Operations can just redeploy if something isn’t working on an application. No restoring from tape or wondering what changed and wasn’t documented.
• Introducing new versions or bug fixes is the same routine process.

Benefits of CI/CD pipelines

It works locally is out of the game

How many times have you heard a team member say “it worked locally.” In their defense, it likely did work locally. However, when they tested it locally they were testing on a snapshot of your code base and by the time they pushed, things changed. Continuous Integration tests your code against the current state of your code base and always in the same (production-like) environment, so you can spot any integration challenges right away.

Increase Your Code Coverage

Does your test cover most of your code? A CI server can check your code for test coverage. Now, every time you commit something new without any tests, you will feel the shame that comes with having your coverage percentage go down because of your changes. The results of your tests should be displayed on your build pipeline. If a build passes, that increases the confidence of the team. If it fails, you can easily ask team members to help you determine what may have gone wrong

Deploy Your Code to Production

A CI system can automatically deploy your code to staging or even production if all the tests within a specific branch are green. This is what is formally known as Continuous Deployment. Changes before being merged can be made visible in a dynamic staging environment, and once they are merged these can be deployed directly to a central staging, pre-production, or production environment.

Never Deploy Broken Code

Using continuous integration means that all code is tested and only merged when all tests pass. Therefore, it’s much less likely that your master builds are broken and broken code is shipped to production. In the unlikely event that your master build is broken, let your CI system trigger a warning to all developers

Decrease Code Review Time

You can have your CI and Version Control System communicate with each other and tell you when a merge request is good to merge: the tests have passed and it meets all requirements. In addition, even the difference in code coverage can be reported right in the merge request. This can dramatically reduce the time it takes to review a merge request

Build Test Deploy Everyday or Many a time a day

With the build system ready for your product. You can make sure each of your builds is tested in the same way for every change.