渐进交付时代的发布管理

然后是功能标志的使用如何影响渐进式交付，最后是那些希望采用渐进式交付作为实践的企业的首要考虑事项。

让我们从功能标志开始。它们是什么?

特性标志使您能够远程打开或关闭应用程序的特性或子部分，而无需实际将软件重新部署到您的环境中。

所以在你的代码中简单地使用一个if语句作为特征标志。

因此，如果启用了特性标志，那么代码就会暴露给您所识别的用户。

功能标志并不是一项新技术或新概念。很长一段时间以来，它一直是开发人员在个人层面上使用的东西，但在过去的五到七年里，它在跨组织的使用和管理中被正式化了

这是由Netflix、Uber和Facebook等软件开发领导者开创的。

现在这种对CI\CD工具链的使用和标准化越来越多

在不同的公司也有更多。

现在我们来谈谈持续交付。

这是人们更熟悉的东西，它是一种软件

开发规程，您可以构建软件，以便它可以在任何时候发布到生产中，并且当您的软件在整个生命周期中可部署时，您正在进行持续交付。

团队正在优先考虑可部署的软件，而不是开发新功能。

任何人都可以获得关于他们的系统的生产准备的自动反馈，你可以在任何环境中执行按钮部署，所以很多都是关于自动化的，然后越来越多地，在类似生产的环境中，代码被推送，以便在生产前测试你的代码。

所以CI\CD实践是渐进式交付的基础，但仅仅是持续交付，即使你做得很好，你知道，有一些事情要考虑如何改进?从持续交付过渡到持续部署(每次签入都可以自动推入生产环境)，您是否感到舒适?

一路上没有手动停车。

你能在周五部署吗?

这对你的团队来说意味着什么?

然后在生产中进行测试吗?

这是我们将更多地讨论的事情，测试的焦点已经向左转移，但也向右转移到您的生产环境中，在那里您将与真实的用户进行测试。

现在让我们来谈谈渐进式交付，这是一个迭代地推动产品变化的过程，首先面向较小的受众，然后逐渐面向更大的用户群体。

这样你就可以保持对用户和质量的控制。

因此，您将逐步将您的特性滚动到特定选择的队列中，这限制了部署新特性时受到影响的爆炸半径

一旦你在更小的群体中进行了测试，你就可以

要有信心开始向越来越大的群体推广，直到你向所有用户推出你的特性。

所以这是渐进式的部署，你有功能标志来控制功能如何推出。

通过这种方式，发布现在与比特的部署分离了。

因此，您可以将其部署到生产环境中，但前提是您实际上启用了新版本中的新特性。

你真的要发布新版本吗?

这样，你就可以在产品中更多地与用户一起测试功能，并且你对自己的发布版本更有信心，因为当出现问题时，你可以控制和敏捷地快速响应。

所以你可以自信地发布，甚至可以在周五发布。

因此，让我们进入特性标志和持续交付如何帮助您实现渐进式交付。

那么，我们今天所知道的持续交付在传统上有哪些不足呢?

组织可以很好地进行持续交付。

但这种方法仍然有局限性，您可能会提高开发速度，更频繁地向用户发布新功能，但这也会因缩短周期而带来风险。

你交付给生产环境和用户的所有东西都需要为用户准备好。

因此，如果在部署后出现问题，整个版本都需要回滚或前滚。

所以你需要在制作前做很多努力，这样你才会有信心

否则，它会触发你的版本的整个回滚。

但是，CD中的大多数测试都是在生产前完成的

在你的生产环境中缺少一些现实世界的因素，你知道，拥有一个包含所有因素的预生产环境是非常困难的

可能在您的生产环境中。

更重要的是，你也无法测试和回应来自真实用户的反馈。

因此，在部署到生产环境时，这可能会带来意想不到的惊喜。然后，你必须用完全回滚来回应。

使用传统CD，很难控制爆炸半径，或者

谁会在你的新版本中看到你的新能力。

你无法集中控制它所面向的用户，你也没有能力向特定客户推出功能，然后推出和回滚逐渐变得更加复杂。

所以让我们回过头来看看渐进式交付是如何工作的

一个传统的Canary发行版。

因此，您可以使用Canary部署逐步交付到环境中，这确实限制了暴露，并且可以进行测试

部署新代码时的生产。

本例中的控件位于基础设施网络层。

这就是你如何控制访问你的新版本的用户，我们在图中选择，你可以看到我们选择了一小部分被路由到部署版本2的服务器的用户。

随着时间的推移，您将版本2推广到越来越多的服务器，并将更多用户路由到版本2，直到所有用户都使用版本2。

这种方法允许在您的生产环境中使用小组用户测试功能，这很好，您能够完成测试。

但也有很多挑战。

运维团队必须参与整个过程，这可能很难控制。

有，你知道，有限的mes方法，针对哪些用户来测试一个新功能，你没有控制和所有的输入类型的用户，你知道，我们在网络层有控制。

反馈循环变得更加困难，因为大多数新版本的部署可能包含许多更改，对吗?

这不仅仅是一个单独的特性，而是一个整体

软件版本。所以你可能会得到关于某个特定功能的反馈，但你仍然必须在完整版本级别上做出回应。所以回滚是在特定特性出现问题或负面反馈时必须回滚整个版本的粒度。

那么现在让我们看看对于带有特性标志的用户来说，渐进式交付是如何工作的。

在这种情况下，金丝雀部署带有特征标志。

控件位于应用程序层，这允许您限制其公开

用户可以看到新的更改，无论是内部测试人员、beta用户还是基于百分比的推出。

你对那些开始看到新功能的用户群体有很大的控制。

然后你可以逐渐增加爆炸半径，帮助你在每一个新的增量步骤中充满信心地向前推进。

在这个例子中，通过图表，你可以看到带有特征标志，

新版本被部署到您的环境中。

所以版本二被部署在中间的盒子里，但是特性本身一开始只暴露给一小部分用户。

这就是产品团队在运维团队完成一次部署之后，现在产品团队可以逐步接管

开始为用户开启新功能，并使用高度选择性的标准，这些标准都在用户的控制范围内。

然后随着时间的推移，随着功能得到积极的反馈，功能可以逐步改进

在一段时间内为所有用户打开。

这很好。这意味着组织现在正在改变他们的

从一个完整的产品发布的心态到一个功能的焦点。

功能不再受整个发行版本的限制，这确实改变了游戏，我们将在下一个例子中看到更多。

你需要注意的几件事是，

如果您不知道一个特性标志在生产中是打开还是关闭，那么您需要测试这两种状态。

您不必总是测试所有配置，但在进入生产环境之前，您必须考虑您想要测试的特性标志的配置是什么。

你必须考虑的另一件事是随之而来的流程和文化变化，因为新的团队成员将有不同的职责，而不是拥有部署和后部署，你将把开发和产品团队带回这个后部署的功能中。

所以让我们进一步分析，在整个版本中，版本粒度和特性粒度以及控制的真正含义是什么。

因此，我们将详细介绍这个版本，其中将引入四个新特性，以及这两种方法的区别。

在最上面一行，我们有我们传统的CD制作过程，我们有这个版本

其中所有的特性都包含在一起并发布，特性一到特性四。

如今，大多数公司都在使用这种模式，其中的编排是发布版本级别，如果交付的任何一个功能出现问题，整个发布都可能被推迟和暂停。

在这个例子中，我们有四个阶段在测试阶段，在提交之后

构建完成后，我们发现特性3的bug超过了我们的处理能力，我们现在必须删除整个版本来修复这些bug。

一旦这些错误被修复，

然后您可以重新开始并进入部署和发布阶段。

在这个阶段，所有四个特性都发布给我们生产环境中的所有用户，在发布完成后，我们发现特性4不能像用户期望的那样工作，我们需要修复它。

因此，我们不能只关注第四个特性，现在我们必须回滚整个版本来解决这个问题。

因此，我们正在回滚版本，等待特性4被修复，然后新版本才能进入整个过程并重新部署到生产环境中。

因此，在所有新特性都准备好并处于良好状态之前，用户不会使用任何新特性，并且在此过程中会出现版本回滚、延迟和发布。

现在让我们看看底部一行，我们有一个带有特性粒度的版本。

我们有四个特性要经过提交和构建。

在测试阶段，我们仍然会在特性3中看到同样的问题。

而不是在整个发布过程中出现意料之外的延迟，我们能够

使用特性标志，关闭特性3，并继续进入我们的部署。

所以现在在我们的代码部署阶段，第三个特性被关闭，其他三个特性被启用，我们开始逐步向用户交付和推出其他三个特性，只有一小部分用户可以看到这些特性。

我们再次发现特性4没有被很好地接受，但它只是暴露出来了

对于一小部分用户，他们在我们能够响应并在生产中关闭该功能之前就看到了该功能。

同样，我们不会回滚整个版本。

这是一个简单的功能切换，功能1和功能2仍在生产中

并且可以继续向其他用户推出，而特性三

第四项功能正在开发中，稍后会投入使用。

所以你能做的就是添加。

使用渐进式交付的特性标志，您可以在您的发布中拥有更多的灵活性和敏捷性，以响应具有该粒度级别的特性级别的问题。

在功能的推出和回滚中，这样您就能够在不引起延迟和回滚的情况下响应用户，从而将风险引入到整个流程中。

因此，特性标志可以大大提高发布速度，因为它们打破了正在编排的发布的依赖关系。

而不是一次编排，您看到的是您能够控制的功能集合。

因此，这意味着一组功能不会因为其中一个有bug而支撑发行版。

您能够保持发布的一致性和速度，因为没有任何事情会导致回滚或其他事情……

需要修复的bug。

你还可以限制不完整或有bug的功能的暴露，你可以把它们，你知道，把它缩小到它唯一的内部

能够看到该功能并继续开发该功能的开发人员。

再来比较一下传统CD和带功能标志的CD。

传统上，你关注的是比特的战术传递，但当你得到

使用特性标志，您可以专注于交付特性，并在组织内达到下一个成熟度级别。

与其关注环境和环境的状态，看看有哪些版本，

你关注的是你的客户，以及他们能够在你的产品中使用哪些功能。

您的测试正在发生变化，您正在与真正的用户在生产环境中进行测试。

您可以对用户进行集中粒度的测试

是这些用户的特征。

独立的特性现在可以在不影响用户的情况下推出或推出，因为版本的回滚或升级不会有任何停机时间。

然后将代码部署到生产中，现在你在业务需求和开发需求之间没有依赖关系了因为你可以部署然后

根据您的业务要求，在您需要的时候推出功能。

既然我们已经讨论了渐进式交付，并通过了一些示例，那么我想回顾一下让您的企业使用渐进式交付的一些主要考虑因素。

所以你要问自己的问题是，在真正的用户身上进行测试和学习的最简单的方法是什么，你希望能够轻松地控制哪些用户可以看到新功能，哪些用户属性，能够轻松地做出响应

并在需要时回滚更改。

所以你想，你可以用功能标记一次性完成这个，但是你如何做到这一点并把它变成一个可以在用户身上测试的实践

以一种可重复和自动化的方式。

那么让我们来讨论一下如何达到这个目标。

在基本面方面，你将需要持续的整合。

因此，您希望在某个成熟度级别上实践CI，您的开发人员应该尽可能频繁地将他们的更改合并到主分支中，并且您拥有自动触发的CI流程。

持续交付，您需要在您的CD流程中有一些成熟的自动化。

因此，当您能够将代码投入生产时，这不是手动的消防演习，而是有一个管道来编排或推动您的代码投入生产。

在这个过程中可能会有手动的停顿，但背后有一个过程。

这是一种持续的交付，这是一种误解

你需要持续部署来实现渐进式交付

但是当您能够通过持续交付引入特性标记时，您就可以实现渐进式交付。

这是第三点，你需要某种程度的特性标志功能

您可以使用用户属性来控制功能的推出。

然后所有这些集成在一起，CI\CD，和功能标志一起成为驱动渐进式交付的集成骨干。

那么该怎么做呢?你需要什么?

第一个是功能标志的可见性，你想要你的功能标志，

应该是你的发行版的一个输入，在那里你可以看到作为你的发行版的一部分的功能的有效负载?

您希望了解哪些功能正在控制您的环境

以及在特定环境下的可见性?

出现了哪些功能标志?当前的状态是什么?所有这些特征标志在整个管道中都是可见的?

那么释放标准是什么呢?

什么是大门?你需要满足什么条件才能完成释放，但你看到的右边是一个高层次的视图，

其中一个有帮助的视觉效果是查看你发布的价值流，看看我的功能在哪里，状态如何，以及有多少功能已经向所有用户推出。

接下来是通用的治理和控制，您需要能够控制您的功能标志作为CD管道的一部分。

因此，您需要能够自动更改各个特性的值

每个阶段的管道，更新功能的目标对象，然后用访问控制控制功能标志，并在其上更改权限。

所以你应该能够控制谁可以从你的CD管道中更新特性标志，并且让特性标志作为闸门，检查特性标志状态并在CD管道中进行之前将其作为闸门。

所有与特性标志相关的活动都应该是管道运行的审计跟踪的一部分，这样您就可以回头查看部署中究竟发生了什么，以及特性是如何在用户之间推出的。

接下来的一步是在你的CD管道上创建一些智能自动化的功能标志。

因此，您希望能够定义可以跨特性和管道使用和重用的特性发布模板，在那里您可以决定是基于百分比的推出，还是基于环形的推出，从小型开始，从内部员工增长到beta到GA用户。

因此，定义模板，然后在管道中使用它们，然后就像在CD管道中应该做的那样，编排工具，收集APM工具的响应或用户管理数据或正在运行的其他测试的响应，并将其与功能标志关联起来，以便您可以根据结果定义滚出和回滚策略。

所以如果你的用户测试结果，你知道，你可以在适当的地方设置门来查看你的用户测试结果，如果你知道，错过了5%，你就不能进入下一阶段推出你的功能。

因此，您可以进行检查，然后决定是继续推出您的特性，还是在您的管道中完全放弃该特性。

最后，正如DevOps和实践的任何变化一样，涉及到组织流程和文化的转变，这一点不应掉以轻心。

你必须在整个组织范围内考虑变化，人们也需要这样做

同时也要改变他们的思想和心态。

你需要接受这样一个事实:你可能会将不完整的代码发布到生产环境中，并且相信特性标志控制着实际公开的内容。

生产应用程序版本可能不再是唯一的真相来源。

对吧?您必须在生产中查看标记的状态，才能知道是什么

你的用户可以使用它。

然后你需要引入新的过程，你的测试和生产，你需要背后的过程，你在生产中测试的反馈或修订过程是什么，组织中谁正在发布特性，这种所有权正在发生变化，正如我之前提到的，所以你想要了解并开始改变发布的所有权，超出你的部署。

然后，当您开始在许多特性的发布中引入特性标志时，应该对特性标志进行管理，您需要确保有一种管理它们的方法。

否则，您将在代码中创建技术债务。

因此，这是一个逐步交付实践的旅程，你要确保你有CI\CD和功能标志的基础知识。

这其中应该有整合。

然后，通过该集成，您将获得公共可见性、公共治理、智能自动化，并最终通过整个流程的流程和文化转换部分实现企业渐进交付。非常感谢你们今天的时间。而且，你知道，我欢迎任何问题。谢谢你！

因此，让我们进入特性标志和持续交付如何帮助您实现渐进式交付。

那么，我们今天所知道的持续交付在传统上有哪些不足呢?

组织可以很好地进行持续交付。

但这种方法仍然有局限性，您可能会提高开发速度，更频繁地向用户发布新功能，但这也会因缩短周期而带来风险。

你交付给生产环境和用户的所有东西都需要为用户准备好。

因此，如果在部署后出现问题，整个版本都需要回滚或前滚。

所以你需要在制作前进行大量的勤奋工作，这样你才有信心，否则，你知道，它会触发你的版本的整个回滚。

然而，CD中的大多数测试都是在生产前完成的，在生产环境中，你可能会遗漏一些现实世界的因素，这是非常困难的，你知道，有一个生产环境中可能存在的所有因素的预生产环境。

更重要的是，你也无法测试和回应来自真实用户的反馈。

因此，在部署到生产环境时，这可能会带来意想不到的惊喜。然后，你必须用完全回滚来回应。

使用传统的CD，很难控制爆炸半径，或者谁能在新版本中看到你的新功能。

你无法集中控制它所面向的用户，你也没有能力向特定客户推出功能，然后推出和回滚逐渐变得更加复杂。

因此，让我们后退一步，看看渐进式交付在传统的Canary发行版中是如何工作的。

因此，您可以使用Canary部署逐步交付到环境中，这确实限制了暴露，并且可以在部署新代码时在生产环境中进行测试。

本例中的控件位于基础设施网络层。

这就是你如何控制访问你的新版本的用户，我们在图中选择，你可以看到我们选择了一小部分被路由到部署版本2的服务器的用户。

随着时间的推移，您将版本2推广到越来越多的服务器，并将更多用户路由到版本2，直到所有用户都使用版本2。

这种方法允许在您的生产环境中使用小组用户测试功能，这很好，您能够完成测试。

但也有很多挑战。

运维团队必须参与整个过程，这可能很难控制。

有，你知道，有限的mes方法，针对哪些用户来测试一个新功能，你没有控制和所有的输入类型的用户，你知道，我们在网络层有控制。

反馈循环变得更加困难，因为大多数新版本的部署可能包含许多更改，对吗?

这不仅仅是一个单独的特性，而是一个整体

软件版本。所以你可能会得到关于某个特定功能的反馈，但你仍然必须在完整版本级别上做出回应。所以回滚是在特定特性出现问题或负面反馈时必须回滚整个版本的粒度。

那么现在让我们看看对于带有特性标志的用户来说，渐进式交付是如何工作的。

在这种情况下，金丝雀部署带有特征标志。

控件位于应用程序层，这允许您限制其公开

用户可以看到新的更改，无论是内部测试人员、beta用户还是基于百分比的推出。

你对那些开始看到新功能的用户群体有很大的控制。

然后你可以逐渐增加爆炸半径，帮助你在每一个新的增量步骤中充满信心地向前推进。

因此，在本例中，通过图表，您可以看到通过特性标志，新版本被部署到您的环境中。

所以版本二被部署在中间的盒子里，但是特性本身一开始只暴露给一小部分用户。

所以这就是产品团队在运维团队完成一次部署之后，现在产品团队可以接管并逐步开始为用户启用新功能，并使用高度选择性的标准，这些标准都在他们的控制范围内。

然后随着时间的推移，随着该功能得到积极的反馈，该功能可以逐步为所有用户打开。

这很好。这意味着组织现在正在将他们的关注点从完整的产品发布转变为关注功能。

功能不再受整个发行版本的限制，这确实改变了游戏，我们将在下一个例子中看到更多。

您确实需要注意的几件事是，如果您不知道一个特性标志在生产中是打开还是关闭，那么您需要测试这两种状态。

您不必总是测试所有配置，但在进入生产环境之前，您必须考虑您想要测试的特性标志的配置是什么。

你必须考虑的另一件事是随之而来的流程和文化变化，因为新的团队成员将有不同的职责，而不是拥有部署和后部署，你将把开发和产品团队带回这个后部署的功能中。

所以让我们进一步分析，在整个版本中，版本粒度和特性粒度以及控制的真正含义是什么。

因此，我们将详细介绍这个版本，其中将引入四个新特性，以及这两种方法的区别。

所以在最上面一行，我们有我们传统的CD过程，在那里我们有这个发布，所有的功能都包括在一起，功能1到4。

如今，大多数公司都在使用这种模式，其中的编排是发布版本级别，如果交付的任何一个功能出现问题，整个发布都可能被推迟和暂停。

在这个例子中，我们有四个阶段在测试阶段，在提交之后

构建完成后，我们发现特性3的bug超过了我们的处理能力，我们现在必须删除整个版本来修复这些bug。

因此，一旦这些错误被修复，您就可以重新开始并进入部署和发布阶段。

在这个阶段，所有四个特性都发布给我们生产环境中的所有用户，在发布完成后，我们发现特性4不能像用户期望的那样工作，我们需要修复它。

因此，我们不能只关注第四个特性，现在我们必须回滚整个版本来解决这个问题。

因此，我们正在回滚版本，等待特性4被修复，然后新版本才能进入整个过程并重新部署到生产环境中。

因此，在所有新特性都准备好并处于良好状态之前，用户不会使用任何新特性，并且在此过程中会出现版本回滚、延迟和发布。

现在让我们看看底部一行，我们有一个带有特性粒度的版本。

我们有四个特性要经过提交和构建。

在测试阶段，我们仍然会在特性3中看到同样的问题。

为了避免整个发行版中出现意外的延迟，我们只需要使用一个特性标志，关闭特性3，然后继续我们的部署。

所以现在在我们的代码部署阶段，第三个特性被关闭，其他三个特性被启用，我们开始逐步向用户交付和推出其他三个特性，只有一小部分用户可以看到这些特性。

我们再次发现功能4没有被很好地接受，但是在我们能够做出回应并在生产中关闭该功能之前，它只暴露给了一小部分看到该功能的用户。

同样，我们不会回滚整个版本。

这是一个简单的功能切换，功能1和功能2仍在生产中，可以继续推出给其他用户，而功能3和功能4正在开发中，您知道，将在稍后部署。

因此，您在这里能够做的是添加……使用渐进式交付的特性标志，您在发布中拥有更大的灵活性和敏捷性，可以在该粒度级别的特性级别上响应问题。

在功能的推出和回滚中，这样您就能够在不引起延迟和回滚的情况下响应用户，从而将风险引入到整个流程中。

因此，特性标志可以大大提高发布速度，因为它们打破了正在编排的发布的依赖关系。

而不是一次编排，您看到的是您能够控制的功能集合。

因此，这意味着一组功能不会因为其中一个有bug而支撑发行版。

您能够保持发布的一致性和速度，因为没有任何事情会导致回滚或需要修复的错误。

你还可以限制不完整或有bug的功能的曝光，你可以把它们缩小到内部开发人员，他们能够看到该功能并继续开发该功能。

再来比较一下传统CD和带功能标志的CD。

传统上，您关注的是位的战术交付，但是当您使用特性标志时，您可以关注于交付特性，并在组织内达到下一个成熟度级别。

你关注的不是环境和环境的状态，有什么版本，而是你的客户，以及他们可以在你的产品中使用什么功能。

您的测试正在发生变化，您正在与真正的用户在生产环境中进行测试。

您可以对用户进行集中粒度的测试，了解这些用户的特征。

独立的特性现在可以在不影响用户的情况下推出或推出，因为版本的回滚或升级不会有任何停机时间。

然后将代码部署到生产环境中，现在您在业务需求和开发需求之间没有依赖关系，因为您可以部署，然后根据您的业务要求在您想要的时候推出功能。

既然我们已经讨论了渐进式交付，并通过了一些示例，那么我想回顾一下让您的企业使用渐进式交付的一些主要考虑因素。

因此，您要问自己的问题是，在生产中对真正的用户进行测试和学习的最简单的方法是什么，您希望能够轻松地控制哪些用户可以看到新功能，哪些用户属性，能够轻松地响应事情并在需要时回滚更改。

所以你想，你可以用功能标记一次性完成这个，但是你如何做到这一点并把它变成一个可以在用户身上测试的实践

以一种可重复和自动化的方式。

那么让我们来讨论一下如何达到这个目标。

在基本面方面，你将需要持续的整合。

因此，您希望在某个成熟度级别上实践CI，您的开发人员应该尽可能频繁地将他们的更改合并到主分支中，并且您拥有自动触发的CI流程。

持续交付，您需要在您的CD流程中有一些成熟的自动化。

因此，当您能够将代码投入生产时，这不是手动的消防演习，而是有一个管道来编排或推动您的代码投入生产。

在这个过程中可能会有手动的停顿，但背后有一个过程。

这是持续交付，我们有一种误解，认为你需要持续部署才能实现渐进交付，但当你能够通过持续交付引入特性标记时，你就可以实现渐进交付。

这是第三点，你需要某种程度的特性标志功能

您可以使用用户属性来控制功能的推出。

然后所有这些集成在一起，CI\CD，和功能标志一起成为驱动渐进式交付的集成骨干。

那么该怎么做呢?你需要什么?

第一个是功能标志的常见可见性，你想要你的功能标志，并且应该是你发布的一个输入，在那里你可以看到作为你发布的一部分的功能的有效负载?

您希望了解哪些功能正在控制您的环境

以及在特定环境下的可见性?

出现了哪些功能标志?当前的状态是什么?所有这些特征标志在整个管道中都是可见的?

那么释放标准是什么呢?

什么是大门?为了让你的发布完整，你需要满足什么，但你在右边看到的是一个高层次的视图，其中一个有用的视觉效果是查看你的发布的价值流，看看我的功能在哪里，状态是什么，以及我的功能有多少已经推出给我的所有用户。

接下来是通用的治理和控制，您需要能够控制您的功能标志作为CD管道的一部分。

因此，您需要能够通过每个阶段的管道自动更改单个功能的值，更新功能的目标对象，然后使用访问控制控制功能标志，并在此基础上更改权限。

所以你应该能够控制谁可以从你的CD管道中更新特性标志，并且让特性标志作为闸门，检查特性标志状态并在CD管道中进行之前将其作为闸门。

所有与特性标志相关的活动都应该是管道运行的审计跟踪的一部分，这样您就可以回头查看部署中究竟发生了什么，以及特性是如何在用户之间推出的。

接下来的一步是在你的CD管道上创建一些智能自动化的功能标志。

因此，您希望能够定义可以跨特性和管道使用和重用的特性发布模板，在那里您可以决定是基于百分比的推出，还是基于环形的推出，从小型开始，从内部员工增长到beta到GA用户。

因此，定义模板，然后在管道中使用它们，然后就像在CD管道中应该做的那样，编排工具，收集APM工具的响应或用户管理数据或正在运行的其他测试的响应，并将其与功能标志关联起来，以便您可以根据结果定义滚出和回滚策略。

所以如果你的用户测试结果，你知道，你可以在适当的地方设置门来查看你的用户测试结果，如果你知道，错过了5%，你就不能进入下一阶段推出你的功能。

因此，您可以进行检查，然后决定是继续推出您的特性，还是在您的管道中完全放弃该特性。

最后，正如DevOps和实践的任何变化一样，涉及到组织流程和文化的转变，这一点不应掉以轻心。

你必须在整个组织范围内考虑变化，人们也需要这样做

同时也要改变他们的思想和心态。

你需要接受这样一个事实:你可能会将不完整的代码发布到生产环境中，并且相信特性标志控制着实际公开的内容。

生产应用程序版本可能不再是唯一的真相来源。

对吧?您必须在生产中查看标记的状态，才能知道是什么

你的用户可以使用它。

然后你需要引入新的过程，你的测试和生产，你需要背后的过程，你在生产中测试的反馈或修订过程是什么，组织中谁正在发布特性，这种所有权正在发生变化，正如我之前提到的，所以你想要了解并开始改变发布的所有权，超出你的部署。

然后，当您开始在许多特性的发布中引入特性标志时，应该对特性标志进行管理，您需要确保有一种管理它们的方法。

否则，您将在代码中创建技术债务。

因此，这是一个逐步交付实践的旅程，你要确保你有CI\CD和功能标志的基础知识。

这其中应该有整合。

然后，通过该集成，您将获得公共可见性、公共治理、智能自动化，并最终通过整个流程的流程和文化转换部分实现企业渐进交付。

非常感谢你们今天的时间。

你知道，我欢迎任何问题。谢谢你！