随着我们变得越来越大，我们开始遇到问题，其中的功能使其可以分阶段进行测试，但是到所有测试和批准的新功能都在分阶段进行测试时。

这创造了一个环境，在该环境中我们几乎永远无法投入生产，因为我们拥有经过测试和未经测试的功能的组合。我敢肯定这是一个普遍的问题，但是我还没有找到对我们有用的资源。

一些细节：

• BitBucket上的GIT
• Jenkins用于脚本部署到Azure

我希望找到一种隔离特征的方法，使它们在环境中移动并仅推送准备就绪的产品。

听起来您这里有一些问题：

1.识别特定版本的功能

这是一个项目管理问题，也是一个协调问题。将这种功能被释放之前，在同一时间，或在此之后的其他功能？如果发布一次要发生一项功能，请确定该功能。如果要将功能分组到版本中，请找出分组的含义，并与开发人员和决策者一起实施。使用问题跟踪或票证系统标记发布。明确指出，如果特定版本的一项功能是不可行的，那么所有功能都可以。

2.分支策略

git-flow是解决此类问题的简单答案，而且人们通常会使用git-flow的变体，即使他们不知道它是什么。我不会说这是所有问题的通盘，但它会有所帮助。

听起来您似乎遇到了不确定性发布策略的问题，这些功能已被认可为分散的功能，而早已开始开发的功能可能会在最近开始的功能发布之后发布-跨越式功能。

长期存在的功能分支或同时发布的分支可能是此类问题的最佳答案。将最新信息从master合并（或重新设置，如果您愿意的话）到您长期运行的分支中。注意仅合并已经存在的功能，否则会遇到您现在遇到的问题（一个分支上太多混合的功能）。

“ Hotfix”或“ Bugfix”分支是此过程的重要组成部分。将它们用于质量检查周期较短的一次性修补程序。

根据您的描述，最好不要保留官方的“开发”分支。而是将所有功能从master分支出来，并在确定发布后创建合并的发布分支。

3.环境

不要将git分支与您的环境匹配，生产== master除外。“开发”分支应假定为已损坏。发行分支被推送到测试环境，无论是QA环境还是登台环境。如果需要，将特定功能分支推送到环境。

如果您有多个功能分支需要分别发布，但需要同时进行测试..... \ _（ツ）_ // .....启动另一台服务器？也许将它们合并到一个废弃分支中……对原始分支进行修复/更改，然后重新合并到废弃分支中；在各个发行分支上进行最终批准和UAT。

4.从分支中删除未经批准的功能

这就是上述想法试图避免的事情，因为毫无疑问，这是尝试去做的最痛苦的事情。如果幸运的话，功能已使用合并提交功能自动合并到开发或测试分支中。如果您不走运，开发人员将直接致力于开发/测试分支。

无论哪种方式，如果你准备释放，并有未经批准的变更，就需要使用Git用背出发布分支那些未经批准的提交; 最好的想法是在测试发行版之前执行此操作。

祝你好运。

这是一个想法，停止使用发布分支。相反，开始构建功能切换并通过配置对其进行管理。这样，您总是将功能分支合并到master中，永远不会有关于测试或生产哪个版本的问题。如果您对环境中的哪些功能/实现有疑问，只需检查配置文件即可。

这应该是测试和生产之间的简单协调问题。如果您在Git中使用功能分支，只需在测试周期内停止将已完成的功能分支推送到“测试”，然后在测试完成时恢复。

如果您需要比这更好的控制，请将测试分为开发服务器和验收测试服务器，并与测试团队协调将被推送到验收测试服务器的那些分支。然后，有人可以负责启动从验收测试到生产的最终部署。

工作堆积

根据我的经验，这是一个普遍的问题。我用以下方式解决：

• 产品负责人对功能发布进行强有力的管理
• 确保合并分支时将其删除
• 限制进行中的工作（在Jira中限制列）
• 季度审查失效的旧票，包括错误和功能
• 回顾讨论问题的组成部分
• 不断鼓励所有人进行代码审查
• 配对机会以​​解决长期存在的问题
• 季度会议审查和清理旧票
• 使开发人员，产品和QA / QE紧密合作的团队方法
• 良好的报告和工具，以使新产品功能和待办事项显而易见
• 查看会话以遍历旧分支并将其删除

分行

您需要一些分支来控制该过程：

• 特点：这个分支是从大师那里诞生的。使用某些项目管理应用程序来识别具有某些任务的每个功能分支。例如，如果使用TRAC，则分支如：1234-user-crud，1235-bug-delete-catalog等将结束。还要用任务号标识提交，这将在合并中遇到问题时为您提供很多帮助（您将）。
• 测试：完成的所有功能分支都将合并到测试分支。您永远不会将测试分支合并到某个功能分支中，因为您不想要来自生产环境（主版）中其他功能的代码。对于release分支机构同样有效。
• release：当您决定生产中可以使用哪些经过测试的功能时，可以将该分支（再次...）合并到该分支中。您需要再次测试所有功能，因为这种合并会带来新的问题。测试并完成发行版后，您可以将此分支合并到master，并在master上为该版本创建标签。
• master：仅包含生产代码。

参见git flow：

                              |FEAT_2|
                                  |
                             .---C06<-------.---------.
                            /                \         \
                           /   |FEAT_1|        \         \
                          /       |            \         \
                         /    .--C07<--.--------\---------\---------.
                        /    /          \        \  |TEST| \         \
                       /    /            \        \    |    \         \
                      /    /        .-----`--C09<--`--C10    \         \ |RELEASE|
                     /    /        /                          \         \    |
    <v4.6.0>        /    /        /                       .----`--C11<---`--C12<--.
       |           /    /        /                       /                         \
C01<--C02<--C04<--´----´--------´-----------------------´---------------------------`--C13
 |           |                                                                          |
<v4.5.0>  <v4.6.1>                                                                   |MASTER|
                                                                                        |
                                                                                     <v4.7.0>

环境环境

很简单的：

• 测试：此环境使用测试分支。
• release：此环境使用实际的release分支。

开发人员在自己的机器上工作，每个人都使用自己的数据库。如果不可能每个开发人员都有一个单独的数据库（由于许可证，数据库大小等），那么在开发人员之间共享数据库将遇到很多问题：当某人删除其分支中的列或表时，其他人分支仍然在数据库中的此列/表中计数。

问题

此过程中最大的问题是合并。

您需要在test和中重新进行相同的合并release。如果在代码中进行了一些很好的重构，例如删除类，移动/重命名方法等，这将很痛苦。由于您无法将代码从test（或release）分支获取到功能分支，因此只能在以下位置解析合并提交：的test（或release）。因此，您最终在两个不同的分支中解决了相同的冲突，可能在每次合并中生成不同的代码，并且将来，您会发现测试团队将需要对功能进行两次测试：在test和release分支中，因为每次合并可能会导致不同的错误。

另一个问题是test分支。您将需要master不时地“回收”该分支（从中删除并创建一个新分支），因为那里的一些旧分支（或旧合并，已删除的合并分支）可能为新代码带来很多问题，与里面的东西大不相同master。此时，您需要控制要在中再次合并的分支test。

真正最好的解决方案是业务团队知道在下一版本中需要交付什么，并且每个人都在唯一的分支（开发分支）中工作。对于他们来说，有可能随时选择他们想要在下一版本中使用的“完成”功能（我认为这是您的情况），但这对于开发人员和（我相信）这都是一场噩梦。测试团队。

听起来好像您正在将集成分支中的更改合并到生产分支中，这正是您提到的原因，恕我直言，这不是一个好习惯。只要某个版本的生产分支从主集成分支中撤出，集成分支就可以随时分开（毕竟应该发展到下一个版本）。从Integration分支合并到当前版本分支会带来与该版本不兼容的更改。

恕我直言，一个适当的过程将是：

• 仅在认为集成产品与所需质量水平足够接近时才从集成产品分支中撤出生产分支，以便进一步期望只有少量更改才能完成发布。换句话说，在拉动生产分支之前，应在集成分支上（连续）评估功能完成情况。
• 在拉出生产分支之后，仅带来经过精心挑选的更改，将其视为独立/定点更改-即验证它们是否确实按预期工作（只是因为更改在一个分支中起作用并不一定意味着它也起作用在另一个分支中）。

就个人而言，这听起来可能是过程问题，而不是工具问题。我在这里建议一些注意事项：

• 我不确定您是否有单独的开发和质量检查小组。如果这样做，请确保Dev和QA都参与冲刺计划和评估会议。在我以前的一家公司中，我们确保为故事分配的故事点数同时考虑了开发和测试工作。（理论上，您也可以对开发和质量检查的工作有两个单独的估计，但是您需要以两种方式将估计都包括在内；一个故事所需的时间就是实际交付它的时间）。即使您没有单独的质量检查小组，也请确保在评估中包括测试工作。
• 与上述类似，请事先就特定冲刺中要包含的故事数达成一致。你接受的故事点数是根据你的开发人员可以在他们的终点冲刺的金额和物品QA可以在自己的冲刺测试的数量。（当然，我假设QA冲刺落后于Dev冲刺，但您可以对此进行调整）。如果您的开发人员可以完成200个故事点，但是您的质量检查仅可以完成150个故事点，那么显然您只能在工作开始“堆积”之前完成150个故事点，最终您得到的案例就是您所描述的。（在这种情况下，您可能需要调查造成障碍的原因以尝试减轻障碍）。
• 在测试和交付当前质量检查中的所有内容之前，没有人会推动质量检查。
• 一项完整功能是已测试并交付的功能。如果未交付，则不会完成。
• 显然，您想尝试以某种固定的时间表执行此操作。持续集成和敏捷背后的全部思想之一就是迭代。根据定义，迭代需要频繁交付。频繁的集成和交付使每一项风险最小化。

老实说，我认为最大的事情将是关于何时交付以及在给定时间内实际上可以完成多少任务的纪律性。

总结：仅在完成测试并交付旧功能后才交付质量检查。

当“一切都经过测试和批准”时，将经过测试和批准的内容部署到生产中。那可能是一个特定的提交，或者可能是詹金斯生成的特定构建工件。

稍后对同一分支上的提交尚未进行测试也没关系。