你如何维护开发代码和生产代码? [英] How do you maintain development code and production code?

问题描述

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

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

编辑 - 补充问题 - 您的开发团队是否遵循尽可能早地提交并且经常甚至如果代码包含小错误或不完整"协议或将代码提交到 DEVELOPMENT 分支时的仅提交完美代码"协议?

解决方案

2019 年更新:

现在，这个问题会在使用 Git 的上下文中看到，并且使用了 10 年的

^{(来源:Gitworkflow:面向任务的入门)}

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

<小时>

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

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

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

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

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

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

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

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

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

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

<小时>

回答 Ville M. 的评论:

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

What are the best practices and rules-of-thumb to follow while maintaining code? Is it good practice to have only the production ready code in the development branch, or should untested latest code be available in the development branch?

How do you guys maintain your development code and production code?

Edit - Supplementary question - Does your development team follow "commit-as-soon-as-possible-and-often-even-if-the-code-contains-minor-bugs-or-is-incomplete" protocol or "commit-ONLY-perfect-code" protocol while committing code to DEVELOPMENT branch?

解决方案

Update 2019:

These days, the question would be seen in a context using Git, and 10 years of using that distributed development workflow (collaborating mainly through GitHub) shows the general best practices:

• master is the branch ready to be deployed into production at any time: the next release, with a selected set of feature branches merged in master.
• dev (or integration branch, or 'next') is the one where the feature branch selected for the next release are tested together
• maintenance (or hot-fix) branch is the one for the current release evolution/bug fixes, with possible merges back to dev and or master

That kind of workflow (where you don't merge dev to master, but where you merge only feature branch to dev, then if selected, to master, in order to be able to drop easily feature branches not ready for the next release) is implemented in the Git repo itself, with the gitworkflow (one word, illustrated here).
See more at rocketraman/gitworkflow. The history of doing this vs Trunk-Based-Development is noted in the comments and discussions of this article by Adam Dymitruk.

^{(source: Gitworkflow: A Task-Oriented Primer)}

Note: in that distributed workflow, you can commit whenever you want and push to a personal branch some WIP (Work In Progress) without issue: you will be able to reorganize (git rebase) your commits before making them part of a feature branch.

---

Original answer (Oct. 2008, 10+ years ago)

It all depends of the sequential nature of your release management

First, is everything in your trunk really for the next release? You might find out that some of the currently developed functions are:

• too complicated and still need to be refined
• not ready in time
• interesting but not for this next release

In this case, trunk should contain any current development efforts, but a release branch defined early before the next release can serve as consolidation branch in which only the appropriate code (validated for the next release) is merged, then fixed during the homologation phase, and finally frozen as it goes into production.

When it comes to production code, you also need to manage your patch branches, while keeping in mind that:

• the first set of patches might actually begin before to first release into production (meaning you know you will go into production with some bugs you can not fix in time, but you can initiate work for those bugs in a separate branch)
• the other patch branches will have the luxury to start from a well-defined production label

When it comes to dev branch, you can have one trunk, unless you have other development efforts you need to make in parallel like:

• massive refactoring
• testing of a new technical library which might change the way you calls things in other classes
• beginning of a new release cycle where important architectural changes need to be incorporated.

Now, if your development-release cycle is very sequential, you can just go as the other answers suggest: one trunk and several release branches. That works for small projects where all the development is sure to go into the next release, and can just be frozen and serve as a starting point for release branch, where patches can take place. That is the nominal process, but as soon as you have a more complex project... it is not enough anymore.

---

To answer Ville M.'s comment:

• keep in mind that dev branch does not mean 'one branch per developer' (which would trigger 'merge madness', in that each developer would have to merge the work of other to see/get their work), but one dev branch per development effort.
• When those efforts need to be merged back into trunk (or any other "main" or release branch you define), this is the work of the developer, not - I repeat, NOT - the SC Manager (who would not know how to solve any conflicting merge). The project leader may supervise the merge, meaning make sure it starts/finish on time.
• whoever you choose for actually doing the merge, the most important is:
  • to have unit tests and/or assembly environment in which you can deploy/test the result of the merge.
  • to have defined a tag before the beginning of the merge in order to be able to get back to previous state if said merge proves itself too complex or rather long to resolve.

这篇关于你如何维护开发代码和生产代码?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！