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

问题描述

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

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

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

解决方案

更新2019年：

这些天，问题是在使用Git的环境中可以看到，并且使用

^{（来源： Gitworkflow：面向任务的入门书）}

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

---

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

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

首先，行李箱中的所有物品是否真的要用于下一个版本？
您可能会发现一些当前开发的功能是：

• 太复杂了，仍然需要完善
>

• 未及时准备


• 有趣，但不适用于下一版本

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

对于生产代码，您还需要管理您的修补程序分支，同时请记住：

• 第一组修补程序实际上可能已经开始在首次发布到生产环境之前（这意味着您知道您将带着一些无法及时修复的错误进入生产环境，但是您可以针对这些错误启动工作一个单独的分支）


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

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

• 大规模重构


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


• 开始新的发布周期，其中需要合并重要的体系结构更改。

现在，如果您的开发发布周期非常长顺序，您可以按照其他答案的建议去：一个主干和几个释放分支。这适用于小型项目，这些项目的所有开发工作都将在下一个版本中进行，并且可以冻结并用作发行分支的起点，在该分支中可以进行补丁发行。那是正常的过程，但是一旦您有一个更复杂的项目……这已经不够了。

---

回答Ville M.的评论：

• 请记住，dev分支并不意味着每个开发人员一个分支（触发合并疯狂，因为每个开发人员都必须合并其他开发人员的工作才能看到/获得他们的工作），但是每个开发工作都需要一个dev分支。


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


• 无论您选择实际进行合并的哪个，最重要的是：
  
  
  
  
  • 具有单元测试和/或汇编环境，您可以在其中部署/测试合并结果。
  
  
  • 定义标签< $ li $ b $$ strong>在合并开始之前， ，以便能够恢复到先前的状态。
  
  

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屋！