Ops Moving At Git Pace

DevOps, NoOps, DevSecOps… there’s been a lot of different things to come out of our DevOps boom in the last decade. DevOps continues to help companies grow by reducing silos, producing quality documentation, communicating and finding smarter ways to deliver their companies software needs. A chance encounter recently got me thinking about how DevOps continues to grow at big and small places. I recently ran into a friend at a Kubernetes Meetup who was telling me about their new job. This person is now responsible for a ton of code and its deployment for a fairly popular website.

“So how do you do the CD/CI portion and deployment?” I asked.

“Well we’re doing GitOps via the built-in tools we have in GitLab,” he responded.

This is a huge shop doing tremendous deployments for a website that many of you will depend on.

GitOps — what is it? Simply put, it’s Ops via Git pull requests. It’s putting operations tools in the hands of developers by automating processes that really used to take many hands.

WeaveWorks shared this blog post in August of 2017 that really helped define how they used this process to manage their deployment of Kubernetes. To me, using Git as a “source of truth” is brilliant for a few reasons:

• You ensure great practice of revision control on the changes you want to implement in your infrastructure.
• Document your changes more easily using native README.
• Use pull requests to serve in change management to approve or to decline change.
• You can create tests for your infrastructure code, even if it’s yaml. Run something like kubeval to lint your Kubernetes config files.
• Connecting your change management process to something like Github Issues or just using branches connected to something like JIRA tickets.

These are just a few good ideas I think are out there for using this method to manage your infrastructure. If you think about it in the modern method of managing “infra-as-code,” this process can really be used with almost any of the big orchestration software options there are. I can easily see using a series of git-based hooks after tests are accepted to update code to master from the branch I was deploying and then running something like “chef-client” on my systems.

Your git repository can also be your “source of truth.” You can deploy after your PR is merged. All part of breaking down barriers and promoting a DevOps idea of handling your systems.