DevSecLab Series: CI/CD Principles

As stated in my previous post introducing the DevSecLab series, this post will cover the CI/CD principles. I will also explain the difference between continuous integration (CI) and continuous delivery (CD) and CI/CD pipeline specifics.

CI/CD Overview

According to InfoWorld, continuous integration (CI) is a coding philosophy that takes a set of practices that are defined by the development teams to implement changes and check-in code to source code management systems frequently. The goal of CI is the establish and maintain a consistent and automated way for the code to be compiled, built, and tested before new changes have been committed to the same repository. (Sacolick, 2020)

After the CI process has completed, the continuous delivery (CD) process will be executed., This is where the application is automatically deployed into the environments that are specified by the application team. In other words, this process could deploy the application to development, Q/A, or production.

CI/CD Principles

In order for code to be pushed to production successfully and safely, the following principles must be incorporated into the implementation of the pipeline:

1. Ensure application design supports iterative releases: As the development team, you will want to ensure that components of the application are loosely coupled, otherwise you run the risk of running into issues following the Agile methodology.

2. Emphasize and enforce test-driven development (TDD): Development teams should be required to maintain a comprehensive and healthy automated test suite for their application. This test suite should include unit and regression tests. This will help eliminate potential bugs and bad releases to production.

3. Feature and Fix Branching Model: Personally, I've seen developers commit code straight to master that was a part of a feature that IS NOT production-ready.... which defeats the purpose of working in small iterations. Please ensure that your development team is developing their features and fixes within their feature and fix branches, and merging those changes into the branch that is respective to their environment. For instance, if I am attempting to deploy to the development environment, I will merge my feature into the "dev" branch. For more information on branching strategies, please refer to GitFlow Branching Model Overview: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

CI/CD Pipelines and Tools

One thing to know is that there are several CI/CD tools that engineers use to build CI/CD pipelines for application deployment. Examples of CI/CD tools are Jenkins (my favorite), CircleCI, and AWS CodeBuild.

CI/CD pipelines contain a series steps, or stages, that are executed by the CI/CD tool to deploy the application or software. Most pipelines contain the basic stages: build, test, and deploy. The build stage is responsible for compiling the entire codebase. The test stages will run the entire test suite. Finally, the deploy stage will deploy the application to the configured environment. If any of these stages fails, the entire pipeline will fail. In the event this happens, the developer that last committed code "should" fix the issues pointed out by the tool.

As application teams mature, one should expect pipelines to be more sophisticated. Some of the more sophisticated pipelines contain many steps such as:

1. Obtaining code from SCM and building the application

2. Configuring target environment

3. Providing log data and alerts on the pipeline state (whether it failed or not)

4. Executing tests and rolling back environments upon failure

5. Moving code from lower environments to higher environments

One of the coolest features of most CI/CD tools as that they allow developers trigger the pipeline build on-demand via webhooks or by using a scheduler. Webhooks are automated messages that are sent from app to app to trigger an event. Most source code management tools support webhooks for the developer to configure to talk to CI/CD tools. Assuming the webhook is properly configured, if a developer commits code, the pipeline should be triggered automatically.

That sums up this post. I hope you all have found this information helpful. More content is coming out soon. Cheers!

Citations:

Sacolick, I. (2020, January 17). What is ci/cd? Continuous integration and continuous delivery explained. Retrieved April 28, 2021, from https://www.infoworld.com/article/3271126/what-is-cicd-continuous-integration-and-continuous-delivery-explained.html