10 years back, Puppet, an infrastructure and delivery automation company, published its first state of devops report. In all these years devops has completely transformed the way we design and deliver our systems. Advents like microservice architecture, Docker containers, Kubernetes, and practices like continuous integration and continuous delivery have made it possible to deliver secure, reliable, and stable software with high velocity.
However, devops has added its fair share to the complexities of managing infrastructure and applying changes to systems securely. Due to this reason, most of the companies got stuck in mid-level devops evolution. Having partial automation and not tying up the full cycle does not provide the efficiency that devops promises. The most common cause is having complex deployment cycles and detached configuration management. Git+Ops is the next holy grail that promises to reduce complexity, making deployment faster and giving power back to Developers and Operations.
Let’s know about some history of GitOps.
GIT and ever-changing OPS
Circa 2005, Linus Torvalds, creator of the world’s most widely used operating system Linux came up with a new version control system that was easy to use. It came to be known as GIT. Much to his surprise, a system he created for his own use quickly took over the world. As of January 2020 Github, the world’s most popular host of source code, reports having 40 million+ users and 190 million+ repositories (involving 28 million public repositories). Today, GIT is used not only for source code but for varied purposes like configuration files, keeping private files and blogs as well as keeping ebooks. Some of the features of GIT that makes it powerful are:
- Easily auditable
- Supports collaboration
- Easy branching
- Webhooks
- Free and Open source
Fast Forward to 2013, the world of software saw Docker and The Rise of Containerization. A wide array of systems to automate the management of containers, virtual machines and infrastructure cropped up. All of them had one thing in common: They all were dependent on human-readable and declarative configuration files rather than script/code snippets. Configuration files are the way users will declare the desired state, automation systems will then work to achieve it. GIT became the de facto place to store all these configuration files. Ironically we call it, Configuration as code. Devops world realized that there can be a single source for declarative infrastructure and application with strong collaborative features of GIT. That is how GitOps was born.
What is GitOps?
GitOps is a set of practices that enables developers and ops to declare the desired state of the system in a versioned and auditable manner via Git, which is then picked up by cloud-native automation agents and applied to the system. It empowers developers and ops to use the same, battle-proven workflows to manage large and complex deployment as well as infrastructures that we have been using for years to manage source code.
It is quick, hassle-free, and liberating!
Benefits of GitOps
- High velocity of deployments: With easy and quick changes in GIT, we can trigger automated workflows to do the deployment. This provides high velocity and increases development output. However, it saves teams from a lengthy deployment process and helps in cutting costs and increasing revenues
- Familiar workflow of Git: Git is the defacto standard for managing source code among developers. Familiar workflow of Git of creating a feature branch, making commits, creating a pull request gives developers and ops a very secure and easy to adapt the environment to manage infrastructure and application
- Git is the ultimate auditing and collaboration tool: Git has everything you need to do an effective collaboration. The concept of Pull request means authoritative figures in the team can always verify changes going to be applied to the system. Auditing becomes easy through historical data stored in Git commits
- Higher reliability: With Git’s capability to revert/roll back and fork, you gain stable and reproducible rollbacks. Because your entire system is described in Git, you also have a single source of truth from which to recover after a meltdown, reducing your Mean Time to Recovery (MTTR) from hours to minutes
Prerequisites for applying GitOps
In order to manage systems using GitOps based workflows, the following prerequisites have to be in the system:
- Systems have to be described declaratively
- The desired state of systems must be stated through Git
- Continues workflows(Continuous integration, Continuous Testing, and Continuous
- Deployment to name a few) should be designed and developed to apply approved and merged changes to the system automatically
- Change agents to detect the configuration drift, i.e. difference between the state mentioned in Git repo and actually a state of the system
How does GitOps work?
GitOps change to process have practically 3 steps:
- Developers create a request for changes in the system by raising a Pull request from their feature branch to the target branch (usually upstream branches)
- Once the Pull request gets approved and merged to the target branch of Git, the change agent detects a configuration drift in the system as the real state of the system and desired state of the system mentioned in git are now different
- Change agents will trigger related continuous workflows to achieve the desired state of the system
VOLANSYS have designed an elaborative GitOps based process to automate deployment to QA environments for one of our clients manufacturing home automation and security products. QA deployments are always multiple deployments in one. The client prepares release notes and pushes it in Github. This will trigger a Jenkins job and will scan through the required artifacts and their version. This further creates a map and based on the map it will update the versions in relevant helm charts, which are used for Kubernetes deployments.
We use Harness as our continuous deployment solution for the setup. Harness deployments to QA are configured to be triggered on GitHub webhooks. As we make the changes in Github repositories for helm charts, Harness will trigger the deployments, and Jenkins’ job will track those deployments and prepare a final report.
VOLANSYS designs continuous workflows having expertise in workflow automation, continuous integration and deployment pipeline, microservices architecture and dockerization keeping developers’ ease of work in mind. Our team of DevOps engineers ensure improving deployment frequency, yielding faster time-to-market, reducing failure rate of new releases, shortening lead time between fixes, and faster time to recovery for businesses using tools like Jenkins, Ansible, Terraform, Kubernetes, and more.
Read our success stories to know how VOLANSYS help organizations design automated workflows based on DevOps.
About the Author: Jeet Bavishi
Jeet is working as a Cloud and Devops technical lead with VOLANSYS past 2 years. He is a cloud solutions architect, having 7+ years of experience with expertise in designing, developing and architecting CI/CD, cloud and automation processes that directly impacts business outcomes. He also helps clients transform the culture and mindset required to push organizations towards Devops path.
