What is your primary use case for LaunchDarkly?

My main use case for LaunchDarkly is to gate our new features behind the flags and to manage those flags via LaunchDarkly UI and portal and dashboard so that we can roll out different features properly tested on different environments and for different users and with different variations, with different configurations and settings. One feature that we rolled out this way is a really big feature which was changing the product's whole flow and had to be rolled out to multiple markets, specifically to three different countries where our product is being used. Since it was a big feature, we had to get it behind the development first because it was in the development stage. We tested it out regularly with different variations, with different targetings, with different rule sets, using different LLMs and everything which was managed by LaunchDarkly. Then we launched it on staging, turning on the flag for staging to test it out there. When we rolled it into production, we selected a smaller customer country from the rules part for the launch to identify initial bugs or issues at a smaller customer base, eventually rolling it out and turning on the feature for bigger customers and bigger countries as well. This is my main use case for LaunchDarkly; we create the flags there, manage them from there, and turn them on or off there. We have a whole dashboard where we can see who has made a recent change in the flag and what settings have been changed. If something breaks due to recent settings, we have an idea of what has been changed that caused it to not behave as required. Additionally, we have different variations, different rules in it, as well as a whole dashboard where we can look into it. It is really helpful to integrate it easily due to the flexibility that gives us confidence in LaunchDarkly.

I primarily use LaunchDarkly for rollouts, having flags, and putting my feature and code behind the flags. I have multiple codes that I need to organize in different branches, and it is better to put those behind different flags so we can turn them on and off and test them in required environments. I work with Java SDKs and Go SDKs to integrate LaunchDarkly, which really helps when dealing with a complex workflow and allows me to turn off a flag for a feature if it is not working well. With LaunchDarkly, we are using a lot of AI to ship our bulk of code, which helps us keep new changes behind the flags until fully tested, enhancing our day-to-day usage. We integrate monitoring tools like OpenSearch and Grafana with LaunchDarkly; these integrations are sufficient for our needs, and we use a common library built for across the organization to utilize LaunchDarkly flags and features.

My main use case for LaunchDarkly is feature flagging and gradual rollouts. Instead of releasing a new feature to all users at once, we can first enable it for internal users, then for a small group of customers, and only later roll it out to everyone. When we released a new feature, we first turned it on only for internal users. After that, we enabled it for a small percentage of real customers, which helped us test that feature in production without taking too much risk. If something went wrong, we could simply turn the flag off in LaunchDarkly without doing a full rollback. We use flags for gradual deploying and testing, then rolling out. For example, we enabled a feature, tested it in a specific environment, then turned off this flag.

My main use case for LaunchDarkly involves dark releases on production and feature flagged features delivered to customers. I use LaunchDarkly to test new releases on staging and sandboxes, and later deliver it to production darkly. I test it, verify that the dry run is fine, and afterwards release it. I have additional thoughts on how LaunchDarkly fits into our process by splitting our platform into models using feature flags and delivering it meaningfully.

Currently, my main use case for LaunchDarkly is as a consumer. The application that I'm using uses LaunchDarkly as feature toggles. We toggle our flags on and off depending on what environment they're in, and depending on what state of the application's development lifecycle is. I can give a specific example of how I use LaunchDarkly for feature toggles in my application. We've got a set of features that we're keeping hidden behind a set of feature toggles, specifically based on how we're allowing users to log into our application. When the feature toggle is on, the functionality allows the user to access the new identity provider that we're using. When the feature toggle is off, it's using our old, previous functionality for our identity provider.

We use LaunchDarkly for managing feature flags. It helps manage the keys to control what users view on our screens.

Our developers are using LaunchDarkly. I am using it to turn on features.

We use the solution for risk-free releases, allowing us to control the blast radius when launching content to our customers. We also use it for targeted experiences, enabling us to reach specific customer segments with various features as they are rolled out. However, the company's main use case was extensive A/B testing to conduct experiments.

We built a powerful e-commerce platform and heavily used LaunchDarkly to launch features behind a flag. This allowed us to implement trunk-based development, significantly improving our development speed. We could continuously deploy everything behind a flag and enable features only when ready, which was incredibly helpful. There are certain features we need to keep behind a flag. Typically, there are two ways to do this: using a property file or using LaunchDarkly. With property files, we had to deploy the feature in a lower environment, update the property, and then restart the server. LaunchDarkly, on the other hand, offers real-time changes and the ability to disable features if issues arise in production. This real-time capability is extremely beneficial.