You have written a new Web application and would
like it to be added to your organization’s Web load
balancer. The load balancer is complex; highly trained
experts on the network operations team maintain its
configuration. You file a ticket with the team, wait,
wait, wait, have a discussion with the experts, wait,
wait, wait, and finally your request is completed. Your
application is now available, assuming they got it right
on the first try.
At other companies the process looks more like this:
1. Find the Git repo that stores a logical description
of the plumbing that connects the load balancer to
various Web application servers.
2. Edit that file to add your new application.
3. The proposed revision is submitted to the Web
team as a pull request (PR) the same way developers
submit PRs for software projects.
4. At the same time that humans are reviewing
the PR, your continuous integration
(CI) system (such as Jenkins or similar)
is linting and unit testing your changes
to the load balancer config (possibly in
a container or VM).
5. Once the PR is approved and “the
builds are green,” the continuous
deployment (CD) pipeline (often another Jenkins job or similar) will take
care of generating the new config file
for the production load balancer and
deploying it, usually with the help of
a config management system such as
Puppet or Chef.
This kind of workflow is known as
GitOps: Empowering users to do their
own IT operations via PRs.
GitOps lowers the bar for creating
self-service versions of common IT (or
site reliability engineering, or DevOps)
processes. As the bar is lowered, it be-
A Path to More
Article development led by
IaC + PR = GitOps
BY THOMAS A. LIMONCELLI