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

 

维护代码时遵循的最佳实践和规则是什么？ 在开发分支中只有生产就绪代码是好的做法，还是应该在开发分支中提供未经测试的最新代码？

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

编辑 - 补充问题 - 你的开发团队是否遵循了“尽可能快地提交”，甚至是“即使是包含小错误或不完整”协议或“提交 - ONLY-perfect-code“协议，同时将代码提交给DEVELOPMENT分支？

这一切都取决于您的发布管理的顺序性

首先，你的后备箱里的一切都是为了下一个版本吗？ 您可能会发现一些当前开发的功能是：

  • 太复杂，仍然需要改进
  • 没有及时准备好
  • 有趣但不适合这个下一个版本

    • 在这种情况下，trunk应该包含任何当前的开发工作，但是在下一个版本之前早期定义的发布分支可以用作合并分支 ，其中只有合适的代码（针对下一版本进行验证）被合并，然后在认证阶段被修复，并在产品投入生产时最终冻结。

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

  • 第一套补丁程序可能实际上是在第一次发布到生产环境之前开始的（也就是说，您知道您将会投入一些不能及时修复的bug，但您可以在单独的分支中为这些缺陷创建工作）
  • 其他补丁分支将有奢侈品从一个明确的生产标签开始

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

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

    • 现在，如果您的开发周期非常连续，您可以按照其他答案的建议去做：一个主干和几个发布分支。 这适用于小型项目，其中所有的开发工作都将进入下一个版本，并且可以被冻结，并成为发布补丁的起点，补丁可以发生。 这是名义上的过程，但只要你有一个更复杂的项目......这是不够的。

    要回答Ville M.的评论：

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

    • 我们用：

  • 开发部门独家

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

  • 发布分支

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

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

    有时候我们也有单独的开发人员从事一种新的未经验证的技术，或者创建一个概念证明。 但通常只有在更改影响代码库的许多部分时才会这样做。 这种情况平均每3-4个月发生一次，这种分支通常在一两个月内重新整合（或报废）。

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

    在签入早期问题：

    如果您只需要检入PERFECT CODE ，那么实际上什么都不应该检入。没有代码是完美的，并且QA需要在开发分支中进行验证和测试，因此可以构建新的可执行文件。

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

    无论何时，不可避免的组合代码和数据签入都会使程序无法使用，直到新代码生成完成。 我们至少要在签入评论中添加“WAIT FOR BUILD”并/或发送电子邮件。

    对于它的价值，这是我们如何做到的。

    大多数开发都是在树干中进行的，尽管实验性功能或可能会破坏系统的东西显然倾向于获得他们自己的分支。 这很好，因为它意味着每个开发人员总是在其工作副本中拥有最新版本的所有内容。

    这确实意味着将躯干保持在模糊的工作状态是非常重要的，因为完全可以将其彻底打破。 在实践中不经常发生，并且很少是一个重大问题。

    对于产品发布，我们分支主干，停止添加新功能，并开始修复和测试分支（定期合并回主干），直到它准备好发布。 在这一点上，我们做了一个最终的并入，以确保一切都在那里，然后释放。

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

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

    链接地址: http://www.djcxy.com/p/45041.html

    上一篇: How do you maintain development code and production code?

    下一篇: How do I merge changes to a single file, rather than merging commits?