Announcing: Git Sync for Harness Feature Flags
Native Git sync for Feature Flags is here! Read all about it - and all about how it'll make your life easier.
We’re thrilled to announce the introduction of native Git sync for Harness Feature Flags. Users of Feature Flags who prefer to work in an “infrastructure as code” way - or flags as code in this case - or 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 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. There are certainly scenarios where one or the other is easier!
If we think, too, 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! But, that topic (APIs) is something for the near future ;).
Within Harness, we have a concept called a Pipeline. This is essentially 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 Git Sync: 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, commit those changes to Git, and then have it be automatically reflected in the Harness UI.
This isn’t a novel concept in Harness - we’ve been allowing users to build visual pipelines as well as 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.
How to Get Started
If you’re already a Harness Feature Flags user, 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!
If you haven’t signed up to use Harness yet but want to get started, you can easily sign up for a free trial. Happy developing!