We want to implement Feature Deploy Flags, so Development Application Environment will have a new Product feature Toggled on. And Release and Production Environment Webpage, it is turned off.

Its toggled through appsettings.json file.


Our clients, do not like Feature Flag, and want us to Different Source Control Git Branches. The argument is, "We Cannot Ensure, the Features are turned off or toggled off in the Production environment. How do you know there is not new code leakage?"

Well we took screenshots of our APIs not working in Swagger/Postman, additionally showed "Page is not Found in Webpage", when browsing to new feature webpage.

What else can we do to ensure, Deploy Flag Feature are turned off? How would someone prove this?

It will be more confusing for developers to create New Source Control Branches for every toggle, etc.

Application is Net Core C# APIs, with Angular Webpage in Azure Cloud & Devops. Want to apply these feature,

Feature Flags and Router Guards,




  • 1
    What kind of software do you make and how is it distributed? Is it SaaS? Is it multi-tenant?
    – Thomas Owens
    Oct 15, 2020 at 19:07
  • 2
    Report feature flag settings in a health check? You or your clients probably already have ping/health check services - you could look for presence (or absence) of strings that indicated specific feature flags in the health response; mark service as bad if the wrong features showed up.
    – davidbak
    Oct 15, 2020 at 19:14
  • I just left more background info, C# and Angular with Azure Cloud, Property application system for a County in Wisconsin actually cc @ThomasOwens
    – user377748
    Oct 15, 2020 at 19:14
  • hi @davidbak can you explain more with code or source link? sounds interesting
    – user377748
    Oct 15, 2020 at 19:15
  • 1
    (Be sure you want to pull on this thread, but) why does your client trust you to deliver any other part of this system? Then why not this? Note that feature flags don't generally prevent code leakage, unless they're applied at build time (which is an anti-pattern of its own).
    – jonrsharpe
    Oct 15, 2020 at 20:40

2 Answers 2


There are a few ways to slice this.

From a client's standpoint, feature flags can raise some concerns. Is the system well-tested in various combinations of feature flags? Are all of the endpoints (both UI elements and request endpoints) protected against usage when the feature flag is set to a disabled state? When you introduce a third-party to manage those feature flags, there are additional concerns. What happens when the third-party system experiences an outage? Is the ability to toggle the feature flags secure and access well-controlled?

From a developer's standpoint, feature flags add complexity to a system and must be considered throughout the product development life cycle. What features need to be behind a feature flag? What happens if multiple feature flags are interwoven? How do we adequately test in all of the valid states of the system?

Depending on the environment, different types of feature flags are more useful than others. For example, instead of using a third-party service like Launch Darkly, consider a configuration file that requires you to redeploy your system or feature toggles in an administrative UI console. In other cases, feature flags aren't the right solution. Sometimes, keystone interfaces are useful. In other cases, separate branches are the right way to go. The choice depends on the specific requirements of your system.

When you provide software-as-a-service, I do not believe that customers should dictate how you go about building and deploying the software system. There are functional requirements and quality attributes that dictate how you design, build, test, and deploy new features or functionality. There may be regulatory standards at play that need to be treated as requirements on your product as well as the processes used to build it.

As a SaaS vendor, your obligation should be to demonstrate that you meet all of the requirements - regulatory requirements, functional requirements, and desired quality attributes. You should be able to simulate and test under various error and failure conditions to give your client sufficient confidence in your ability to provide the services agreed upon.

Coming from regulated environments, I'm used to questions such as this from clients. My approach is typically:

  • Collect information from vendors and suppliers. This may include various industry-standard audits and assessments (ISO 27001 and SOC 2 are common, but others are more industry-specific). Other information may be documented on their website or in a contract - clients and testimonials, case studies, terms of service, and privacy policy.
  • Perform a vendor assessment. Using the vendor's information, support how they will support meeting the requirements levied upon the system under design. If the client's documentation is insufficient, using a demo or trial period in a test environment to capture information may be a good idea.
  • Allow for your development process to be audited. If you're a larger enterprise, there are various standards you can be audited against. Clients may also want to audit you directly. Have clear descriptions of how you work and how those ways of working satisfy every aspect of the software development life cycle and their requirements.
  • Explicitly walk through your testing process. Demonstrate that you have appropriate coverage (preferably automated) around your feature flags. Although I know that it's not necessarily the most useful, things like code coverage reports can demonstrate that you're able to test. Also, explicitly go into how you manage environment access and who can toggle flags. Demonstrations go a long way.
  • Have a demonstration environment that mimics production, especially if testing can't be done in production. This can give your clients the ability to understand your application in various states. They can gain confidence in the architecture and even toggle features on and off in different combinations without affecting the state of production.

tbh I agree with you clients, feature flags are bad.

However, this particular complaint can be dealt with in the same way as any "wHaT If ITs WrOnG??!?" question. Test it

You should have end to end or integration tests that confirm the behavior of the deployed application. These test should fail if the incorrect features are turned on or off

Build the tests into the deployment script and allow them to be run against the live environment at any time. If a question arises about whether the live app is working correctly, simply run the tests

  • hi Ewan, why are feature flags bad? interesting they are used by google (for A/B user testing), Amazon, and in Microsoft Net Core system framework
    – user377748
    Oct 15, 2020 at 19:16
  • 1
    because they exponentially multiply the paths you need to test.
    – Ewan
    Oct 15, 2020 at 19:17
  • hi @Ewan, true, thats a good point, feature flags should be minimal and technical debt according to develop principles I read, isnt it also hard to manage Multiple git branches with merges and cherry picking, and environments, just to toggle off one feature?
    – user377748
    Oct 15, 2020 at 19:22
  • 1
    dont do that either. add features, have releases with them in
    – Ewan
    Oct 15, 2020 at 19:25
  • 1
    if you need to revert, revert to previous version dont revert to an untested combination of flags
    – Ewan
    Oct 15, 2020 at 19:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.