What is Continuous Integration and Delivery (CI/CD)?

Resource

Edge Academy

Topic

DevOps

Definition

CI/CD is a set of methods that enables application developers to deliver code changes more frequently to customers through the use of automation.

Overview

The acronym CI/CD refers to two separate concepts that are generally used together: continuous integration and continuous delivery.

  • Continuous integration refers to an automation process that developers use to build, test, and merge application code changes.
  • Continuous delivery is the next step in the process where the tested code from continuous integration is automatically deployed in various environments by a manual trigger.

CD can also stand for continuous deployment, which introduces further automation. In continuous delivery, developers need to push changes to their production environment manually. By using continuous deployment instead, developers can have application changes automatically deployed to any environment.

For this discussion, we will only focus on the concepts of continuous integration and continuous delivery.

How CI/CD Works

The modern, fast-paced world of application development demands that multiple developers work on a single app simultaneously. In a standard lifecycle, once developers are ready to test their changes, they merge their individual code changes on a predetermined “merge day.” The merging process is tedious and labor-intensive. It becomes even more intensive if a developer’s change affects another developer’s change, ultimately forcing the team to rollback or spend hours on bug fixes.

The continuous integration phase

Converting to a CI/CD process helps developers merge and test code more frequently, even on a daily basis.

The continuous integration phase follows these basic steps:

  1. A developer takes code from the shared repository to work on it, possibly creating a new branch for a new feature.
  2. Once the new feature is complete, the developer pushes it back to the shared repository.
  3. The CI server determines that changes have been made and begins to build and test the application, ensuring that the changes have not caused the application to break. The tests focus on total functionality to ensure that no part of the application has been compromised.
  4. The development team is notified of the test results. In the event of a failure, the team will know that the new code has caused the failure and can begin to isolate and fix the issue. If the changes are successful, the team moves on to the continuous delivery phase.

The code below is a sample Gradle build script that performs some simple bug and style checks.

apply plugin: 'java'apply 
plugin: 'findbugs'
apply plugin: 'checkstyle'

repositories {
    mavenCentral()
}

dependencies {
     ...
}

tasks.withType(FindBugs) {
    reports {
          xml.enabled 
          falsehtml.enabled true}
     }

tasks.withType(Checkstyle) {
     reports {
          xml.enabled 
          falsehtml.enabled true}
      }
}

The continuous delivery phase

Once thorough testing has taken place, teams can move on to the continuous delivery phase. The delivery of code must be manually triggered by a developer, but the rest of the process is entirely automatic. All necessary interaction with web servers, databases, and other services is done with the call of a script.

One way to trigger a deployment is to use a YAML configuration file through GitLab. Below is a sample configuration file that would deploy scripts using EdgeEngine.

// .gitlab-ci.yml
stages:
    - deploy
deploy_edgeengine: 
stage: deployimage: node
only:
    - master
script:
    - npm install -g @stackpath/edgeengine-cli
    - edgeengine auth --client_id $STACKPATH_CLIENT_ID --client_secret $STACKPATH_CLIENT_SECRET --force
    - edgeengine deploy

CI/CD at the edge

CI/CD software pipelines are particularly helpful when deploying in high-risk environments. At the edge, there is a lack of physical access that can sometimes make it difficult to mitigate problems. Using continuous integration and continuous delivery lessens the risk by supporting small, incremental changes to an application. Problems can then be rapidly detected and mitigated before damaging production environments.

Examples of CI/CD

GitLab

StackPath provides a great tutorial for using the EdgeEngine CLI in GitLab CI/CD. The tutorial walks you through a deployment step-by-step, teaching you how to “include CLI scripts in version control,” “integrate the CLI with GitLab CI/CD,” and “make an IP firewall with EdgeEngine.” Further GitLab examples can be found at GitLab Docs.

CircleCI

ReactJS is a popular JavaScript framework that was developed and is maintained by Facebook; it is also a great example of a robust CI/CD pipeline. Every time a contributor submits a Pull Request, CircleCI is used to build and test the new version of ReactJS. Those results are completely transparent, visible for anyone who wants to use the framework.

The idea behind CircleCI is creating a GitHub or Bitbucket CI/CD pipeline. Every code change that is made to the code repository triggers a testing job which is run in an isolated container or virtual machine. Other open source projects that utilize Circle CI include Flow, Relay, StoryBook, Angular, Yarn, and more.

Key Takeaways

  • CI/CD is a combination of two concepts: continuous integration which builds and tests applications after code changes and continuous delivery which pushes approved changes to a variety of environments.
  • Using CI/CD pipelines for mission-critical applications can reduce the risk of code changes through small, incremental updates by isolating the effect that bugs can have on an application.

Related