What is GitOps?

GitOps is a set of best practices applied from the beginning of the development workflow, all the way to the deployment system for operating software.

Benefits of GitOps

The benefits of the GitOps approach for optimizing software development and the deployment process are important:

  • Increased developer productivity and an enhanced experience for teams
  • Minimize failed deployments
  • Faster time to ship features in production
  • Faster recovery from outages and unplanned downtime
  • Built-in auditing history
  • Greater visibility on the lifecycle of developed features

These benefits are applicable to both operators/service engineers, as well as developers who need a more robust operational solution for application development and infrastructure automation.

It is important to note that GitOps is not the next thing after DevOps or even DevOps 2.0.

GitOps is a set of deployment practices while DevOps is a paradigm or better yet, a mindset. Their shared principles make it easier for teams to adopt the GitOps workflow to already actively employed DevOps techniques. It’s a model developed on the pre-existing practices of Git workflows, CI/CD pipelines, IaC, tracking, observability, and immutable servers. You can adopt GitOps today with your existing tools while still following the DevOps mindset.

Existing challenges to deployments

Most existing processes for infrastructure configuration management face challenges like failed deployments, poor infrastructure design, server outages, etc.

Yet, those challenges can’t be solved by only the traditional approach of IaC (Infrastructure as Code) to manage today’s infrastructure. If you are already familiar with IaC then GitOps will be a natural fit for your organization as you can now handle applications in a similar way to how you are already handling infrastructure.

GitOps can help you with these common challenges:

  • Lack of configuration consistency. Even when using centralized configuration, the actual configuration and a declared one can alter and change with manual processes.
  • No idea how an application is running or where. Implicit infrastructure, its state, and configuration. This sometimes entails a full-scale investigation to determine these mysteries.
  • Failed deployments relying on a disaster recovery strategy. With both manual or semi-manual processes, disaster recovery requires a strict process that teams are disciplined to tackle, which isn’t always reliable. Resulting in unplanned downtime that takes away from developer’s skills and productivity.
  • Missing documentation or unknown development history. It can be difficult to figure out how some applications were built and who managed them.
  • Relying on a system’s previous state for success. This can be unpredictable, which affects the stability and state of a project.

Adopting the GitOps principles, can help you tackle these issues.

How GitOps works

GitOps is the evolutionary approach to continuous deployment that extends IaC and DevOps practices, leveraging Git as the “single source of truth”.

Developers already use Git for the source code of the application. GitOps extends this practice to application’s configuration, infrastructure, and operational procedures.

All changes (both on the application and on infrastructure level) are automated through the source control system that allows you to have a singular path using the single source of truth method. A GitOps controller is responsible for matching the Git state with your system state in a bidirectional manner (match the cluster to Git, but also detect changes to the cluster that are not part of a Git commit).

The basic characteristics of GitOps are:

  • Git is the single source of truth
  • Declarative systems and configuration
  • Immutable deployments
  • Cluster scaling with automation and synchronization, avoiding configuration drift
  • A central auditable changelog

The GitOps approach encompasses high-level principles used to strategize a cohesive workflow.

The basic principles of GitOps

  • 1. Declarative configuration

    By leveraging a declarative format, you can describe how your infrastructure works as well as the applications that are running on top of it. Doing this enables traceability of changes made to any environment and enables rollback, recoverability, and self-healing attributes using any source control system. Move away for imperative adhoc scripts to declarative configuration in all levels (app and infra).

  • 2. Version controlled, immutable storage

    Declarative descriptions stored within the repository supports immutability, versioning, and versioning history. For example, using Git for the declarations mentioned above, allows you a single place from which everything for your application is derived and driven. This allows you to easily pinpoint any changes made at any time. Don’t try to understand what is different between two environments. Just look at all changes found in version control history, having the guarantee that the platform always matches what is described there.

  • 3. Continuous reconciliation

    Operating in a close loop ensuring the desired state of a system matches the declared state. This is one of the most important features because it provides feedback allowing you and your team to better control your operations and workflow.

    When used with your repository, GitOps software agents can perform various functions, ensuring self-healing. Agents automate fixes in case there’s an outage, perform QA processes for your workflow, and protect against human error or a manual intervention.

  • 4. Automation via Git commits

    Another advantage of the declaration is ensuring the desired state in Git and then automating the system to apply all your approved changes to a runtime environment. Allowing teams to easily implement this strategy, allows them to achieve a declarative state that applications and their infrastructure can rely on. Clicking on various buttons in order to deploy stuff is no longer needed with GitOps.

  • 5. Auditing

    This practice enables an audit trail of any system change. The changes to the infrastructure are logged, leaving a trace for auditing capabilities such as rollbacks, troubleshooting, etc. This principle allows teams to view, record, and revert problematic changes. If you want to see what was deployed in your cluster last week you can always look at your Git history.

GitOps deployments

Existing challenges to deployments

Most existing processes for infrastructure configuration management face challenges like failed deployments, poor infrastructure design, server outages, etc.

Yet, those challenges can’t be solved by only the traditional approach of IaC (Infrastructure as Code) to manage today’s infrastructure. If you are already familiar with IaC then GitOps will be a natural fit for your organization as you can now handle applications in a similar way to how you are already handling infrastructure.

GitOps can help you with these common challenges:

  • Lack of configuration consistency. Even when using centralized configuration, the actual configuration and a declared one can alter and change with manual processes.
  • No idea how an application is running or where. Implicit infrastructure, its state, and configuration. This sometimes entails a full-scale investigation to determine these mysteries.
  • Failed deployments relying on a disaster recovery strategy. With both manual or semi-manual processes, disaster recovery requires a strict process that teams are disciplined to tackle, which isn’t always reliable. Resulting in unplanned downtime that takes away from developer’s skills and productivity.
  • Missing documentation or unknown development history. It can be difficult to figure out how some applications were built and who managed them.
  • Relying on a system’s previous state for success. This can be unpredictable, which affects the stability and state of a project.

Adopting the GitOps principles, can help you tackle these issues.

How does GitOps work?

How does GitOps work This diagram describes a CI/CD workflow for Kubernetes enabling the GitOps paradigm.
  • 1. The developer commits changes to the code in the Git repository that holds the application source code. Then, the container image is created and pushed to the container registry.

    Each application repository contains the source code that developers write to build an application. Developers can still work the same way as they worked before as far as the application logic is concerned. A commit always results in an artifact (usually a container image).

    The container registry is a collection of repositories that stores container images. A container image includes everything that the application needs to run.

  • 2. There is a second Git repository that holds deployment configuration for the application.

    In the case of Kubernetes, this includes the manifests that describe the deployment and other associated changes. Configuration files are written in a YAML format that includes the definitions of how to map external ports, directories, services, environment variables, and configuration options for the image. Essentially, the desired state of an application.

  • 3. Any change to the Git repository is monitored by the GitOps agent. Once a change is detected, an application (or infrastructure) deployment takes place.

    Requesting a change to the desired state of the cluster initiates automatic syncing with Argo CD or whatever tool you are utilizing to automate the state change. This step monitors the application and compares it to the current, live state against the desired target state, specified in the Git repository. The sync works both ways. If a change happens to a cluster (that is different from what is described in Git), it can be discarded or applied back to Git.

  • 4. The image is rolled out to the Staging/Production environment.

    You can handle multiple environments or clusters with GitOps. A common pattern would be to deploy to a staging environment first for running load testing or integration testing. This is an extra layer of reliability, making sure there’s no issues with the deployment prior to Production.

  • 5. Once the deployment completes a developer can test the application to verify it’s success and that the cluster state is the same as the Git state.

    This workflow is an example of how GitOps works. It’s a paradigm that can be applied to any cloud-native environment to manage infrastructure provisioning as well as software deployment.

Summary

GitOps is a powerful process and provides a workflow that can help you manage your cloud system infrastructure. It helps provide teams with multiple advantages: better coordination, transparency, stability, and also reliability for your system. Codefresh can be your automated platform that supports GitOps with Kubernetes and other advanced CD methods.

See how Codefresh helps GitOps

See how Codefresh helps you
deploy more and fail less!