证明功能标志在生产环境中关闭项目

Question

我们希望实现特性部署标志，因此开发应用程序环境将有一个新的产品特性切换。和发布和生产环境网页，它被关闭。

它在appsettings.json文件中切换。

https://launchdarkly.com/blog/what-are-feature-flags/

我们的客户，不喜欢特色标志，并希望我们到不同的源代码管理Git分支机构。其论点是，“我们不能保证，在生产环境中，这些特性被关闭或切换。您怎么知道没有新的代码泄漏？”

嗯，我们截图了我们的API不工作在Swagger/邮递员，另外显示“页面是找不到在网页”，当浏览到新的功能网页。

我们还能做些什么来确保关闭部署国旗功能？怎么才能证明呢？

对于开发人员来说，为每个切换创建新的源代码管理分支会更令人困惑，等等。

应用程序是Net C# API，在Azure和Devops中有棱角的网页。想应用这些特性，

特色旗帜和路由器警卫，

资源：

https://docs.microsoft.com/en-us/azure/azure-app-configuration/use-feature-flags-dotnet-core

https://netbasal.com/the-ultimate-guide-to-implementing-feature-flags-in-angular-applications-d4ae1fd33684

Answer 1

有几种方法可以对此进行分割。

从客户端的角度来看，特性标志可能引起一些关注。系统是否在各种特征标志组合中进行了良好的测试？当功能标志设置为禁用状态时，所有端点( UI元素和请求端点)是否都受到保护以避免使用？当您引入第三方来管理这些特性标志时，还需要考虑其他问题。当第三方系统发生故障时会发生什么情况？切换功能标志是否安全，访问是否受到良好控制？

从开发人员的角度来看，特性标志增加了系统的复杂性，必须在整个产品开发生命周期中加以考虑。功能标志后面需要有哪些特性？如果多个特征标志交织在一起会发生什么？如何在系统的所有有效状态中进行充分的测试？

根据环境的不同，不同类型的特性标志比其他类型更有用。例如，考虑一个配置文件，它要求您在管理UI控制台中重新部署您的系统或功能切换，而不是使用第三方服务，比如“黑暗启动”。在其他情况下，特性标志不是正确的解决方案。有时，keystone接口是有用的。在其他情况下，独立的分支是正确的方法。选择取决于系统的特定需求。

当您提供软件即服务时，我不认为客户应该决定如何构建和部署软件系统。功能需求和质量属性决定了您如何设计、构建、测试和部署新特性或功能。可能存在一些监管标准，需要将其视为产品的需求以及用于构建产品的过程。

作为一个SaaS供应商，您的责任应该是证明您满足所有的需求--监管需求、功能需求和所需的质量属性。您应该能够在各种错误和失败条件下进行模拟和测试，以使您的客户对您提供所商定的服务的能力有足够的信心。

来自受规范的环境，我习惯于像这样的问题来自客户。我的方法通常是：

• 收集供应商和供应商的信息。这可能包括各种行业标准的审计和评估(ISO 27001和SOC 2是常见的，但其他则是行业特有的)。其他信息可以记录在他们的网站或合同中--客户和推荐人、案例研究、服务条款和隐私政策。
• 进行供应商评估。利用供应商的信息，支持他们如何支持满足正在设计的系统的要求。如果客户端的文档不足，那么在测试环境中使用演示或试用期来捕获信息可能是个好主意。
• 允许对您的开发过程进行审核。如果您是一个较大的企业，您可以根据不同的标准进行审计。客户也可能希望直接对您进行审计。清楚地描述您是如何工作的，以及这些工作方式如何满足软件开发生命周期的各个方面及其需求。
• 显式地遍历测试过程。证明您的功能标志周围有适当的覆盖(最好是自动化的)。虽然我知道这并不一定是最有用的，但是代码覆盖率报告之类的东西可以证明您可以进行测试。此外，还显式地介绍了如何管理环境访问以及谁可以切换标志。示威有很大的帮助。
• 有一个模拟生产的演示环境，特别是在无法在生产中进行测试时。这可以使您的客户能够理解您的应用程序在不同的状态。他们可以获得对架构的信心，甚至可以在不同的组合中切换功能，而不会影响生产状态。

Answer 2

我同意你的客户意见，特征标志是不好的。

然而，这个特别的投诉可以像任何"wHaT，如果它的WrOnG？“一样处理。有个问题。试试看

您应该进行端到端或集成测试，以确认已部署应用程序的行为。如果打开或关闭了不正确的功能，这些测试就会失败。

将测试构建到部署脚本中，并允许在任何时候针对活动环境运行测试。如果出现关于实时应用程序是否正确工作的问题，只需运行测试即可。