问基于特性的多环境部署

EN

如果您在这样的环境中面临这样的问题，我建议您不要追求如此小的粒度。

1. 当您选择QA时，有五个特性的新版本，您做它是有原因的。业务人员希望它们一起交付，实现是紧密耦合的，等等。这些原因不受发布特性子集尚未准备好这一事实的影响。也就是说，通常不需要交付发布的子集。
2. 这种做法鼓励在整个链条上堆放未完成的功能，而不是集中精力于交付。它没有使瓶颈显现出来，而是产生了改善一切的错误冲动。
3. 通常，一个功能的注销是不够的，你必须注销整个应用程序到下一个阶段，并执行这个阶段的设置。每一个特征都会使这些努力倍增。
4. 为了减少偶尔需要推迟特定麻烦的特性，在一开始就注入切换。

你可能会做什么

1. 尝试各种大小的版本，看看是什么提供了最大的吞吐量。
2. 重新平衡优先级，从添加特性到交付特性。
3. 关于“单个分支”，您可能希望拥有与环境相同的分支链。在QA通过为INT准备好的所有标准之前，不允许从QA合并到INT，如果DEV还没有准备好，也不意味着从DEV立即合并到QA。

您还没有解释您目前在TFS中有多少分支。我不确定当前的过程，您遵循的功能发布。对不起，我正在重复下面同样的话。

我认为你可以做的是，有四个分支DEV，QA，INT和PROD。QA分公司应该是开发部门完成工作的最后一条质量保证线。

一个特性可以在DEV分支中进行多个检查，但应该合并到一起，并在合并到QA分支时创建一个变更集。如果修复错误或请求更改，则可以对同一特性从DEV更改到QA进行更多的更改。简而言之，QA分支应该完成并测试代码开发并为发布做好准备。

当功能发布时，QA分支的所有更改集都应该合并为一个变更集到INT分支。在INT环境上成功验证后，应该将其合并到PROD分支，然后从那里部署到PROD环境中。我在这里假设，您的INT环境一旦部署了该特性，它就会在那里停留一段时间，以检查它的稳定性。

从一个分支到另一个分支的选择性合并是这里的主要思想。您还需要为每个环境有单独的构建脚本。

此外，构建脚本应该配置为从各个分支获取代码。

如果您在VCS中没有任何分支，那么很难实现您想要的结果，这将更多的是手工工作而不是自动化。

除非将代码保存在单独的分支上，否则不能有选择地为单个特性提升代码。

我同意最好避免使用特性分支。如果在单独的特性分支上测试代码，您将不知道代码在合并时是否正确执行，而且当多个分支共存时，重构变得非常困难，因为一个分支中的重构代码可能无法与另一个分支中的非重构代码一起工作。

您还没有说明为什么需要将特定特性的代码保留在特定环境之外。我将尝试使用配置选项来打开或关闭每个环境中所需的特性，而不是将代码拒之门外。

我还会尝试对任何功能进行广泛的自动化测试，然后再批准。这应该可以保证它不会被未来将要部署的特性中的代码悄悄地打破。