您如何维护开发代码和生产代码？ [关闭]答案

【问题标题】：How do you maintain development code and production code? [closed]您如何维护开发代码和生产代码？ [关闭]
【发布时间】：2010-09-17 23:44:49
【问题描述】：

在维护代码时应遵循哪些最佳做法和经验法则？在开发分支中只有生产就绪代码是一种好习惯，还是应该在开发分支中提供未经测试的最新代码？

你们如何维护开发代码和生产代码？

编辑 - 补充问题 - 您的开发团队是否遵循“尽可能尽快提交并且经常即使代码包含次要错误或不完整”协议或将代码提交到开发分支时的“仅提交完美代码”协议？

【问题讨论】：

我之前回答过一个类似的问题（或者好吧，在同一个空间/方向上的一个问题），所以你可能想看看这个问题：What are some good strategies to allow deployed applications to be hotfixable?
@revo：等等……我 2008 年的答案已经过时了？ :) 我想确实如此。已经 10 多年了：我已经编辑了我的答案。

标签： deployment version-control continuous-integration project-management branching-and-merging

【解决方案1】：

2019 年更新：

如今，问题将在使用 Git 的上下文中看到，并且使用 distributed 开发 workflow（主要协作 through GitHub）的 10 年显示了一般最佳实践：

master 是随时可以部署到生产中的分支：下一个版本，其中一组选定的功能分支合并到 master。
dev（或集成分支，或“next”）是为下一个版本选择的功能分支一起测试的分支
maintenance（或hot-fix）分支是当前版本进化/错误修复的分支，with possible merges back to dev and or master

那种工作流程（您不将 dev 合并到 master，但仅将功能分支合并到 dev，然后如果选中，则合并到 master，以便能够删除很容易功能分支还没有为下一个版本做好准备）在 Git 存储库本身中实现，使用 gitworkflow（一个词，illustrated here）。
在rocketraman/gitworkflow 上查看更多信息。在this article by Adam Dymitruk 的 cmets 和讨论中记录了这样做与基于主干的开发的历史。

^{（来源：Gitworkflow: A Task-Oriented Primer）}

注意：在该分布式工作流程中，您可以随时提交并将某些 WIP（正在进行的工作）推送到个人分支而不会出现问题：您将能够在将提交作为一部分之前重新组织（git rebase）您的提交功能分支。

原始答案（2008 年 10 月，10 多年前）

这完全取决于发布管理的顺序性

首先，您的行李箱中的所有东西是否真的适合下一个版本？您可能会发现目前开发的一些功能是：

太复杂了，还有待完善
没有及时准备好
很有趣，但不适用于下一个版本

在这种情况下，主干应该包含所有当前的开发工作，但在下一个版本之前定义的发布分支可以用作整合分支，其中只有适当的代码（已为下一个版本验证）被合并，然后在认证阶段修复，最后在投入生产时冻结。

当涉及到生产代码时，您还需要管理您的补丁分支，同时牢记：

第一组补丁实际上可能在第一次发布到生产之前就开始了（这意味着您知道您将进入生产时遇到一些您无法及时修复的错误，但您可以在单独的分支中启动这些错误的工作）
其他补丁分支将有幸从定义明确的生产标签开始

说到开发分支，你可以有一个主干，除非你有其他开发工作需要并行，比如：

大规模重构
测试新的技术库，这可能会改变您在其他类中调用事物的方式
开始新的发布周期，需要合并重要的架构更改。

现在，如果您的开发-发布周期非常连续，您可以按照其他答案的建议进行：一个主干和多个发布分支。这适用于所有开发肯定会进入下一个版本的小型项目，并且可以被冻结并作为发布分支的起点，在那里可以进行补丁。这是名义上的过程，但一旦你有一个更复杂的项目......它就不够了。

回答 Ville M. 的评论：

请记住，开发分支并不意味着“每个开发人员一个分支”（这会引发“合并疯狂”，因为每个开发人员都必须合并其他人的工作才能查看/获取他们的工作），而是一个开发人员每个开发工作的分支。
当这些工作需要合并回主干（或您定义的任何其他“主”或发布分支）时，这是开发人员的工作，不是 - 我重复一遍，不是 - SC 经理（谁不知道如何解决任何冲突的合并）。项目负责人可能会监督合并，这意味着要确保按时开始/完成。
无论您选择谁来实际执行合并，最重要的是：
- 拥有单元测试和/或组装环境，您可以在其中部署/测试合并结果。
- 在合并开始之前定义了一个标签之前，以便在合并证明自己太复杂或太长时能够返回到先前的状态解决。

【讨论】：

如何确保master（生产）和dev（集成）不发生分歧？尤其是热修复？您是否定期将master 合并回dev，例如发布后？
@Bergi 与 gitworflow，dev 是一个临时分支，在每个新版本的顶部删除并重新创建。那里没有分歧。
自最初发布以来已经超过 12 年了，但我想说这个答案仍然非常有用和最新。
@MatheusCirillo 谢谢马修斯。我实际上在 2019 年修改了这个答案，提到了gitworkflow。但我很高兴这仍然有用。

【解决方案2】：

我们使用：

开发分支独占

直到项目接近完成，或者我们正在创建一个里程碑版本（例如产品演示、演示版本），然后我们（定期）将我们当前的开发分支分支到：

发布分支

没有新功能进入发布分支。在发布分支中只修复重要的错误，修复这些错误的代码重新集成到开发分支中。

包含开发和稳定（发布）分支的两部分过程使我们的生活变得更加轻松，我不相信我们可以通过引入更多分支来改进其中的任何部分。每个分支也有自己的构建过程，这意味着每隔几分钟就会产生一个新的构建过程，因此在代码签入后，我们会在大约半小时内获得所有构建版本和分支的新可执行文件。

有时，我们还会为单个开发人员设立分支机构，该开发人员致力于一项未经证实的新技术，或创建概念验证。但通常只有在更改影响代码库的许多部分时才会这样做。这种情况平均每 3-4 个月发生一次，这样的分支机构通常会在一两个月内重新整合（或报废）。

一般来说，我不喜欢每个开发人员都在自己的分支中工作的想法，因为您“跳过并直接进入集成地狱”。我强烈建议不要这样做。如果你有一个共同的代码库，你应该一起工作。这使开发人员对他们的签入更加谨慎，并且每个编码员都知道哪些更改可能会破坏构建，因此在这种情况下测试更加严格。

关于提前入住的问题：

如果您只需要签入 PERFECT CODE，那么实际上什么都不应该签入。没有代码是完美的，为了让 QA 验证和测试它，它需要在development 分支，因此可以构建一个新的可执行文件。

对我们来说，这意味着一旦功能完成并由开发人员测试，它就会被签入。如果存在已知（非致命）错误，它甚至可能会被签入，但在这种情况下，会受到影响的人通常会通知错误。也可以签入不完整和正在进行的代码，但前提是它不会导致任何明显的负面影响，例如崩溃或破坏现有功能。

在构建新代码之前，不可避免的代码和数据组合检查会时不时地使程序无法使用。我们至少要做的是在签入评论中添加“等待建造”和/或发送电子邮件。

【讨论】：

我投了赞成票。这与我们所做的类似，但我们正在开发中进行所有更改，然后尝试将这些错误修复合并到发布分支中......不工作。但是，我认为如果我们更改为在发布中修复所有错误并合并到开发中，那将修复它。
你的意思是 QA 测试开发分支，如果他们检查发布分支不是更好吗？这样我就可以开始开发下一个版本中不会包含的新疯狂功能（并且可能会破坏某些东西），而那时 QA 将测试现有代码而不会干扰我的新功能？

【解决方案3】：

对于它的价值，这就是我们的做法。

大多数开发都是在主干中进行的，尽管可能会严重破坏系统的实验性功能或事物往往会获得自己的分支。这非常有效，因为这意味着每个开发人员在他们的工作副本中始终拥有最新版本的所有内容。

这确实意味着保持行李箱处于正常工作状态很重要，因为完全有可能完全破坏它。在实践中，这并不经常发生，也很少是重大问题。

对于生产版本，我们将主干分支，停止添加新功能，并进行错误修复和测试分支（定期合并回主干），直到它准备好发布。此时我们会最终合并到主干中以确保所有内容都在其中，然后释放。

然后可以根据需要在发布分支上执行维护，并且可以轻松地将这些修复合并回主干。

我不认为这是一个完美的系统（它仍然存在一些漏洞 - 我认为我们的发布管理还不够严格），但它运行良好。

【讨论】：

运行良好，对于纯代码非 vcs-druids 开发人员来说也足够简单。

【解决方案4】：

为什么没有人提到这个？ A successful Git branching model.

这对我来说是终极分支模型！

如果您的项目很小，请不要一直使用所有不同的分支（也许您可以跳过小功能的功能分支）。但除此之外，这就是这样做的方法！

【讨论】：

是的，除非它经常有点过于复杂/完整，如scottchacon.com/2011/08/31/github-flow.html 所示。
我同意。了解 git flow 分支模型（解决了很多问题）并简化它以满足您的需求。并且 GitHub 流需要快速部署，但这并不总是可能的......它或多或少是我们在我的项目中使用的分支模型（为了简单起见），但我们遇到了一个我们喜欢使用 git-flow 模型的情况：（这让我们陷入了真正的困境：（
在我看来，这基本上复制了大约 1 年前 VonC 所说的所有内容（在他的回答中），但以更详细的方式和漂亮的图片！

【解决方案5】：

分支上的开发代码，主干上标记的实时代码。

不需要“只提交完美的代码”规则 - 开发人员遗漏的任何东西都应该在四个地方得到解决：代码审查、分支测试、回归测试、最终 QA 测试。

下面是更详细的分步说明：

在一个分支上进行所有开发，并定期提交。
所有开发完成后对更改进行独立代码审查。
然后将分支传递给测试。
分支测试完成后，将代码合并到候选版本分支中。
Release Candidate 分支在每次合并后进行回归测试。
在所有开发分支合并后，在 RC 上执行最终 QA 和 UA 测试。
一旦通过 QA 和 UAT，将发布分支合并到 MAIN/TRUNK 分支。
最后，在该点标记主干，并将该标记部署到 Live。

【讨论】：

【解决方案6】：

dev 进入主干（svn 风格），发布（生产代码）有自己的分支

这是“按目的分支的模型”（The importance of branching models /!\ pdf 中的图 3）

【讨论】：

【解决方案7】：

我们通过将生产代码（主干）与开发代码（每个开发人员都有自己的分支）完全分离来解决这个问题。

在经过彻底检查（由 QA 和代码审查员）检查之前，不得将任何代码用于生产代码。

这样就不会混淆哪些代码有效，它始终是主分支。

【讨论】：

【解决方案8】：

哦，是的 - 另一件事 - 我们在 cvs HEAD 中保留了非生产代码（即永远不会发布的代码 - 例如工具脚本、测试实用程序）。通常它需要清楚地标记，所以没有人“意外”释放它。

【讨论】：

也许作为对上一个答案的编辑会更好。
他说的是 CVS。 :-)

【解决方案9】：

我们在主干上开发，然后每两周分支一次并投入生产。只修复了分支中的严重错误，其余的可以再等两周。

对于主干，唯一的规则是提交不应该破坏任何东西。为了管理 wip-code 和未经测试的代码，我们只需添加适当的 if 语句，以便于打开和关闭。

基本上可以随时分支主干并投入生产。

【讨论】：

【解决方案10】：

我使用 git，我有 2 个分支：master 和 maint

master - 开发代码
维护 - 生产代码

当我将代码发布到生产环境时，我标记它并将 master 合并到 maint 分支。我总是从 maint 分支进行部署。来自开发分支的补丁我会挑选它们到维护分支并部署补丁。

【讨论】：

【解决方案11】：

我们有一个“发布”分支，其中包含当前正在生产或将很快部署的内容（已通过大多数 QA）

每个项目，或者在某些情况下是其他单元，都有自己的分支，该分支是从发布分支出来的。

项目的开发人员将更改提交到他们项目自己的分支中。定期将发布合并回开发分支。

一旦分支上的工作包都经过 QA（单元测试、系统测试、代码审查、QA 审查等），该分支就会合并到发布分支中。新版本是从发布分支构建的，最终验证在该版本上进行。

在合并完成后发现问题之前，该过程基本上是可以的。如果 WP 在合并后“卡住”了，它会保留它之后的所有内容，直到它被修复（在卡住的发布之前，我们不能再发布一次）。

它也有点灵活 - 如果发布分支的发布时间非常短（比如 1-2 天左右），那么一个非常微不足道的更改可能会直接发生在发布分支上。

如果出于某种原因将更改直接投入生产（影响客户的关键生产问题，需要立即更改代码来修复），则这些更改将放回 BRANCH_RELEASE。这几乎不会发生。

【讨论】：

【解决方案12】：

这取决于项目。我们的 Web 代码非常一致地签入，而我们的应用程序代码只有在编译时才会签入。我注意到这与我们发布东西的方式非常相似。当应用程序遇到严格的最后期限时，Web 的东西就会尽可能地增加。不过，我没有看到这两种方法的质量下降。

【讨论】：