Skip to content

Short introduction

CI/CD is the combination of two different concepts. CI/CD removes manual human interactions where possible — automating everything except the final manual code deployment to production. One of the challenges of implementing this practice is integrating the various tools and systems required to build a CI/CD pipeline.

Continuous integration (CI) and Continuous Delivery (CD) embody a culture, set of operating principles, and collection of practices that enable application development teams to deliver code changes more frequently and reliably.

CI : Continuous Integration

The CI part of CICD can be summarized with: you want all parts of what goes into making your application go to the same place and run through the same processes with results published to an easy to access place.

Developers practicing continuous integration merge their changes back to the main branch as often as possible. The developer's changes are validated by creating a build and running automated tests against the build. By doing so, you avoid the integration hell that usually happens when people wait for release day to merge their changes into the release branch.

Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch.

Usually, the process is triggered off an update to an SCM (Source Code Manager). After the trigger fires, your CI will begin to build your application and then run tests and other operations against the entirety of your application.

Example Steps:

  • The code is cloned from SCM (e.g. GitHub)
  • Build scripts, create a new version of your application
  • The new version is put through the wringer in the form of a series of automated tests and other application-specific operations

Benefits:

  • Automated execution of test suite off SCM trigger
  • Fewer production rollbacks due to catching issues early

Quote

Continuous Integration (CI) is a development practice where developers integrate code into a shared repository frequently, preferably several times a day. Each integration can then be verified by an automated build and automated tests.

The key goals of continuous integration are to find and address bugs quicker, improve software quality, and reduce the time it takes to validate and release new software updates.

CD: Continuous Delivery

Continuous delivery is an extension of continuous integration to make sure that you can release new changes to your customers quickly in a sustainable way. This means that on top of having automated your testing, you also have automated your release process and you can deploy your application at any point of time by clicking on a button.

In theory, with continuous delivery, you can decide to release daily, weekly, fortnightly, or whatever suits your business requirements. However, if you truly want to get the benefits of continuous delivery, you should deploy to production as early as possible to make sure that you release small batches that are easy to troubleshoot in case of a problem.

CD : Continuous Deployment

Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There's no human intervention, and only a failed test will prevent a new change to be deployed to production.

Continuous Delivery is a powerful way to continuously deploy your code live to end users or to various environments (e.g. dev, QA, prod).

Similar to CI, the process is kicked off by an update to an SCM. Which will then run a series of operations which is completely customizable by your team. These operations are usually packaged up into a series of bash scripts (e.g. bash, python) which handle interacting with your service providers.

Continuous deployment is an excellent way to accelerate the feedback loop with your customers and take pressure off the team as there isn't a Release Day anymore. Developers can focus on building software, and they see their work go live minutes after they've finished working on it.

Example Steps:

  • The code is cloned from SCM (e.g. BitBucket)
  • Build scripts, create a new version of your application
  • The new version is pushed/synced/uploaded to your hosting provider and replaces the old version of your application

Benefits:

  • Automated deployment process (less human errors)
  • Release new versions of your application quickly!

Quote

Continuous deployment is a strategy for software releases where in any code commit that passes the automated testing phase is automatically released into the production environment, making changes that are visible to the software’s users.

Why is it used

With a CI/CD:

Automation. Automation. Automation. Your team is able to build confidence with every push. Increased visibility allows every member of the team to understand the full process versus separating the responsibilities in a way where every team member is a walled-off silo.

As potential problems pop up, they are added into the CI/CD to increase the overall strength. Something that would be hard to do without a CI/CD as you wouldn’t have a single source of truth for what should happen at each phase in the application deployment lifecycle.

For instance, if you had a problem pop up where unit/integration tests locally didn’t account for issues that pop up when you’re application is deployed live. Then you could incorporate a rollback strategy, add smoke tests as a final sanity check and lay the foundation for future edge cases where local vs live don’t align.

Without a CI/CD:

Developers write new code, run some tests locally (maybe?), and push the code to your SCM (ideally as a pull request). Depending on the level of the established process your company has, the code is extensively reviewed or briefly reviewed and merged. Once merged, the code is manually deployed and replaces your existing application.

A problem pops up, the deployed code is preventing users from signing up. Unfortunately, the code has already replaced your live application.

Example scenario

Let’s say we have a Node.js API that retrieves a list of books in a database. We can create a pipeline that pushes our code through three phases: build, test and deploy. A pipeline is a group of steps that are grouped by similar characteristics. With those phases our pipeline is defined by three types:

  • Project Pipeline
  • Continuous Integration Pipeline
  • Deploy Pipeline

The Project Pipeline installs dependencies, runs linters and any scripts that deal with the code. The Continuous Integration Pipeline runs automated tests and builds a distributed version of the code. Finally, the Deploy Pipeline deploys code to a designated cloud provider and environment.

The steps that the three pipelines execute are called jobs. When you group a series of jobs by those characteristics it is called stages. Jobs are the basic building block for pipelines. They can be grouped together in stages and stages can be grouped together into pipelines. Here’s an example hierarchy of jobs, stages, and pipelines:

A.) Build
 i. Install NPM Dependencies
 ii. Run ES-Linter
 iii. Run Code-Minifier
B.) Test
 i. Run unit, functional and end-to-end test.
 ii. Run pkg to compile Node.js application
C.) Deploy
 i. Production
 1.) Launch EC2 instance on AWS
 ii. Staging
 1.) Launch on local development server

In this hierarchy, all three components are considered three different pipelines. The main bullets — build, test, and deploy are stages and each bullet under those sections are jobs.

Further reading: