We are so happy to finally announce that GO Feature Flag v1.0.0 is released. 🎉 🥳 🚀

It was a long journey before this release but we are happy to propose you an even better experience with feature flags always keeping simplicity in mind and building a lightweight solution.

Our goal is still the same, we want you to experience the world of feature flags with a lightweight self-hosted solution.

With this new version you will now be able to enhance your usage of feature flagging with opening the creation of more complex and more advance toggles.

Earlier this week the super cool podcast Dev’Obs asked me to talk about feature flags, go-feature-flag and also the super nice initiative OpenFeature.

The podcast is in French 🇫🇷 (yes I know sorry…) but you can learn a lot of cool things, when to use them, what is OpenFeature about and all the cool things that the feature flags can bring to your developer experience.

Listen it here: https://www.listennotes.com/podcasts/devobs/devobs-24-feature-flags-rknRoFGL7N5/

When you build a new feature, orchestrating the actual launch schedule between the Product, Engineering, and Marketing teams can be challenging.

While it seems easy to launch something new, a poorly executed rollout can end up being your worst nightmare.

In this article, I will present to you how to use the Go module go-feature-flag to roll out your new features smoothly and help you be confident during the rollout phase. If you are not familiar with the concept of feature flags or feature toggles, I encourage you to read this article by Martin Fowler.

go-feature-flag is a Go module to easily manage your flags. You can refer to this article I wrote a few months ago to understand how it works.

I absolutely don’t think human/manual QA gates should be involved in between the writing of code and its being live. To avoid breaking things every time and to have an early cutoff system, you should use feature flags.

There are a lot of systems available on the market to manage your flags, like LaunchDarkly or UNLEASH, that have Golang support — but this option is expensive, and you have to host a server somewhere to manage your flags.

From this starting point, I came up with the idea to create a simple library with only one file in the back end. This file can be stored in different places (AWS S3, GitHub, an HTTP endpoint somewhere, etc.). This is the only thing you have to host — all the decision logic stands inside the Go module.