Announcing: GitOps for Harness Feature Flags

Authors:

Table of Contents

Announcing: GitOps for Harness Feature Flags

We’re thrilled to announce the GitOps workflow for Harness Feature Flags. Users of Feature Flags who prefer to work programmatically now have the option to manage their Feature Flags Pipelines entirely in a developer workflow without touching the UI.

Too Many Tools, Too Many UIs, Too Many Different Ways to Work

One of the biggest challenges for developers is dealing with the sheer number of tools in their workflow. And, to make things worse, there are multiple tools that solve specific problems, so from one role to another, there could be a vastly different set of tools. What’s common across all of this, however, is working in code.

As it turns out, the problem isn’t the number of tools in a developer’s toolkit, it’s the wide array of differences in how to use them, and, in particular, all of the different UIs. The reality is, while UI is important to make it easier to manage things, the day-to-day work that can also be done in the UI can often be done just as easily, if not more so, within code. This is the common workspace for every dev and platform engineer, and working in code many times just makes it easier.

To deal with this problem, a highly requested feature from dev teams is the ability to work in their own workflow (in code), and then have those changes and their impact be reflected within the tool’s UI. Developers want the choice between working in the UI and making changes in code.

If we think about how this applies to feature flagging systems, it becomes apparent that flags can be managed both in a UI and in code. While a UI can provide the ability to follow a wizard to create, edit, and manage flags, those same acts of creating, changing, and managing a flag’s targets can be done in code.

Harness’ Pipeline enables a release or deployment workflow that can be built to enforce standard process or templatize rollouts. You can learn more about Feature Flag Pipelines in this post. Similar to being able to manage the most basic unit of work within Harness Feature Flags (the flag), the Pipeline can also be handled in a UI. But, just like managing flags, can we make it easy to use the “language of deployment” and let developers work in declarative languages like YAML?

Enter GitOps for Feature Flags: Release Management In-Code

The solution to this problem is pretty much what you think it is. In addition to building, updating, and tracing Pipelines in a UI, we wanted to create the ability for users to use YAML syntax, commit those changes to Git, and then have it be automatically reflected in the Harness UI. This approach streamlines the release process.

This isn’t a novel concept in Harness -- we’ve been allowing users to build visual pipelines and work in YAML for years. This concept is core to the Harness platform, and now it’s made its way into Harness Feature Flags.

How It Works

Even for those who work in the UI, Harness, on the backend, creates the associated YAML files for a deployment or a release. This means that whether the UI is used, or a dev creates a YAML file from scratch, Harness can use it. And no matter where it’s created or updated, Harness will automatically keep them in sync – and you guessed it, in Git.

Ultimately, this means that Harness will always work off of the most recent version in Git – and did we mention it’s an almost-instant sync? A dev can commit a new YAML file into Git and then seconds later come to Harness and see the updates to their release workflow. Users also have the option to edit YAML files right within the Harness UI, giving them two ways in the UI alone to work with their Pipelines.

Of course, this applies to managing and changing flag states in code in addition to managing release pipelines. And none of these in-code changes will bypass preset rules or governance; they’ll all be validated via your defined flag pipelines.

How to Get Started

You can get more information in the docs if you’d like to learn more or follow detailed steps.

Head over to the product and right at the top, you’ll see the option to set up your Git Sync. Once you follow the wizard to connect the two, you’ll see which repo is hooked up, and whether it’s set to sync and auto-commit. These are the settings that will define whether to allow the GitOps flow at all, and whether to automatically allow the sync.

If you’re already using feature flag pipelines, you can head over to the product and you’ll see a menu item labeled “Pipelines” where you’ll want to start. At the top of your screen, you’ll see an option for “Visual” or “YAML” and you’ll want to select YAML. Unless, of course, you want to build out your pipeline visually first!