Two years ago, I joined the technology space - and as such, I am now a strong proponent for DevOps methodologies. Back in school, I remember sitting through software engineering classes where the professor would engrave into our brains, “waterfall bad, agile good” - but I had not realized to what extent - until I experienced why firsthand.
Over these two years, I worked on my fair share of projects where clients were stuck in the old, arduous way of developing software. The development team keeps their heads down building out a new feature, only to blindly lob it over to the QA team for testing, to then have it passed off again to the operations team for deployment. However, with the introduction and push to use DevOps (from either consultants or management), organizations now see the benefits of this ideology, as it promotes collaboration between these previously siloed teams.
Various best practices, such as GitOps, are emerging as DevOps as a whole gains traction across the industry. I believe that GitOps is the maturation of DevOps and will help pave the way to even more streamlined, repeatable processes. GitOps combines version control, where all the information is stored, and links it with automation so that the code can be deployed seamlessly into an OpenShift or Kubernetes cluster. This can be done for software development or for cluster management through an infrastructure spin up. GitOps provides a way to implement continuous deployment for cloud-native applications leveraging Git as the single source of truth.
The first time I worked with GitOps, I thought it was magic. I had a main repository that stored the application source code and configuration files, and a Jenkins pipeline that was hooked up to it. Once I committed new code and created a pull request, the pipeline sprung to life, slowly turning green as each step passed. Eventually, when the entire thing turned green, I clicked over to my OpenShift cluster to find my application deployed - just like that. I could not believe how seamless the integration was! After receiving code reviews and approvals, I merged my changes, which triggered yet another pipeline to be kicked off as the new changes needed to be automatically reconfigured and synced to the current live infrastructure.
With Git at the core of GitOps, a major benefit is that there is no need to learn yet another tool. At an amateur level, engineers are exposed and taught Git as a way to version control their code. This makes GitOps appealing, as it’s fairly easy to pick up. If you know how to commit code and create a pull request, you should be on your way towards a green pipeline. This also brings the code closer to the developers as they are pushing code rather than containers. The history functionality that is built into Git also adds great value in GitOps, and the ability to look at past commits allows for an extensive document of past environment changes. This makes it easy to roll back to a previous state if mistakes were made. With GitOps, there is no need to create random text files in your Documents folder with old configuration changes - and no need for backups!
Although GitOps may look like the shiny new toy that engineers are running towards, there are some drawbacks. Once you start creating multiple applications in multiple environments, you realize that it becomes hard to keep track of all the repositories because of the sheer amount of them. And on top of that, each repository has to have the right access and connections to the appropriate cluster. On the project I worked on, I found myself constantly switching between repositories trying to locate the correct one for the changes I wanted to make.
Also, there is no way to store secrets in Git. You can encrypt and decrypt them, but they are stored in the history forever. Therefore, it is advised to have a centralized secret management system. Believe me and take the advice. I learned this the hard way. I was off developing on my own branch, spinning up applications in my own project namespace on an OpenShift cluster, when I accidentally hardcoded in my password and pushed up my changes. Thankfully, I caught my mistake within a couple hours, but secret storage has always been a major pain point in using Git.
GitOps has emerged as a powerful and successful way to create continuous deployments for cloud-native applications and to create programmable infrastructure. Because of its potential, I believe it will soon be as highly recognized as DevOps.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.