Hey @graham.helliwell , thanks for reaching out and welcome to the forum!
You gave a lot of information and context around your approach (Which I appreciate!), I’m going to try and relate each of the important points in context with Octopus as a product overall.
Feature flags are definitely a very popular tactic for managing features that are in development. They make it easy to implement A/B testing, as well as keep non stable code safely built into the codebase without exposing it to users, which is incredibly helpful as teams try to become more and more agile with their deployment cycles.
The overarching concept here is that fundamentally, Octopus isn’t intended to be a tool for managing feature flags. This is due primarily to a lot of the things you outlined in your OP -
The convenience of being able to toggle a variable without going through the build process and all environments is key. But we need to be able to keep track of some settings and ideally actually move them through environments.
Octopus’ ultimate goal is to make a deployment easily repeatable and reliable. This is accomplished at the base level by creating release snapshots that dictate what the release should look like so it can be applied consistently to any and all other deployments of that release.
However, I do see where you’re coming from - it would be nice to be able to “branch” your deployment from an existing release to take advantage of the state of the variables at a known point in time. Unfortunately, that’s not how Octopus is built to function today. I did some local testing to see if it was possible to alter a Release after creation to update the ProjectDeploymentProcessSnapshotId
, LibraryVariableSetSnapshotIds
, ProjectVariableSetSnapshotId
properties to instead point to the sets from prior releases, but the API skips over those properties in the PUT request body.
Given the above, there are two general approaches you can take moving forward.
The first, and our current recommendation, would be to invest in a discrete feature flagging tool. LaunchDarkly is the easy one to recommend due to familiarity, but there are other options in the space as well, including CloudBees, Split, and even some Open Source tools that have been built for this purpose. The benefit you’ll get is that Octopus is a great integrator with feature flagging tools - for example, we have a community contributed step template for managing LaunchDarkly feature flags. This type of mechanism with a step template interacting with a third party service that supports your application’s lifecycle is very common in the world of Octopus, and community step templates are just one of the ways to approach it.
The second approach would be to reconsider how you’re mapping your feature flags in Octopus. This can look like a couple of different things:
- Like you mentioned in your OP, the next steps for Configuration as Code will include non sensitive text variables as an applicable item to be stored in Version Control. This will have some benefits - chiefly, if you deploy from branch
feature-test-1
that has feature flags enabled, you can still deploy from the tip of your main
branch without having to manipulate the variables. When you merge in feature-branch-1
, you’ll update your variables at that time, and your successive deployments from main
will continue to match what’s expected. However, this will rely heavily on your branching strategy, and (at least initially) isn’t planned to cover library variable sets.
- Another option that leverages your existing approach for library variable sets would be looking at the Octopus Deploy Terraform Provider. The Terraform provider would allow you to version control your library variable sets, giving you a clear line of accountability on the state of your variables and enabling you to see previous values and “roll back” those values as needed for hot fix deployments.
- A final option to consider would be organizing your variable sets to be as explicit as possible for feature flagging. For example, if you’re following the documentation recommendation to use channels for your hotfix deployments, you can scope your feature flag variables to be true/false per environment AND channel, allowing you to more granularly control the behavior.
Like I said initially, Octopus isn’t the best tool for managing feature flags at the moment, due to a primary misalignment with the approach and purpose of the tool as designed. Hopefully the options I’ve laid out offer you a path forward to enable better/simpler feature flag management - if you have any other questions or concerns, don’t hesitate to ask. Happy to help however we can!