Explaining CI/CD

Before going deeper into GitHub Actions, we need to understand the terms CI and CD. In this section, we will go over each term and explain the differences.

CI

CI is a practice of automating the integration of code changes from multiple collaborators into a single project. It also concerns the ability to reliably release changes made to an application at any time. Without CI, we would have to manually coordinate the deployment, the integration of changes into an application, and security and regression checks.

Here’s a typical CI workflow:

1. A developer creates a new branch from the main branch, makes changes, commits, and then pushes it to the branch.

2. When the push is done, the code is built, and then automated tests are run.

3. If the automated tests fail, the developer team is notified, and the next steps (usually deployment)are canceled. If the tests succeed, then the code is ready to be deployed in a staging or production environment.

We can find many tools for CI pipeline configurations. We have tools such as GitHub Actions, Semaphore, Travis CI, and a lot more. Here, we will use GitHub Actions to build the CI pipeline, and if the CI pipeline passes, we can deploy it on AWS. Now let’s learn more about CD.

CD

CD is related to CI, but most of the time represents the next step after a successful CI pipeline passes. The quality of the CI pipeline (builds and tests) will determine the quality of the releases made. With CD, the software is automatically deployed to a staging or production environment once it passes the CI step.

An example of a CD pipeline could look like this:

1. A developer writes a branch, makes changes, pushes the changes, and then creates a merge request.

2. Tests and builds are done to make sure there is no regression.

3. The code is reviewed by another developer, and if the review is done, the merge request is validated, and then another suite of tests and builds are done.

4. After that, the changes are deployed to a staging or production environment.

GitHub Actions and the other tools mentioned for CI also support CD. With a better understanding of CI and CD, let’s define the workflow that we will configure for the backend.

Note: You will also hear about continuous delivery if you are diving deeper into CI/CD; it is a further extension of continuous deployment. Continuous deployment focuses on the deployment of the servers while continuous delivery focuses on the release and release strategy.

Defining the CI/CD workflow

Before deploying an application, we need to write off the steps we will follow, along with the tools needed for the deployment. In this section, we will automate the deployment of the backend on AWS. Basically, each time we have a push made on the main branch of the repository, the code should be updated on the server, and the containers should be updated and restarted.

The deployment flow

Again, let’s define the flow as follows:

1. A push is made on the principal branch of the server.

2. Docker containers are built and started to run tests. If the tests fail, step 3 is ignored.

3. We connect via SSH to the server and run a script to pull the new changes from the remote repository, build the containers, and restart the services using docker-compose.

The following diagram illustrates a typical CI/CD workflow: