Really interesting take on your experience with experimentation / feature flags and wanting it to be more stateful in code. I assume that follows the more Terraform-like infrastructure as code approach, which certainly makes sense to rollout infrastructure changes. We have a V1 of a Terraform provider where we hope to enable more control through terraform to manage infrastructure changes directly, but you are correct that has yet to be our core focus. Another way we hope to expose that state outside of our UI is building out a great CLI, which we are actively working on.
Our primary usecase has been working with product development teams who have adopted Feature Flags as part of their workflows, using DevCycle to help them deploy features faster / safer to their end users, even deploying continuously as we do. Generally, customers integrate DevCycle into their Websites / Mobile Apps + API servers to control those feature deployments. We have had a couple of customers use us at the infrastructure layer. One of the best use cases I've seen is in a proxy service controlling the rollout of a new infrastructure stack. I'd love to dig into this use-case deeper and see how we can better support it in the future, "Ops" flags are one of the flag types we are looking to support.
I would say that for customers looking to disconnect the deployment of code from the release of features, our approach where you can "release" features at any time has many advantages over "git-ops" style configurations. But certainly, for Ops use-cases where you are controlling infrastructure changes, we are believers in "git-ops" and use it ourselves. The challenge comes with how to connect those two deployment styles effectively.
Our primary usecase has been working with product development teams who have adopted Feature Flags as part of their workflows, using DevCycle to help them deploy features faster / safer to their end users, even deploying continuously as we do. Generally, customers integrate DevCycle into their Websites / Mobile Apps + API servers to control those feature deployments. We have had a couple of customers use us at the infrastructure layer. One of the best use cases I've seen is in a proxy service controlling the rollout of a new infrastructure stack. I'd love to dig into this use-case deeper and see how we can better support it in the future, "Ops" flags are one of the flag types we are looking to support.
I would say that for customers looking to disconnect the deployment of code from the release of features, our approach where you can "release" features at any time has many advantages over "git-ops" style configurations. But certainly, for Ops use-cases where you are controlling infrastructure changes, we are believers in "git-ops" and use it ourselves. The challenge comes with how to connect those two deployment styles effectively.