渐进式交付时代的发布管理

然后介绍特性标志的使用如何影响渐进式交付，最后介绍希望采用渐进式交付作为实践的企业的主要考虑事项。

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

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

因此，简单地说，特性标志是代码中的if语句。

因此，如果您的特性标志是启用的，那么该代码将暴露给您已识别的用户。

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

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

现在CI / CD工具链中的这种用法和标准化正在不断增长

而且在不同的公司之间。

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

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

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

团队优先考虑软件的可部署性，而不是功能，你知道，开发新功能。

任何人都可以获得关于其系统的生产准备情况的自动化反馈，您可以在任何环境中执行按钮部署，因此很多都是关于自动化的，然后，在类似生产的环境中，代码被推送以便在生产前测试您的代码。

所以CI / CD实践是渐进式交付的基础，但就持续交付而言，即使你做得很好，也需要考虑如何改进?您是否能够适应从持续交付到持续部署(每次签入都可以自动推送到生产环境中)的转变?

沿途没有手动停止。

你愿意在周五部署吗?

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

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

这是我们将会讨论的更多内容，即关注…测试的焦点已经向左转移，但也向右转移到您的生产环境中，在那里您正在与真实用户进行测试。

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

这样你就可以保持对用户的控制，让他们看到功能和质量。

所以你是在逐步地将你的功能推向特定的选择群组，这限制了当你部署新功能时受到影响的爆炸半径

一旦你在较小的群体中进行了测试，这组选定的用户就可以

要有信心开始将其推广到越来越大的组，直到将您的特性推广到所有用户为止。

这是渐进式部署，你有特性标志，用来控制特性如何推出。

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

因此，只有在实际启用新版本中的新特性时，才可以部署到生产环境中。

你真的要发布新版本吗?

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

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

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

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

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

但是这种方法仍然存在局限性，您可能会提高速度并更频繁地向用户提供新功能，但这也会带来缩短周期的风险。

你交付给产品、交付给用户的所有东西都需要为用户准备好。

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

所以你需要做大量的前期工作，这样你才会有信心

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

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

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

可能在您的生产环境中。

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

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

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

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

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

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

一个带有Canary版本的传统版本。

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

部署新代码时的生产环境。

在这种情况下，控制位于基础设施网络层。

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

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

这种方法允许在您的生产环境中对一小群用户进行特性测试，这很好，您可以完成测试。

但也有很多挑战。

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

有，你知道，有限的方法来确定测试新功能的用户，你没有控制和所有类型的用户的输入，你知道，我们在网络层有控制。

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

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

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

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

在本例中，金丝雀部署带有特性标志。

控件位于应用程序层，允许您限制其暴露

用户可以看到新的变化，无论是内部测试者、beta用户还是基于百分比的发布。

你可以很好地控制那些开始看到新功能的用户群。

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

在这种情况下，在这个图表中，你可以看到有了特征标志，

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

因此，版本二部署在中间的盒子中，但功能本身只向一小部分用户开放。

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

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

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

随着时间的推移，对所有用户都是开启的。

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

从完整的产品发布心态转向功能关注。

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

你需要注意的几件事是，

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

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

另一件你必须考虑的事情是随之而来的过程和文化变化，因为新的团队成员将有不同的责任，而不是运营，你知道，部署和部署后，你要把开发和产品团队带回到部署后的功能展示中。

因此，让我们进一步分析发布与功能粒度和控制在整个发布中的真正含义。

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

在最上面一行，我们有传统的CD过程，我们有这个释放

所有的功能都包含在一起，从功能一到功能四。

今天，大多数公司都在使用这个模型，在这个模型中，编排是发布版本级别，如果正在交付的任何一个特性出现问题，整个发布都可能被推迟或停止。

在这种情况下，我们有四个阶段在测试阶段，在提交之后

当构建完成后，我们发现第三个特性的bug比我们能处理的要多，现在我们不得不删除整个版本来修复这些bug。

所以一旦这些错误被修复，

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

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

因此，我们不能只看功能4，现在我们必须回滚整个版本来修复这个问题。

因此，我们正在回滚版本，等待第四个特性得到修复，然后再将新版本投入整个流程并重新部署到生产中。

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

现在让我们看看下面一行，我们有一个具有特性粒度的版本。

再一次，我们有四个特性通过提交和构建。

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

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

使用一个特性标志，关闭特性3，然后继续我们的部署。

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

我们再次发现，功能四不被接受，但它只是暴露

在我们能够做出响应并在生产环境中关闭该功能之前，一小部分用户看到了该功能。

再次强调，我们不会回滚整个版本。

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

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

第四个功能正在开发中，稍后会部署。

所以你在这里能做的就是添加。

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

在特性的转出和回滚中，这样您就能够响应用户，而不会造成延迟和回滚，从而在整个过程中引入风险。

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

而不是一次全部编排，您正在查看您能够控制的功能的集合。

所以这意味着一组功能不会因为其中一个有bug而阻碍发布。

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

需要修复的bug。

你还可以限制不完整或有缺陷的功能的曝光，你可以把它们，你知道，缩小到它的内部

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

我们再来比较一下传统CD和带有特征标志的CD。

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

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

而不是看环境和环境的状态，有哪些版本，

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

您的测试正在发生变化，就在您与实际用户进行生产测试的地方。

你可以用专注于什么的粒度与用户进行测试

是这些用户的特征。

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

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

当您的业务要求您在需要时推出功能。

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

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

在需要时回滚更改。

你认为，你可以一次性地做这个也许有特征标记，但你如何到达这个地方并把它变成一种实践，你能够在用户身上测试

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

所以让我们来谈谈如何实现这一目标。

在基础上，您将需要持续集成。

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

持续交付，您再次需要在您的CD过程中具有一定的成熟度，并具有适当的自动化。

因此，当您能够将代码投入生产时，这不是手工灭火演习，而是有一个管道将您的代码编排或推送到生产中。

沿途可能会有手动停止，但这背后有一个过程。

再说一次，这是持续交付，我们有一个误解

你需要持续的部署来实现逐步的交付

但是，当您能够在持续交付中引入特性标记时，您就可以将逐步交付作为一种实践。

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

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

然后所有这些结合在一起，CI\CD和特性标志结合在一起，成为推动渐进式交付的集成主干。

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

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

是否应该成为你发布版本的一个输入，在那里你可以看到你发布版本中正在交付的部分功能的有效负载?

您需要了解哪些功能限制了您的环境

在你的发行版中对给定环境的可见性?

存在哪些特性标志?你在管道中看到的所有这些特性标志的当前状态是什么?

那么释放标准是什么呢?

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

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

接下来是公共治理和控制，您需要能够将特性标志作为CD管道的一部分进行控制。

因此，您需要能够通过自动更改单个特征的值

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

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

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

下一步是在CD管道上创建一些带有特性标志的智能自动化。

所以你希望能够定义可以跨功能和管道使用和重用的功能发布模板，在那里你可以决定是基于百分比的推出还是基于环的推出，你可以从小规模开始，从内部员工到测试版再到GA用户。

所以定义你的模板，然后在你的管道中使用它们，然后你应该在你的CD管道中使用它们，编排你的工具，收集你的APM工具或你的用户管理数据或其他正在运行的测试的响应，并将其与特性标志相关联，这样你就可以根据结果定义推出和回滚策略。

如果你的用户测试结果是，你可以设置闸门来检查你的用户测试结果，如果你错过了5%你就不会进入下一阶段推出你的功能。

因此，您可以将检查放在适当的位置，然后决定是继续推出您的功能，还是在您的管道中完全关闭该功能。

最后，您知道，随着DevOps和实践的任何变化，都涉及到组织流程和文化的转变，这一点不应掉以轻心。

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

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

您需要接受这样一个事实:您可能会将不完整的代码发布到生产环境中，并相信功能标志正在控制实际暴露的内容。

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

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

你的用户可以使用。

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

然后应该管理功能标志，当你开始在发行版中引入许多功能标志时，你需要确保你有一种管理它们的方法。

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

因此，这是一段通往渐进式交付实践的旅程，您需要确保掌握了CI\CD和特性标志的基础知识。

这里应该有一个积分。

然后，通过这种集成，您将获得共同的可见性、共同的治理、智能自动化，并最终通过整个过程的过程和文化转换部分实现企业渐进式交付。所以非常感谢你们今天的时间。我欢迎大家提问。谢谢你！

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

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

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

但是这种方法仍然存在局限性，您可能会提高速度并更频繁地向用户提供新功能，但这也会带来缩短周期的风险。

你交付给产品、交付给用户的所有东西都需要为用户准备好。

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

所以你需要做大量的前期工作，这样你才会对此有信心，否则你的版本就会出现回滚。

CD中的大部分测试都是在生产前完成的，在生产环境中可能会缺少一些真实世界的因素，要在生产环境中拥有一个包含所有因素的生产前环境是非常困难的。

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

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

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

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

因此，让我们回过头来看看渐进式交付如何在传统版本中与Canary版本一起工作。

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

在这种情况下，控制位于基础设施网络层。

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

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

这种方法允许在您的生产环境中对一小群用户进行特性测试，这很好，您可以完成测试。

但也有很多挑战。

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

有，你知道，有限的方法来确定测试新功能的用户，你没有控制和所有类型的用户的输入，你知道，我们在网络层有控制。

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

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

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

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

在本例中，金丝雀部署带有特性标志。

控件位于应用程序层，允许您限制其暴露

用户可以看到新的变化，无论是内部测试者、beta用户还是基于百分比的发布。

你可以很好地控制那些开始看到新功能的用户群。

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

因此，在这种情况下，通过图表，您可以看到使用特性标志，新版本已部署到您的环境中。

因此，版本二部署在中间的盒子中，但功能本身只向一小部分用户开放。

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

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

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

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

您需要注意的一些事情是，如果您不知道某个特性标志在生产环境中是打开还是关闭，那么您需要考虑测试这两种状态。

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

另一件你必须考虑的事情是随之而来的过程和文化变化，因为新的团队成员将有不同的责任，而不是运营，你知道，部署和部署后，你要把开发和产品团队带回到部署后的功能展示中。

因此，让我们进一步分析发布与功能粒度和控制在整个发布中的真正含义。

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

所以在最上面一排，我们有传统的CD流程，我们有这个版本，所有的功能都包括在一起，从功能一到功能四。

今天，大多数公司都在使用这个模型，在这个模型中，编排是发布版本级别，如果正在交付的任何一个特性出现问题，整个发布都可能被推迟或停止。

在这种情况下，我们有四个阶段在测试阶段，在提交之后

当构建完成后，我们发现第三个特性的bug比我们能处理的要多，现在我们不得不删除整个版本来修复这些bug。

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

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

因此，我们不能只看功能4，现在我们必须回滚整个版本来修复这个问题。

因此，我们正在回滚版本，等待第四个特性得到修复，然后再将新版本投入整个流程并重新部署到生产中。

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

现在让我们看看下面一行，我们有一个具有特性粒度的版本。

再一次，我们有四个特性通过提交和构建。

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

而不是在整个发布中出现意想不到的延迟，我们可以只使用一个特性标志，关闭特性3，然后继续我们的部署。

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

我们再次发现特性四不太被接受，但在我们能够做出响应并在生产中关闭该特性之前，它只暴露给一小部分看到该特性的用户。

再次强调，我们不会回滚整个版本。

这是一个简单的切换，功能一和功能二仍在生产中，可以继续向其他用户推出，而功能三和功能四正在开发中，你知道，将在稍后的时间部署。

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

在特性的转出和回滚中，这样您就能够响应用户，而不会造成延迟和回滚，从而在整个过程中引入风险。

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

而不是一次全部编排，您正在查看您能够控制的功能的集合。

所以这意味着一组功能不会因为其中一个有bug而阻碍发布。

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

你还可以限制不完整或有缺陷的功能的曝光，你可以将其缩小到只有内部开发人员能够看到该功能并继续开发该功能。

我们再来比较一下传统CD和带有特征标志的CD。

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

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

您的测试正在发生变化，就在您与实际用户进行生产测试的地方。

您可以对用户进行测试，重点关注这些用户的特征。

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

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

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

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

你认为，你可以一次性地做这个也许有特征标记，但你如何到达这个地方并把它变成一种实践，你能够在用户身上测试

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

所以让我们来谈谈如何实现这一目标。

在基础上，您将需要持续集成。

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

持续交付，您再次需要在您的CD过程中具有一定的成熟度，并具有适当的自动化。

因此，当您能够将代码投入生产时，这不是手工灭火演习，而是有一个管道将您的代码编排或推送到生产中。

沿途可能会有手动停止，但这背后有一个过程。

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

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

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

然后所有这些结合在一起，CI\CD和特性标志结合在一起，成为推动渐进式交付的集成主干。

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

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

您需要了解哪些功能限制了您的环境

在你的发行版中对给定环境的可见性?

存在哪些特性标志?你在管道中看到的所有这些特性标志的当前状态是什么?

那么释放标准是什么呢?

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

接下来是公共治理和控制，您需要能够将特性标志作为CD管道的一部分进行控制。

所以你需要能够在每个阶段通过管道自动更改单个功能的值，更新功能的目标用户，然后使用访问控制和更改权限来控制功能标志。

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

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

下一步是在CD管道上创建一些带有特性标志的智能自动化。

所以你希望能够定义可以跨功能和管道使用和重用的功能发布模板，在那里你可以决定是基于百分比的推出还是基于环的推出，你可以从小规模开始，从内部员工到测试版再到GA用户。

所以定义你的模板，然后在你的管道中使用它们，然后你应该在你的CD管道中使用它们，编排你的工具，收集你的APM工具或你的用户管理数据或其他正在运行的测试的响应，并将其与特性标志相关联，这样你就可以根据结果定义推出和回滚策略。

如果你的用户测试结果是，你可以设置闸门来检查你的用户测试结果，如果你错过了5%你就不会进入下一阶段推出你的功能。

因此，您可以将检查放在适当的位置，然后决定是继续推出您的功能，还是在您的管道中完全关闭该功能。

最后，您知道，随着DevOps和实践的任何变化，都涉及到组织流程和文化的转变，这一点不应掉以轻心。

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

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

您需要接受这样一个事实:您可能会将不完整的代码发布到生产环境中，并相信功能标志正在控制实际暴露的内容。

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

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

你的用户可以使用。

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

然后应该管理功能标志，当你开始在发行版中引入许多功能标志时，你需要确保你有一种管理它们的方法。

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

因此，这是一段通往渐进式交付实践的旅程，您需要确保掌握了CI\CD和特性标志的基础知识。

这里应该有一个积分。

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

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

欢迎大家提问。谢谢你！