[Kubernetes, Cloud Native]

Kubernetes and Cloud native Application Checklist: Continuous Integration and Delivery (CICD)

Part Two of our Kubernetes and Cloud native application checklist outlines CICD tools that CIOs, CTOs and DevOps teams leads can use to accelerate the build, test and deploy workflow for cloud native containerised applications.

Hasham Haider

Hasham Haider

January 27, 2020

4 minute read

This is the second instalment in our cloud native and Kubernetes application checklist series. In instalment one we looked at the complexity that cloud native applications introduce into the developer workflow. We also outlined the tools aimed at streamlining this workflow,  making it easier for devs to build and deploy code while reducing integration issues for cloud native applications deployed on Kubernetes.

In this article we will review continuous integration and deployment (CICD) tools aimed at cloud native environments. We will also evaluate these tools based on how well they integrate with modern cloud native applications and Kubernetes.

Cloud Native CICD tools

CICD is driven by the demands for speed, agility and automation placed on modern software release cycles. A related set of CICD tooling has also cropped up to support this concept. CICD tools usually encompass the build, test and deploy workflow and allow developers and DevOps to accelerate software delivery and reduce integration issues in production.

Modern CICD tools need to align with the specific requirements of cloud native containerised applications deployed on Kubernetes. Several CICD tools specifically targeted towards cloud native architectures are already in the market.

Most of these tools also aid developers by abstracting away the heavy lifting involved in prepping applications for deployment on Kubernetes, packaging applications as docker images and creating Kubernetes manifests.

Below we will outline some of these tools specifically targeted towards build and deploy workflows for cloud native applications deployed on Kubernetes.


Jenkins is one of the most widely known CICD tool. A newer iteration, Jenkins-x, is specifically targeted towards cloud native applications on Kubernetes. Jenkins-x allows Developers and DevOps to quickly spin up new projects that include a template application, as well as all the required artifacts including a git repository, default Dockerfile, Jenkinsfile and Helm charts. Jenkinsfiles are source-controlled declarative pipeline as code files that implement the CICD pipelines.

Jenkins-x also introduces the concepts of environments. Environments are usually created for individual teams (staging, production) and are highly flexible. Each environment refers to a Kubernetes namespace, which isolates all the resources of that environment. New features that have been merged to the main branch are promoted to the production environment after passing through a battery of automated tests.

Jenkins-x eases the learning curve for beginners by automating the deployment of CICD pipelines compatible with cloud native, containerised applications as well as abstracting away some of the complexity of building and deploying those applications.


Gitlab is a feature rich CICD tool with support for automated code quality and performance testing, container and dependency scanning and automated deployments. Its Auto DevOps feature aims to declutter the software development and release lifecycle by making it easier for DevOps to setup and manage cloud native CICD pipelines.

Gitlab has a broad integration footprint with both Docker and Kubernetes with a built-in container registry, the ability to add and remove Kubernetes clusters via the CI, support for canary deployments to a subset of pods as well as auto deployment to Kubernetes clusters.

Deploy boards are another feature tightly integrated with Kubernetes, providing insights into the health and status of each CI environment running on Kubernetes. DevOps can also easily monitor cluster metrics and performance by enabling the Prometheus and Kubernetes integrations along with easy access to pod logs.


Argo is an open source CICD project from Argo and Intuit, designed specifically for cloud native applications on Kubernetes. It supports automated deployment and delivery of new features and updates to a microservices based application deployed on multiple Kubernetes clusters.

CICD pipelines in Argo are implemented using Kubernetes CRDs and are referred to as workflows. Being implemented as CRDs means Workflows are tightly integrated with  Kubernetes services such as volumes, secrets and RBAC. It also means they can be managed using Kubernetes tools like kubectl. Workflows are yaml files that define everything that needs to happen as part of the pipeline. Once created the new workflows run as containers inside your own Kubernetes cluster.

Argo harnesses GitOps principles of git as a single source of truth, version control, declarative definitions and automated divergence detection. Once setup Argo monitors the actual state of live applications and compares it to the version controlled state specified in git repositories. Any divergence from the desired state are flagged with triggers for either manually or automatically syncing both states. Argo also provides flexible deployment strategies including blue/green and canary deployments.


GoCD is a part of the CNCF landscape and is featured as one of the highest starred continuous integration and delivery CICD tools. It is tightly integrated with Kubernetes and leverages Helm charts to provide a simple setup and upgrade mechanism.

Once installed the Helm chart spins up an a GoCD server and GoCD elastic agents as Kubernetes pods inside the cluster. Elastic agents are dynamic and can scale based on the number of jobs to be executed.

GoCD pipelines can be defined in both yaml and Json and can be stored in a version control system. A GoCD server poller checks these definitions and automatically updates the main GoCD pipeline configuration in case of any modifications.

DevOps can import sample pipelines to get up and running quickly or add new pipeline configurations by adding a configuration repository. Deployment pipelines can be configured using native Kubernetes artefacts like secrets, service accounts and API tokens. Pipelines are triggered by ‘materials’ which are often updates to a source code repository such as git. Once triggered pipelines build, test and deploy new feature artefacts to a target Kubernetes cluster.

Want to dig deeper? Download the Complete CIOs Guide to Kubernetes

Download Guide


0001-a CIOs guide to kubernetes in production-email-cover Download Guide
Hasham Haider


Hasham Haider

Fan of all things cloud, containers and micro-services!

Want to Dig Deeper and Understand How Different Teams or Applications are Driving Your Costs?

Request a quick 20 minute demo to see how you can seamlessly allocate Kubernetes costs while saving up to 30% on infrastructure costs using Replex.

Contact Us