Linus Torvald, one of the godfathers of Linux, after some source code management shakeup on the platform hosting certain Linux projects, wanted a better way for source code management for Linux projects. Thus, GIT was born in 2005. GIT falls under the category of SCM or source code management tooling. Since a lot of software projects today leverage a GIT implementation as the source code management solution, engineers interacting with the SCM is a good event/flag for automation needing to kick off — thus the dawn of GitOps.

GIT is that OctoCat?

If you are just starting out with GIT, a cursory Googling would reveal GitHub as one of the top search results. Folks tend to equate GitHub with GIT; GitHub has done an excellent job branding with its iconic OctoCats.

There are several GIT providers such as GitHub and GitLabs. If you are using your MacBook and have XCode installed, GIT comes along with the XCode install. With this large install base, GIT is pretty platform-agnostic and ubiquitous in the developer ecosystem. Interacting with an SCM system is a pretty good flag that action needs to occur.

All in a Commit [Or Pull / Merge Request]

Today, we can expect as software engineers that every time we commit, we are potentially having a release candidate in our pipeline. To get to that level of automation, having a pipeline robust enough to handle that is no small task. Our SCM solutions are viewed as system or records/truth, the primary mechanism for the code that we and our team(s) have written to start getting into the wild.

The basic premise is that some sort of hook is there. Even if your team is not using GIT as the SCM solution, Subversion has hooks that center around the commits. Depending on if you are using GitHub or GitLab, the mighty Pull Request — aka PR in GitHub or Merge Request aka MR in GitLab — is the mechanism.   

Purest GitOps – Focus on Ops

The GitOps movement has certainly picked up a lot of momentum recently and been garnering participation in the CNCF — for example, WeaveWorks Flux as one piece of the GitOps puzzle. The level of automation and codification needed to get from a commit/PR/MR to a deployed application requires a bunch of declarative steps/platforms when looking at a purist definition of GitOps.

Our applications certainly require infrastructure to run; we don’t run in a vacuum.  If we are leveraging a JAVA Stack, dependency management/build tools like Maven or Gradle command are obvious next steps after a commit.

Those might even feed into a Docker Compose if you are containerizing your environment.

After you have the artifact or artifacts, this is where the complexity curve starts to trend upwards. We have this amazing artifact that you and your team created into environments and infrastructure that might exist or might not be depending on how close to deployment you provision infrastructure.

With application infrastructure, this is where the declarative importance comes in. There might be multiple pieces to the deployment in specific steps. Your to-be platform might be a Platform-as-a-Service or a flavor of Kubernetes from a cloud vendor e.g GKE/EKS. Like learning the order of operations in elementary school math class, the order is important when we are aiming for these declarative end states, and validating each step is important. This is the operations piece that can get complicated quickly.

Modern Complexities

Minus the SCM complexities around repository models and general flow to commit and merge, let’s pretend we have an artifact in our hand. Here at Harness, we are adding a new stateful service endpoint, /KungFuCanary in this example.  

We need to register this service with our API Gateway, deploy an appropriate number of pods to Kubernetes, ready our  Redis cluster for additional capacity, prep our Kafka brokers for the new topic, and for fun carve out a new Istio route for Kung-Fu-Canary. Back to the order of operations, to tackle the bootstrap question we need to ready the persistence stack, networking stack, then the application stack in that particular order. Plus each one of the pieces has a rolling upgrade or even a canary strategy for the actual deploy which we have to bake in. All of this from a commit/merge? Wowzers.

Not only this has to happen from a commit/merge, but it is also commonplace for us software engineers to revert. How many times have you reverted a commit? How do we undo what we just did or rollback? With all of this complexity, to have each of these moving pieces into declarative states and managing the success/failure of each one, why even get started?

Your Own Flavor of GitOps

If the above example is complicated or seems out of reach for you and your team, don’t fret. A solid MVP would be making sure all the systems are tied together. The first thing to take out to make this simpler is the infrastructure.

If the application infrastructure is there awaiting, let’s say we are just deploying to WildFly Server in a JAVA example; having the build plug-in to a Maven Deploy to an awaiting WildFly instance from a GIT Hook or a Subversion Hook, you are well on your way to GitOps in principal.

Once you get the taste of your GitOps or GitOps-esque journey of deploying a binary, now start to add back in the complexity. There are several moving pieces to take into accounts such as infrastructure creation or repurposing, pipeline definition in terms of stages, workflows and release strategies (e.g. canary), verification strategy, auditing/ticketing/notifications, and failure/rollback strategies.

GitOps does not have to be tied down to a specific provider, tool or technology stack — for example, Kubernetes on a public cloud provider. The scope of GitOps should encompass your entire software delivery chain.

Super Charge your GitOps Dreams

Harness can help supercharge your GitOps dreams and help bulk up your existing pipelines or even create your first pipeline. Let Harness take care of the tougher complexities around deployment strategy and rolling back The beauty of the Harness platform is that the platform steps are repeatable and consistent.

We have a more detailed example about Pull Request Driven Development where the rubber meets the road here at Harness. We are excited for you to take a spin in the Harness Platform and “Force Push” (okay, maybe not force) your pipeline today!


Keep Reading

  • The Women of DevOps: Patricia Anong

    The Women of DevOps: Patricia Anong

    Meet Patricia Anong, DevOps Consultant. We're thrilled for you to meet her!
  • Introduction to Helm: Charts, Deployments, & More

    Introduction to Helm: Charts, Deployments, & More

    Probably one of the first packages installed after your Kubernetes cluster is up and running is Helm. A stalwart in the Kubernetes ecosystem, Helm is a package manager for Kubernetes. If you are unfamiliar with Helm, Helm helps users to have a more consistent deployment by packaging up all of the needed resources needed for a Kubernetes deployment.
  • GitOps Got Me Up

    GitOps Got Me Up

    Two years ago, I joined the technology space - and as such, I am now a strong proponent for DevOps methodologies.