From Zero to the GitOps — Part 1

A series of articles about GitOps

GitOps operations by pull request, git as a source of truth

What exactly is GitOps? Using Git as our source of truth, we can operate just about anything. For example, version control, history, peer review, and rollback take place in Git without having to touch tools like kubectl.

• The provisioning of Cloud resources, third party services and the deployment of k8s could be declarative
• The entire state of the system is under version control and described in Git repositories
• Operational changes are made on merge requests (in addition to build and release pipelines)
• The Diff tools detect any divergence and notify us via alerts; synchronization tools allow convergence Reversal and audit logs are also provided via Git
• The monitoring and alerts could be created as a code level.
• The Security layer could be implemented as a code.
• The code itself is the documentation of the environment

It is not about centrally managing the infrastructure/operations, having specific engineering teams to take care of operations, this is a bottleneck, in addition to having more risks and less knowledge dissemination, it is more difficult to obtain a continuous improvement process, we have to understand that in a self-service culture there can be no distinction between development, operations, testing, security, everyone may be able to create, or even change, we will have squads or teams that are more specialized in a given subject, but everyone can be able to propose and create improvements. Just as software development has evolved rapidly over the past few decades, think that infrastructure/operations configuration management needs to follow the same path to evolve quickly, that is, reusing infrastructure code is very important to obtain a process of continuous improvement, using pipelines, git flows, well-defined processes that can be improved through a pull request, so anyone on the team who is part of that product, environment, solution, can request a change, make a change, going through the review and process approval of others, and having great discussions on the subject in the comments of the Pull Request, and when approved we have tests and more tests that validate this change of infrastructure of the environment until delivery is the path to a continuous improvement process because we can easily have metrics and measure step times and always improve our lead time. The SRE team needs to create this process together with the other teams, develop self-service strategies so that engineers can achieve the continuous improvement of a certain product, they must be able to create and maintain items such as Pipeline as Code, Configuration as Code, Infrastructure as Code, Observability as Code.

Everyone is allowed to create/modify whatever they want in the environment, to ensure standards and things do not get out of control because everyone is allowed to create, modify, we create review strategies based on changes in specific directories (code owners), and the need approval by another engineer, in addition to pipelines with steps that guarantee quality delivery.

Another example is that you need to create and recreate or maintain hundreds of similar, but distinct environments, if we were to think of code in some programming language a good practice is DRY (Don’t repeat yourself), so we use dependencies and make references to libraries and code that is created by other developers, this is the essence of Open Source, the same applies to infrastructure/operations code, the less I repeat code the leaner my infrastructure/operations code is, the easier it will be maintained, test, modify. In addition to using components that are maintained by several people around the world and that is always in constant evolution, the time of the convergence is fast because we can apply the operations code for all environments, after tests, or if want to apply the new version of the infrastructure only for a part of the environment.

These are just examples of how GitOps can leverage your continuous improvement process. In this series of articles, I will describe and give examples of some technologies in which I have the experience to arrive at an effective GitOps strategy, I will give an overview of the technology and practical examples of how to implement it. The series will be divided into 7 parts, described below:

• Pipeline as Code
• Infrastructure as Code
• Configuration as Code
• Continuous integration
• Continuous Delivery/Deployment
• Security as Code
• Observability as Code

Git has advanced the state of the art in development. A decade of best practice says that the configuration is code and the code must be stored in version control. Now it is bringing this benefit to Ops. Now we’ve found that we’d rather fix a production problem with a pull request than make changes to the running system.

None of this matters unless it makes it easier to understand and use application clusters. GitOps practices have made Kubernetes and native cloud applications much easier. I really think you will find that too. The tools themselves are very simple. And you can quickly reach a process of continuous improvement.

So that’s it, until the next article that will be about Pipeline as Code. Hugs.