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

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

2年前关闭。



Improve this question




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

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

编辑 - 补充问题 - 您的开发团队是否遵循“尽快提交并且经常甚至如果代码包含小错误或不完整”协议(protocol)或“提交-将代码提交到 DEVELOPMENT 分支时只有完美代码”协议(protocol)？

Answer 1

2019 年更新:

现在，这个问题会在使用 Git 的上下文中看到，并且使用了 10 年 distributed发展 workflow (主要合作 through GitHub)展示了一般的最佳实践:

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 的评论和讨论中记录了这样做与基于 Trunk-Based-Development 的历史。 .



(来源: Gitworkflow: A Task-Oriented Primer)

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

原始答案(2008 年 10 月，10 多年前)

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

首先，你的行李箱里的所有东西真的都是为了下一个版本吗？
您可能会发现目前开发的一些功能是:

太复杂了，还有待完善

未及时准备好

有趣但不适用于下一个版本

在这种情况下，trunk 应该包含任何当前的开发工作，但在下一个版本之前早期定义的发布分支可以作为 合并分行其中只合并适当的代码(为下一个版本验证)，然后在认证阶段修复，最后在投入生产时卡住。

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

第一组补丁实际上可能在首次发布到生产环境之前就开始了(这意味着您知道您将进入生产环境，但会遇到一些无法及时修复的错误，但您可以在单独的分支中启动针对这些错误的工作)

其他补丁分支将拥有从定义明确的生产标签开始的奢侈

当涉及到 dev 分支时，您可以拥有一个主干，除非您需要同时进行其他开发工作，例如:

大规模重构

测试可能会改变您在其他类中调用事物的方式的新技术库

新的发布周期的开始，需要合并重要的架构更改。

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

回答 Ville M. 的评论:

请记住，开发分支并不意味着“每个开发人员一个分支”(这会引发“合并疯狂”，因为每个开发人员都必须合并其他人的工作才能查看/获得他们的工作)，而是每个开发一个开发分支努力。

当这些工作需要合并回主干(或您定义的任何其他“主”或发布分支)时，这是开发人员的工作，而不是 - 我再说一遍，不是 - SC 经理(他们不知道如何解决任何冲突的合并)。项目负责人可能会监督合并，这意味着确保它按时开始/完成。

无论您选择谁来实际进行合并，最重要的是:

拥有单元测试和/或组装环境，您可以在其中部署/测试合并的结果。

定义了一个标签 之前 合并的开始，以便能够回到之前的状态，如果所述合并证明自己太复杂或太长而无法解决。