GitOps Workflow vs. Traditional Workflow: What Is the Difference?

Article Content

What Is a GitOps Workflow?

GitOps is a set of best practices that makes the development workflow simpler, more efficient, and more consistent. It describes all changes to applications and infrastructure using code checked into a source control system, and automatically synchronizes these changes with a live environment. 

The GitOps workflow is the process by which software updates and deployments occur, which differs from the traditional continuous integration / continuous delivery (CI/CD) process:

  • In a traditional CI/CD workflow, developers commit new code changes to version control, the CI server runs automated tests, and if the changes look fine, pushes the changes to a container image repository. An automated deployment tool then deploys the new container to production.
  • In a GitOps workflow, the CI process is exactly the same. From the deployment onwards, things work differently. When a new container image is available, a GitOps agent identifies the new container image, checks if it exists in the cluster, and if not, replaces the old version with the new.

The key difference is that while the traditional workflow is based on “pushing” new code changes through the pipeline to production, a GitOps workflow is a “pull” process in which new changes are submitted, and the GitOps agent detects them and synchronizes them with the production environment.

Traditional Workflow vs. GitOps Workflow

The continuous integration component is at the pipeline’s start in a traditional environment. The CI component interacts with version control systems acting as a service providing the input to create operations, while the continuous development component acts as the service deploying the code. The pipeline uses CD automation to pass the code through an automated test suite and push the approved code to the production environment. 

In a traditional workflow:

  1. A developer writes code and commits it to a version control system (VCS).
  2. The CI server runs an automated test suite on the code.
  3. If the server finds bugs or errors, the build fails and developers are notified.
  4. If the server approves the code, it automatically pushes it to the container image repository.
  5. An automated deployment tool pushes containers to the production environment.
  6. The team manages the containers using a container orchestration tool. 

In the traditional workflow, the CI component is at the core of this CI/CD pipeline, but in GitOps, the VCS Git is at the center. A GitOps architecture allows developers to leverage Git as the single source of truth to manage IT infrastructure operations. Git directly manages the operations and deployments. Most developers are already familiar with Git workflows and pull requests, so it’s easy to adopt GitOps. Pull requests are review requests where the developer pushing the code to a repository requests the system to merge the code’s approval with the repository.

In a GitOps workflow:

  1. A developer writes code and commits it to a version control system (VCS).
  2. The CI server runs an automated test suite on the code.
  3. If the server finds bugs or errors, the build fails and developers are notified.
  4. If the server approves the code, it automatically pushes it to the container image repository.

Until this point, GitOps is identical to a traditional workflow. Now it gets interesting:

  1. A deployment automator identifies the change to the image repository and pulls it from the registry, updating the YAML file in the configuration repository. 
  2. A GitOps agent identifies a change in the cluster and pulls it from the configuration repository, updating the cluster with the relevant changes. 

Related content: Read our guide to GitOps vs. DevOps

GitOps Workflow in Detail

GitOps is an Infrastructure as Code (IaC) evolution that leverages Git as a version control system for configuring infrastructure. IaC workflows often involve a declarative infrastructure management approach, defining a system’s desired target state and then tracking its true state.

Like IaC, GitOps requires a declarative approach to define the system’s desired state. Declarative tools allow GitOps teams to version control all of their source code and config files in Git. Typically, an external event triggers the CI/CD pipeline (e.g., a developer pushes code into the repository).

Teams can roll out new releases by making pull requests in Git, which changes the relevant cluster’s declared state. A GitOps operator between the orchestrator and the GitOps pipeline picks up new commits and pulls the new state declarations from the Git repository. Once the team approves and merges the changes, the system automatically applies them to the live infrastructure. The developers can keep using their standard CI/CD practices.

When using Kubernetes in a GitOps workflow, the operator is usually a Kubernetes Controller. This operator compares the target state in the Git repository to the deployed infrastructure’s current state. It updates the infrastructure if it detects divergence between the desired and actual state. The operator also monitors the container image repository, applying updates when the team deploys new images.

GitOps requires observability—i.e., the ability to observe the system. It allows GitOps teams to ensure that the observed actual state of an image or container matches the desired state in the repository. Using Git as the VCS and pull requests provides visibility into the deployment pipeline, allowing team members to track changes to the system, conduct audits, and apply rollbacks to breaking changes.

The GitOps workflow increases the development pipeline’s productivity and velocity while guaranteeing the system’s reliability and stability. 

Related content: Read our guide to GitOps in Kubernetes

GitOps Workflow Example with Argo CD

Argo CD is a GitOps tool implemented as a Kubernetes controller that continuously tracks applications and compares their current state to the target state defined in a Git repository. When it detects that a deployed application’s live state deviates from its desired state, it marks the application as out of sync.

The central Git repository should contain the full record of all configuration changes, including environment details adjusted for each stage of the development process.

Argo CD executes the later GitOps stages and ensures the correct deployment of new configurations to Kubernetes clusters. It is a Kubernetes-native tool for implementing continuous deployment. It differs from external CD tools, which only support push-based deployment because it can pull the updated code from a Git repository and deploy it directly to a Kubernetes resource. 

Argo CD allows developers to manage application updates and infrastructure configurations in a single system. 

In a (simplified) Argo CD workflow:

  1. A developer creates a new feature in the source code Git repository.
  2. The CI system picks the source code change, packages the code, and runs unit tests or security scans as needed.. 
  3. The developer makes a pull request and automatically or manually changes the Kubernetes manifest, stored in a separate Git repository that holds only Kubernetes manifests.
  4. The GitOps team reviews the pull request and merges approved changes to the main branch, triggering a webhook that notifies Argo CD of the change.
  5. Argo CD copies the repository and compares the desired application’s state with the Kubernetes cluster’s current state, applying the necessary changes to the cluster configuration.
  6. Kubernetes controllers reconcile the required changes to the cluster resources until it reaches the target configuration.
  7. Argo CD tracks the change’s progress and reports the application as “in sync” when the cluster matches the desired state.
  8. ArgoCD can also work in the opposite direction to monitor changes to the Kubernetes cluster, rolling them back if they do not match the current Git configuration.

Codefresh: The GitOps Platform Powered by Argo

Codefresh is a complete software supply chain to build, test, deliver, and manage software with integrations so teams can pick best-of-breed tools to support that supply chain. Codefresh unlocks the full enterprise potential of Argo Workflows, Argo CD, Argo Events, and Argo Rollouts and provides a control-plane for managing them at scale.

Codefresh provides the following key capabilities:

Single pane of glass for the entire software supply chain

You can easily deploy Codefresh onto a Kubernetes cluster, run one command to bootstrap it, and the entire configuration is written to Git. By integrating Argo Workflows and Events for running delivery pipelines, and Argo CD and Rollouts for GitOps deployments and progressive delivery, Codefresh provides a complete software lifecycle solution with simplified management that works at scale.

Built on GitOps for total traceability and reliable management

Codefresh is the only enterprise DevOps solution that operates completely with GitOps from the ground up. Using the CLI or GUI in Codefresh generally results in a Git commit. Whether that’s installing the platform, creating a pipeline, or deploying new software. The CLI/GUI simply acts as extended interfaces of version control. A change to the desired state of the software supply chain will automatically be applied to the actual state.

Simplified management that works at scale

Codefresh greatly simplifies the management and adoption of Argo. If you’ve already defined Argo workflows and events, they will work natively in Codefresh Software Delivery Platform. Codefresh acts as a control plane across all your instances—rather than many instances of Argo being operated separately and maintained individually, the control plane allows all instances to be monitored and managed in concert.

Continuous delivery and progressive delivery made easy

Those familiar with Argo CD and Argo Workflows will see their configurations are fully compatible with Codefresh and can instantly gain value from its enterprise features. Those new to continuous delivery will find the setup straightforward and easy. The new unified UI brings the full value of Argo CD and Argo Rollouts into a single view so you no longer have to jump around between tools to understand what’s going on.

The World’s Most Modern CI/CD Platform

A next generation CI/CD platform designed for cloud-native applications, offering dynamic builds, progressive delivery, and much more.

Check It Out
Related GitOps articles