Blog series on CI/CD

Page content

If you or your team is trying to adopt CI/CD and struggling to understand what CI/CD is all about, then you are not alone. CI/CD stands for Continuous Integration and Continuous Delivery. In a cloud environment CD also encompasses Continuous Deployment because you deploy code as soon as it is ready. If you aspire to be agile, then you need to embrace CI/CD wholeheartedly.

I will share a couple of great articles that introduce CI/CD. Instead of me providing yet another definition, I recommend that you read these articles. But here is what I will do. Using a series of blogs, I will take you through a journey of CI and CD. I will use my blog as an example to show various technologies like Jenkins and Docker and their role in CI and CD.

What is CI/CD

I found one of the best definitions of CI/CD in this Infoworld article.

Continuous integration is a coding philosophy and set of practices that drive development teams to implement small changes and check in code to version control repositories frequently. Because most modern applications require developing code in different platforms and tools, the team needs a mechanism to integrate and validate its changes.

Continuous delivery picks up where continuous integration ends. CD automates the delivery of applications to selected infrastructure environments. Most teams work with multiple environments other than the production, such as development and testing environments, and CD ensures there is an automated way to push code changes to them.

Continuous integration and continuous delivery require continuous testing because the objective is to deliver quality applications and code to users. Continuous testing is often implemented as a set of automated regression, performance, and other tests that are executed in the CI/CD pipeline.

I found another great overview of CI/CD in a Redhat article

Continuous delivery usually means a developer’s changes to an application are automatically bug tested and uploaded to a repository (like GitHub or a container registry), where they can then be deployed to a live production environment by the operations team. It’s an answer to the problem of poor visibility and communication between dev and business teams. To that end, the purpose of continuous delivery is to ensure that it takes minimal effort to deploy new code.

Continuous deployment (the other possible “CD”) can refer to automatically releasing a developer’s changes from the repository to production, where it is usable by customers. It addresses the problem of overloading operations teams with manual processes that slow down app delivery. It builds on the benefits of continuous delivery by automating the next stage in the pipeline.

My blog as an example for CI/CD

Let us now see how I use CI/CD when I write these blog. I write my blogs using Markdown and then use a static site generator called Hugo to generate HTML files for my blog. Then I host these static HTML files on AWS. So effectively, the Markdown files are the source code that I want to integrate and the output of Hugo (static HTML files) is the artifact that I want to deploy.

The picture above captures the CICD process I have been using for my blogs. As you can see the “build and integrate code is the heart of this process. I will share several tools that are used for this important step of the CICD process. Specifically, I will talk about Jenkins since it is one of the most popular open-source CI/CD system.

Blog outline

Finally here is the outline of the whole blog series. As I work through this outline, I will keep updating this page to include links to all the related blogs.

  • Understanding CI/CD Personas - In this blog I cover two common CI/CD personas and impact on the CI/CD process for my blogs.
  • Developer experience and CI using Docker containers - This blog shows how Docker can be used to create a simple and consistent environment for developers to get CI/CD going.
  • CI Process - the developer perspective - In this blog I walk you through the process of CI as seen by the developer, step by step.
  • CI Process - the shared perspective - This blog shows the changes needed to create a common Dockerfile and image that will be used by developers as well as CI System like Jenkins. The idea is to demonstrate the benefit of common build and packaging environments.
  • CI Process - the DevOps and CI System perspective - This blog shows how a CI system is setup by the CI/CD team. We will see how Jenkins agent and pipelines are used for CI. We will use the same Docker image as used by Developer but with different parameters.
  • CD Process - Setting up CD Pipelines in Jenkins - This blog shows you how to use docker containers and Jenkins to setup a deployment pipeline. The example deployment pipeline will copy my static website to AWS S3 bucket.
  • Bonus - setting up CICD Pipeline using AWS or Azure (I will decide which one later)