CI/CD is a set of methods that enables application developers to deliver code changes more frequently to customers through the use of automation.
The acronym CI/CD refers to two separate concepts that are generally used together: continuous integration and continuous delivery.
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.
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:
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 false
html.enabled true
}
}
tasks.withType(Checkstyle) {
reports {
xml.enabled false
html.enabled true
}
}
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: deploy
image: 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 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.
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.
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.