GitOps Use Cases You May Not Have Considered – InApps Technology 2022

GitOps is growing in popularity. You’ve probably seen it mentioned on Reddit or dev.to. But what the heck is GitOps?

Broadly speaking, GitOps takes the principles of Git and CI-powered workflows favored by software developers — commonly used to automate the process of building, testing and deploying software — and applies them to other business processes.

For example, cloud infrastructure teams use GitOps with Infrastructure-as-Code (IaC) tools — like Terraform and CloudFormation — to simplify cloud infrastructure management. They love it, because it lets them reuse powerful developer tools to get their job done more efficiently.

But are there opportunities to use GitOps outside of software development and cloud infrastructure provisioning? Does it actually work for things that don’t involve code?

Benefits of GitOps

In a word, yes. You can potentially use GitOps in any workflow that’s centered around text — although that doesn’t mean you always should. New processes can add more complexity than they solve.

Fortunately, there’s no shortage of business processes that benefit from GitOps. If we look at the individual steps of a process, it’s easy to understand how they add value outside of software. Some of the benefits include:

• Change tracking: A Git repository holds a complete record of every change to the text files it contains — whether those files are code, configuration, documentation, or anything else. It’s easy to look through a repository and see what was changed, when, and by whom.
• Peer review: Changes typically aren’t pushed to the main branch of a Git repository. Instead, changes are pushed to a branch or fork, a pull/merge request is created, and the changes are reviewed by someone other than their creator before they are approved and merged.
• Versioning: Git tags can be used to mark a specific commit as important. If, for example, you are using GitOps to help write a book, you could create a tag every time you sent a copy to the publisher for review.
• Easy rollbacks: If, for any reason, you decide you don’t like changes you’ve made, it’s easy to roll back to an older tag or commit.
• Testing: Developers typically use the CI part of GitOps to run unit and integration tests. But testing can be useful in other contexts. If you’re using IaC, you can run automated verification on Terraform configuration files to make sure they’re valid. If you’re writing documentation or literature, you may want to add automated spelling and grammar checks.
• Build and deploy: These may seem software-specific, but if we’re creative we can envision ways to use them for other tasks. For example, you may want to “build” documentation by transforming it from Markdown to HTML. Or you might “deploy” a book you’ve written by automatically uploading it to a Dropbox account shared with your publisher.

Edge Cases for GitOps

With these benefits in mind, let’s look at some edge cases where GitOps is a good fit — even if it’s not commonly used yet.

Writing Books

If you’re writing a book, GitOps might be exactly the workflow you’ve been looking for. Books are a good fit for Git because they’re nearly 100% text-based. And lightweight markup formats like Markdown and AsciiDoc offer features like titles, headings, lists, links and images; all while remaining plain text-centric.

When you’re done writing, your GitOps pipeline can automatically test your text files by running spelling and grammar checks; and then build them into multiple book formats, like HTML, ePub and PDF. As mentioned above, you can even deploy the finished book into your publisher’s cloud drive when it’s ready for editing and publishing.

Static Websites

Static sites dominated the internet in the 90s, and they’ve made a comeback in the past few years due to their performance benefits. If your site is content-based, like a blog, it’s much quicker to serve up a static HTML file than to make a database call (or several) to generate dynamic HTML.

It might not seem like static sites need GitOps. After all, if they’re just static HTML, can’t you avoid complexity by simply copying the files to the server and calling it a day?

Unfortunately, static sites aren’t as simple as they used to be. They often start out as a set of Markdown files, so that the site’s pages will be easier to edit than raw HTML. So you’ll need at least one build to turn your static site into something you can publish.

But that’s not all. If your static site has images, you’ll likely want them available in multiple sizes — to ensure that your site looks good on devices with widely varying screen sizes and pixel densities. You may even want images available in multiple formats — such as JPEG, Webm and HEIC — to ensure that all web browsers can download the most optimized format they support.

So at minimum, your static site needs a build step to convert its pages into clean, minified HTML and ensure its images are fully optimized. Once you’ve gone to the trouble of compiling your site this way, you may as well let your GitOps pipeline copy the updates to your web server, too.

Contracts and SOWs

Contracts and statements of work (SOWs) might seem like an odd fit for GitOps. But in reality, Git’s great change tracking ability is ideal for both of them — along with similar legal documents — because they often undergo several rounds of changes before they’re finalized and signed.

In a typical scenario, a vendor presents a contract to a client. Next, the client’s legal department will read the contract, cross out or modify any terms it dislikes, and send the revised contract back to the vendor. After each round of revisions, the vendor can apply the changes via git commits and pull requests to ensure there’s a complete, easily viewable record of every change. It’s often easier to look at a series of git commits than to deal with complex change tracking in a word processor.

Even better, when each pull request is merged, the GitOps pipeline can run automated tests on the updated contract to check its spelling and grammar and then ensure it doesn’t contain any words or terminology that the vendor wants to avoid using in its contracts. The pipeline can even contain a build step that compiles the contract text into a final PDF to send to the client.

GitOps for Docs

GitOps edge cases aren’t just theory — GitOps is a great fit for product documentation and it’s commonly used for this purpose. Docs are similar to some of the other edge cases we’ve discussed. They can be created in Markdown, AsciiDoc or reStructuredText, and can easily be stored in a Git repository.

A CI tool can then watch the repository, and build and deploy a new version of any document that’s updated. The “deploy” step can be broad or granular, depending on how the documentation is distributed. If the docs are published as HTML, the deploy step could be as simple as uploading a single file to the cloud or an on-premises server each time a documentation page changes in the Git repo.

CircleCI’s docs are a real-world example of this creative use of GitOps. The docs live on GitHub and are automatically built and deployed via a CI pipeline.

How to Get Started with CI and GitOps

Let’s take a quick look at how to publish a static website with AWS S3 using GitOps and CircleCI. Traditionally, you’d use the AWS console or AWS CLI with the aws s3 cp or aws s3 sync command. Additionally, you would need to set up public access for HTML files to make your static website public, or use --acl public-read parameter when using CLI.

But if you already keep your website in a Git repository, you just need to set up a CI pipeline to use GitOps for this task. Otherwise, you will need to commit your files to a Git repository first.

In this example, we’ve stored a website in a GitHub repository named CircleCI-AWS-S3. The website has an index.html file and two CSS files. Rendering these files in a web browser generates the following view:

To set up the CI pipeline to deploy this website to S3, we first created an AWS identity and access management (IAM) user with programmatic access, and then generated the credentials. These credentials are needed later to let CircleCI access AWS resources. Next, we created the S3 bucket named db-aws-bucket in the us-west-1 region.

Since the website code is in GitHub already, CircleCI can see all of our projects:

To proceed further, we clicked Set Up Project, then provided the following config.yml:

The configuration is straightforward. It contains only one job — build — which first checks the source code, then uses an aws-s3 orb to sync the website folder (from repository) with the S3 bucket (s3://db-aws-bucket). This procedure is equivalent to calling the following AWS CLI command:

aws s3 sync website s3://db-aws-bucket --acl public-read

After setting up the pipeline, we used CircleCI’s Project Settings to type our AWS credentials and a default AWS region into the corresponding environmental variables (see figure below): AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_REGION.

At this stage, the pipeline should now run without any problems. The progress is trackable via the CircleCI portal:

After the deployment is finished, all the website files are visible in the AWS S3 bucket:

We can open index.html in a browser. The page will be publicly available:

What Is the Continuous Integration Advantage?

You might wonder why you would use continuous integration (CI) here since you can also deploy through the AWS CLI. The advantage is that the pipeline monitors your repository and will trigger automatically whenever you commit code changes to the main branch in your Git repository. So, you can focus on your code and deploy new website versions straight to the S3 bucket. For instance, if we make the following change to index.html:

<body class="heaven-15""heaven-23">

then commit the change to the Git repository, the CI pipeline will trigger. This will automatically replace the website with the new version:

We can now focus on developing our website without worrying about deployment. Everything happens automatically.

Next Steps

We’ve seen a few interesting edge cases for GitOps and we saw a quick example of GitOps in action, but we’ve just scratched the surface. If you get creative, you can apply GitOps to nearly any text-centric workflow.

CI adoption changes developer team culture. When it comes to developer team success, finding the right DevOps metrics to measure is crucial. Learn how to measure DevOps success with four key benchmarks for your engineering teams in the 2020 State of Software Delivery: Data-Backed Benchmarks for Engineering Teams.

Feature image via Pixabay.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Saturn.