Overview

Continuous Integration/Continuous Deployment (CI/CD) Pipeline lays out some practices to follow in order for the code you write to more quickly and safely get to your users and ultimately generate value. The CI (Continuous Integration) part of CICD can be summarized as all code parts that go into making your application go to the same place and run using the same processes with results published to an easy to access place. further, if  you’re doing CI and for some reason, the integration fails, that means the broken build becomes the highest priority to fix before continuing to add more features. Moreover, CD(continuous Delivery) generally refers to the overall chain of processes (pipeline) that automatically gets source code changes and runs them through build, test, packaging, and related operations to produce a deployable release, largely without any human intervention .

CI/CD Pipeline is crucial in order to improve delivery predictability, efficiency, security and maintainability of our products. This pipeline automates the steps in our product delivery process, such as initiating automatic builds, testing and then deploying to Kubernetes.

Continuous Integration/Continuous Deployment (CI/CD) is crucial in order to improve delivery predictability, efficiency, security and maintainability of our products. This pipeline automates the steps in our product delivery process, such as initiating automatic builds, testing and then deploying to Kubernetes.

The Kubernetes Continuous Integration Continuous Delivery (CI/CD) pipeline tool for WSO2 API Microgateway help in automating the delivery process by building docker images, running automated tests, and deploying to a Development, Staging, or Production environments. Additionally, the setup consists of tools required for seamless update delivery, log aggregation, and monitoring.

The tools consist of Jenkins and Spinnaker. They are the primary tools used for continuous integration and deployment. The setup is deployed on top of Kubernetes using Helm, which makes the processes of configuration, installation, scaling, and upgrading simple. Additionally, Jenkins jobs and Spinnaker pipelines are preconfigured, making the process of getting started hassle-free.

Pipeline Architecture

The following diagram illustrates the architecture of the CI/CD pipeline.

This pipeline uses Jenkins as the integration tool, while Spinnaker is being used as the deployment tool.

For a product to be created or updated, Spinnaker expects a new Helm chart or Docker image. An update could be triggered by Spinnaker from any of the following events:

1. The Helm chart's overriden values(values-dev.yaml, values-staging.yaml, values-prod.yaml) are stored in the chart source repository and Jenkins periodically polls for changes to the repository. Once a change is detected, a predefined Jenkins job will download the relevant chart from WSO2 repository and provide it to Spinnaker as a Webhook along with the overrides for each environment.
2. A cron job in Jenkins pulls the latest image from the WSO2 Docker registry containing  the latest updates. A new image is built on top of this updated base image based on the Dockerfile in the artifact  source repository. This image is then pushed to the private  Docker registry which  is then consumed by Spinnaker and propagated to the environments.
3. The artifact source repository contains  the Dockerfile used to customize the base image from WSO2 Docker registry.  This could also include artifacts that need to be copied into the image. A change to this repository triggers a build of a new image, which gets pushed to the private  Docker registry.  This triggers Spinnaker to propagate the new image to the environments.

Each environment has a corresponding Spinnaker pipeline (Dev, Staging, and Production). Every new change is deployed to Dev environment immediately. However, promotion to the staging and above environments need manual approval, which will trigger the pipelines to respective environments.