GitOps has the following key principles:
- It describes the entire system declaratively: Having declarative code forms the first principle of GitOps. This means that instead of providing instructions on how to build your infrastructure, applying the relevant configuration, and deploying your application, you declare the end state of what you need. This means that your Git repository always maintains a single source of truth. As declarative changes are idempotent, you don’t need to worry about the state of your system as this will eventually become consistent with the code in Git.
- It versions desired system state using Git: As Git forms an excellent version control system, you don’t need to worry too much about how to roll out and roll back your deployments. A simple Git commit means a new deployment, and a Git revert means a rollback. This means you do not need to worry about anything apart from ensuring that the Git repository reflects what you need.
- It uses tooling to automatically apply approved changes: As you’ve stored everything within Git, you can then use tooling that looks for changes within the repository and automatically applies them to your environment. You can also have several branches that apply changes to different environments, along with a pull request-based approval and gating process so that only approved changes end up in your environment.
- It uses self-healing agents to alert and correct any divergence: We have the tooling to automatically apply any changes in Git to the environment. However, we also require self-healing agents to alert us of any divergence from the repository. For example, suppose someone deletes a container manually from the environment but doesn’t remove it from the Git repository. In that scenario, the agent should alert the team and recreate the container to correct the divergence. This means there is no way to bypass GitOps, and Git remains the single source of truth.
Implementing and living by these principles is simple with modern DevOps tools and techniques, and we will look at practically implementing them later in Chapters 11 and 12. In this chapter, however, we’ll examine their design principles using a branching strategy and GitOps workflow.