So what is GitOps you may ask?

Firstly, I wouldn’t say that GitOps is a particularly new concept. GitOps is more of a re-badging of some existing processes that are combined together. The main idea behind GitOps is that it gives us a way to empower developers so that they are able to do some of the operations that used to be handled by some IT/Ops or DevOps people. GitOps lets us describe the systems, stacks or environments as code so that they can easily and repeatedly be deployed for development, testing and production.

A great equation to GitOps I have seen that describes GitOps is the following.
GitOps = IaC + PR + CICD
Now all those acronyms may not mean much to you but what its actually saying is that GitOps is the combined operations of Infrastructure as code, Pull requests plus continuous integration and either continuous delivery/deployment.

• IaC or infrastructure as code in terms of GitOps is when you have a repository that contains all the code that’s needed to define the full stack / infrastructure. Version control ( most likely git ) tracks the changes for how the stack should look.

• PR or Pull requests in terms of GitOps is when you use the pull requests or branch management as a hook for all the infrastructure changes that are made in the IaC repositories, by using the pull request as the hook this can be done post a formal code review or any other gating process you may have in place.

• CICD or continuous integration continuous delivery/deployment in terms of GitOps is when we use CICD pipelines to deploy the infrastructure changes once the PR process dictates the changes can be made.

If infrastructure as code interests you then checkout my article on AWS CDK, CDK is by far my favourite way to develop and maintain infrastructure in the cloud.

Self service is key

In traditional infrastructure deployments these are normally managed via a ticketing system, this would involve the developer putting in a ticket, for example to create a new environment for an issue to be tested, this ticket would usually not be reviewed in a timely manor with developers often having to wait up to a week to compete some work that may only take a couple of hours. This often means that the fix maybe put into production without the full testing that we would like to see before such a change is made.

This is why in GitOps self service is key! The development team should be able to create an environment themselves that would match any desired state that is needed ( Prod, Pre Prod, QA, Master, Branch_1234 ). This will result in the developer not having to change what they are working on while another team prioritise creating the developer an environment that may only be used for a number of hours.

Benefits of GitOps

This automated manor of creating environments ( or a specific sub systems ) has a number of huge benefits.

• Empowering developers, as mentioned above GitOps can empower the developers to spin up what infrastructure they need when they need it. This can also help reduce friction in large teams that always have conflicting priorities.
• Simplicity, the overall process is automated reducing the complexity in building and deploying stacks and reducing the overall project or task risk.
• Consistency, with GitOps a developer should be able to spin up x number of environments in a repeatable manor. If these environments are all based of of the same IaC commit then the environments would be identical in behaviour. This also means that developers should not see any surprises when deploying to production stacks.

Conclusion

Overall I would conclude that if you have a medium to large team or teams that are not cross functional, not including developers and DevOps / team members responsible for the infrastructure, then I recommend you look into how you can create a GitOps culture within your organisation.
With smaller cross functional teams GitOps often matters less as the developers will have free access to the team member who will bring them up a stack and this will often be done almost immediately when needed, however I would still always recommend that the member responsible automate and use IaC to maintain the environments just skipping out the PR section of GitOps.

Categories: Developer Chat, Productivity

Tags: AWS, Developer, DevOps, Git, GitOps, IaC, programming, Software