LaunchDarkly

LaunchDarkly is used for maintaining feature toggles for our production services. We have been using it for a year now and haven't had any issues so far. We have a toggle framework that abstracts away the complexity of Launch Darkly so we don’t actually interact with it directly. LaunchDarkly provides a clear insight into the state of your toggles in production.

We use LaunchDarkly to help hide incomplete features from end users. This allows us to deploy code to production more often, which reduces code conflicts and leads to a healthier codebase

We currently use it in a couple of ways:
1. Use for configuration values that are shared across multiple applications
2. Feature Flagging for new features can deploy and test while still being developed.
3. Used it as a feature kill switch if we need to disable a feature during peak traffic/season.

While LaunchDarkly delivers a huge set of features, we use it mainly as an environment. Our CI/CD pipelines push our code straight to live, with our new features encapsulated in a LaunchDarkly toggle. That gives us huge control over what can be seen on live without the overhead of having to mimic a live environment on staging.

We predominantly use LaunchDarkly to facilitate our Trunk Based / Continuous Deployment workflow, enabling us to deploy multiple times a day and target specific user segments. We also use it to run UI experiments that help us determine the optimal customer experience.

Ours is a provider-facing application. We were needing a tool that could toggle between features that providers get to see. And on that search, we landed on LaunchDarkly for feature toggle management. One of the best tools that fit our use case. The ease of use is very straightforward. The support team is excellent in providing immediate support while setting up the tool and during development. I would highly recommend this for any organization that needs a feature toggle use cases. We currently use this tool across our organization.

We use LaunchDarkly to control features in our authenticated web and mobile applications. It allows us to test features in production, gradually rollout new features to users & gather feedback, and disable new features if there is a problem. We are currently using it in one department, but other departments have seen our success and are working on their own POCs.

LaunchDarkly is being used by our Technology department to continuously deliver code that is off in production - customers are not impacted by code delivery. Their workflow is not interrupted. We then schedule when the code will be enabled and prepare our customers for the changes. This allows our Technology teams to continue to work without slowing down their schedule for our customers, who like more time to prepare for changes.

We use LaunchDarkly to separate the Deploy and Release aspects of changes. The R&D team implements LaunchDarkly flags in code, and then by using the user targeting functionality the QA team can validate the changes with the flag on and off. The main point is testing with the flag off, as this means that the master can be deployed to production at any point with the flag remaining off, so we don't have to worry about breaking existing functionality by using these flags.

LaunchDarkly has been used as the proof of concept to use feature flagging. It has been used in my department for some POC work as currently we use Azure Devops pipeline configuration for feature flags. It solves feature toggling in production to switch on and off features which are not stable or completely finished. It gives full control in deciding what features whether it is backend or frontend to be used in production environment. Further, feature toggling can also be used dynamically to change some features without recompiling the code or reload the page.

We use LaunchDarkly to separate deploy and release processes and allow for a test in production mentality. It allows us to internally target new features for test in production before releasing to external customers.

When making structural changes to our systems, our operations teams use the feature management to maintain stability while undergoing these processes. The fact that we can use feature flags in place throughout our systems [means] we can put our applications into maintenance mode and make the necessary system updates and be at ease of mind.

The platform allows us to implement and test features without full deployment. In turn, the risk is greatly reduced and user acceptance is much higher when deployment occurs. Currently it is being used internally. LaunchDarkly allows us to address individual problems one issue at a time by introducing a new feature and make sure it meets the needs and resolves the problem.

We are building a new customer-facing platform that spans all products in the company and has multiple teams working on features. LaunchDarkly allows us to manage our rollout of new features by different teams so they can be deployed independently and slowly released to the interested beta users.
Having features wrapped in flags has allowed us to test in production before anyone sees it. This has allowed us to find issues that we could not have seen with QA data.

We are using it in my department as a part of deploying and releasing chat application features. We are still in early phases of adoption, but it is currently helping us with controlling access to beta testing features.

We use it for rolling new variants of our code out and passing new features to production to limited people before sending it out for the whole user base. Knowing that we can set up targeting based on many different values allows us to be precise on who we send out the feature for.

Only downside is limited seats for engineers to use, which makes adopting it slower than I would like.

We use LaunchDarkly to improve our Release-on-Demand capabilities and cycle time of features for our business. It allows our product delivery teams to decouple from one another and launch features independent of a release window. It is currently being used by a few teams, but we are looking to expand the capability across as many business applications/components as possible in the near future.

LaunchDarkly is been used by the product team to enable/disable feature[s] per client.

It is being used with the Software Development department to test the value of features in small iterations, ensure implementations are working as expected before rolling out to all customers, to perform A/B tests of features and to have kill switches to enable/disable functionality on a permanent basis. Data gathered by the ability to use feature management in this way informs business decisions and the priority of the work being undertaken.

Through being able to decouple a deployment of code to the release of a feature the development teams and business teams can more effectively decide when, how and to whom a feature is being enabled. This makes work easier to implement and the value of the feature can be understood more effectively.

Every team can decide for themselves if they want or need to use LaunchDarkly. We do offer a company-wide subscription to everyone that wants to use it. In our team, we use it to support us in the continuous deployment of features in our portal. In the future, we want to extend our use of the different features.

LaunchDarkly is used by engineering for testing in production. It is used to deploy code to customers in a safe manner.

It addresses the issue of deploying code and allowing a easy way of reverting if something is needed. This is important for StockX where the businesses needs to serve customers around the world 24/7, and a small code change can cause outages which lead to failed orders.

LaunchDarkly is used within the Engineering department to speed up time to delivery. We use feature flags so that we can deploy changes, and hide them behind feature flags until we are ready to show customers. We also use feature flags to show specific customers specific features.

LaunchDarkly is used by our software development team for several of our customer-facing products. We primarily use it to manage the features that are released to these applications. We deploy new code to production on a daily basis. As our teams develop large feature sets we hide those feature sets behind LaunchDarkly feature flags until the entire feature set is complete. Once we have the feature set complete, the documentation created, and our customer service team trained, we remove the feature flag and make the new feature set available to our customers.

Teamworks implemented LaunchDarkly over a year ago and it has been a game-changer for our product development process. It has allowed our development team to move faster, we deploy code to production with confidence knowing that we can roll out features at our own discretion with feature flags. Our quality standards have improved as well since we can selective rollout features to internal testing accounts in production as a final check before a broader GA release.

We use LaunchDarkly as a key part of our shipping & QA process. Let's us ship features behind a feature flag, first roll out internally to employees, then a controlled roll out to a percentage of users, before turning on for all users. Each of the steps only takes a few seconds, without any code changes. Being able to safely roll out features in this way helps us move faster.