ArgoCD & GitOps Introduction


In this article, we aim to introduce the concept of Argo CD and its core GitOps. Thus, to elucidate how Argo CD manages to make the deployment process more efficient. 


It is a code-based infrastructure and operational procedure that relies on Git as a source control system.  Specifically, it is the practice of using Git pull requests to automatically verify and deploy changes to the system infrastructure. Even Git pulls define the essence of GitOps.

Argo CD

Argo CD is a declarative continuous delivery tool for Kubernetes. It follows the GitOps model by using Git repositories as the source of truth to define the desired state of the application.

Essentially, Argo CD was built to make continuous delivery to Kubernetes clusters more efficient and this is mainly due to the ability to track updates to branches, tags, or pins of a specific version of manifests during a Git commit. 

How does Argo CD make the deployment process more efficient and what are the challenges faced with the traditional CD pipeline?

To answer this question and to understand the importance of using Argo CD in the deployment part, we present a comparative study of the continuous deployment part without and with Argo CD.

First approach – the classic CD pipeline 

Pipeline workflow

During each commit, the continuous integration tool makes this new version tested, then it makes the build of the image ( small description ) and finally it makes the push to the docker repository. 

At this point, the kubernetes manifest file undergoes changes and so we need some tools / steps to apply these changes on the kubernetes cluster.

To do this, it is necessary to

  • Install a tool capable of controlling and applying these changes on the k8s cluster such as Kubectl
  • Configure the Kubectl settings to give it access to the cluster 

The challenges of this approach 

–  A security challenge

– we need to give access to external parties (Jenkins server) to the k8s cluster.

– In the condition that this application is deployed on the cloud using EKS for example, we need to share our cluster credentials with Jenkins so that it can apply changes every time we change the k8s manifest file.

–  A visibility challenge

– Once Jenkins applies changes to the kubernetes cluster, it no longer has visibility into the status of the deployment. In this case, we can’t be sure if the deployment has been completed or if there are issues preventing it from firing.

The solution is therefore to use Argo CD to facilitate / solve the problems of the continuous deployment process.

  How to use Argo CD? 

The Argo CD workflow 

  1. Deploy the Argo CD in the K8s cluster.
  2. Configure Argo CD to connect to the git repository and track changes. 
  3. Argo CD detects changes in the Git repository and applies them to the cluster. 

In the image below, we present in more detail how Argo CD works. Indeed, it manifests itself as an agent detecting changes on the resting Git (and also for the cluster) and in case the last two are not synchronized, it applies the last changes on the other part (the cluster or also the resting Git).

Second approach – the CD pipeline with Argo CD


The continuous integration pipeline remains the same, the difference is in the continuous deployment pipeline where we no longer need to install tools to monitor the k8s cluster but rather Argo CD works as a listener detecting that the docker image has been changed so it steps in to make those changes to the cluster. Similarly, it works the other way around where it is also a listener for the cluster and if it is out of sync with the manifest file in the git, it also steps in to do the sync between the two.

The advantages of using Argo CD 

The benefits of using Argo CD are many and varied and in this section we present some of the benefits that we consider essential.

  • Easy rollback 

When a new configuration fails at startup, we can roll back to the previous working state on the git repository.

Just declare the previous working state, and the cluster will be synchronised.

  • Cluster disaster recovery

When for example we use an EKS and it crashes, we can create a new cluster and point it to the git repo where the full cluster configuration is defined.This way we get the exact same state as the previous one without any intervention from us.

This is because we have described the whole cluster in the code declaratively, and from this Argo cd gets the appointment of a declarative fool for continuous delivery. 


At this point, we are satisfied that Argo CD makes improvements to the cd pipeline and makes it more efficient. Obviously, there are several other solutions to do this, such as Flux, and although they both follow the same path, there are differences between these tools. We can choose which one is more appropriate depending on certain features such as flexibility in code collaboration, what you need to manage and what is automatically offered by the tool, etc.

Do you have a cloud project?