One of the feature provided by Jenkins X is to rely exclusively on GitOps to manage environments. Let’s talk about this practice. As promised, I’ll illustrate this blog with my own drawings.

Developers and Ops used to be considered a separate group of people based on distinct mindset. Developers always want to change everything for latest hype technology, while Ops pamper production and reject any unproven change. This is a terrible cliché, but reflect a reality in the way work is managed.

“classic” Ops

Both Developers and Ops have to track their work. They rely on a task/issue tracker for this purpose, managing priorities, assignments, dependencies and estimates. A major difference on Developer side of the universe is that those have been using Source Code Managers (i.e Git) to manage changes, providing audit and reversibility on projects’ code base.

Ops work has heavily evolved within recent years, and Infrastructure-as-Code fundamentally changed the way Ops do manage production. With automation of infrastructure management and application deployment, the whole system can be controlled by plain config files, stored in Git.

GitOps is an extension of this approach. It enforce any change to configuration has been validated by Ops rules. A typical implementation, as provided by Jenkins X, is to have dedicated Git repositories to manage environments configuration, and to rely on a validation pipeline for proposed changes. Just like a developer uses a pull-request to propose changes on the code, and get the project built, tested, checked by various QA tools, environments configuration managed in a GitOps repository will be updated using pull-requests. Associated pipeline will then validate the configuration is consistent and match governance rules. When PR get merged, another pipeline will apply the configuration to the target environment.

This workflow has many benefits

Changes to configuration is guaranteed to respect all governance rules establish by Ops team. Those can for sample require artifacts being deployed on production to be signed and checked by security tools. Like developers would configure Git repository so that push to master require a successful pull-request CI build, GitOps repository permission can be configured so that only a validated pull-request can be merged.

Sounds like “déjà vu” ? Actually, some people consider GitOps as yet-another-buzzword. The name suggests the primary component is Git. But team using Chef/Puppet/Ansible for years all store the configuration in SCM. Does this mean they already do GitOps ?

GitOps ?

GitOps actual force is to add automation on to of SCM-managed infrastructure and configuration-as-code. Automation applies changes from GitOps repository, so no human being need credentials to access production servers. Humans are subject to failure, aren’t they ? This enforce security and stability rules.

Compared to some existing deployment management tools, automation here doesn’t need to be highly clever and sophisticated to handle complex workflow and permissions: Once some changes have landed in the master branch of an environment, those are applied to the matching target. The whole process of managing permission, review, authorization and audit is handled by Git repository.

Creating pull-requests on GitOps repositories also can be automated. So does Jenkins X. As changes are pushed to project’s master branch, Jenkins X open a pull-request on staging environment GitOps repository, and automatically merge this PR for staging environment to reflect latest version of the application.

Propagating changes from one environment into another is just a question of creating a pull-request. Promotion in Jenkins X is using this approach, applying recent changes from staging environment into production via a pull-request.

In just few words, GitOps is a smart combination between automation and infrastructure-as-code. It brings a higher level of confidence with changes management, and as such unlock some remaining barriers to continuous delivery.