维护代码时要遵循的最佳实践和经验法则是什么？在开发分支中只有生产就绪代码,或者开发分支中是否有未经测试的最新代码,这是一种好的做法吗？
你们如何维护开发代码和生产代码？
编辑 - 补充问题 - 您的开发团队是否遵循"尽快提交 - 通常 - 甚至是代码包含 - 次要错误或不完整"协议或"提交 - 只有完美的代码"协议,同时将代码提交给开发分支？
这完全取决于发布管理的顺序性
首先,你的后备箱中的所有东西是否真的适合下一个版本？您可能会发现一些当前开发的功能是:
太复杂,仍需要改进
还没准备好
有趣但不适用于下一个版本
在这种情况下,trunk应该包含任何当前的开发工作,但是在下一个版本之前定义的发布分支可以作为合并分支,其中只合并适当的代码(验证下一个版本),然后在认证阶段修复,并最终冻结,因为它投入生产.
在生产代码方面,您还需要管理补丁分支,同时请记住:
第一组补丁可能实际上是在第一次发布到生产之前开始的(意味着你知道你将投入生产时遇到一些你无法及时解决的错误,但是你可以在一个单独的分支中启动那些错误的工作)
其他补丁分支将从一个定义明确的生产标签开始
当涉及到dev分支时,你可以有一个主干,除非你需要进行其他开发工作,例如:
大规模的重构
测试新的技术库,这可能会改变你在其他课程中调用内容的方式
新版本周期的开始,需要将重要的架构变更纳入其中.
现在,如果你的开发 - 发布周期是非常顺序的,你可以像其他答案所说的那样:一个主干和几个发布分支.这适用于小型项目,其中所有开发都必须进入下一个版本,并且可以冻结并作为发布分支的起点,可以在其中进行补丁.这是名义上的过程,但只要你有一个更复杂的项目......它就不够了.
回答Ville M.的评论:
请记住,dev分支并不意味着"每个开发人员一个分支"(这将触发"合并疯狂",因为每个开发人员必须合并其他人的工作以查看/获取他们的工作),但每个开发人员需要一个dev分支努力.
当这些努力需要合并回主干(或你定义的任何其他"主要"或发布分支)时,这是开发人员的工作,而不是 - 我再说一遍,不是 - SC经理(谁不知道如何解决)任何冲突的合并).项目负责人可以监督合并,这意味着确保它按时开始/结束.
无论你选择谁实际进行合并,最重要的是:
具有单元测试和/或组装环境,您可以在其中部署/测试合并的结果.
在合并开始之前定义了一个标记,以便能够返回到先前的状态,如果所述合并证明自己太复杂或者很难解决.
我们用:
开发部门专门
直到项目接近完成,或者我们正在创建里程碑版本(例如产品演示,演示版本),然后我们(定期)将我们当前的开发分支分支到:
发布分支
没有新功能进入发布分支.只有重要的错误在发布分支中得到修复,修复这些错误的代码重新集成到开发分支中.
具有开发和稳定(发布)分支的两部分流程使我们的生活变得更加轻松,我不相信我们可以通过引入更多分支来改进它的任何部分.每个分支也有自己的构建过程,这意味着每隔几分钟就会产生一个新的构建过程,因此在代码检查之后,我们会在大约半小时内获得所有构建版本和分支的新可执行文件.
有时,我们还为一位开发人员提供分支机构,从事新的未经验证的技术,或创建概念验证.但通常只有在更改影响代码库的许多部分时才会执行.这种情况平均每3-4个月发生一次,这样的分支通常会在一两个月内重新整合(或报废).
一般来说,我不喜欢每个开发人员在自己的分支机构工作的想法,因为你"跳过去直接转向集成地狱".我强烈建议不要这样做.如果你有一个共同的代码库,你应该一起工作.这使得开发人员对其签名更加谨慎,并且根据经验,每个编码人员都知道哪些更改可能会破坏构建,因此在这种情况下测试更加严格.
在办理登机手续的早期问题:
如果您只需要签入PERFECT CODE,那么实际上什么都不应该被检入.没有代码是完美的,并且QA需要验证和测试它,它需要在开发分支中,以便可以构建新的可执行文件.
对我们而言,这意味着一旦某个功能完成并由开发人员进行测试,就会检查它.甚至可以检查是否存在已知(非致命)错误,但在这种情况下,受该错误影响的人员是通常告知.还可以检查不完整和正在进行的代码,但前提是它不会导致任何明显的负面影响,例如崩溃或破坏现有功能.
偶尔出现一个不可避免的组合代码和数据签入将使程序无法使用,直到构建新代码.我们至少要在登记注释中添加"等待构建"和/或发送电子邮件.
对于它的价值,我们就是这样做的.
大多数开发都是在主干中进行的,尽管可能破坏系统的实验性功能或事物往往会得到自己的分支.这很好用,因为这意味着每个开发人员都在其工作副本中始终拥有最新版本的所有内容.
它确实意味着保持干线处于模糊的工作状态非常重要,因为它完全可以完全破坏它.在实践中,这种情况不会经常发生,并且很少是一个重大问题.
对于生产版本,我们分支主干,停止添加新功能,并处理错误修正和测试分支(定期合并回主干),直到它准备好发布.此时我们最后合并到trunk中以确保一切都在那里,然后释放.
然后可以根据需要在发布分支上执行维护,并且可以轻松地将这些修复合并回主干.
我并不认为这是一个完美的系统(它仍然有一些漏洞 - 我不认为我们的发布管理是一个足够紧密的过程),但它运作良好.
为什么没人提这个呢？一个成功的Git分支模型.
这对我来说是最终的分支模型!
如果您的项目很小,请不要一直使用所有不同的分支(也许您可以跳过小功能的功能分支).但除此之外,它就是这样做的!
分支上的开发代码,在Trunk上标记的实时代码.
不需要"只提交完美代码"规则 - 开发人员错过的任何东西都应该在四个地方被提取:代码审查,分支测试,回归测试,最终QA测试.
这是一个更详细的逐步说明:
在分支机构进行所有开发,随时随地进行.
独立代码在完成所有开发后审核更改.
然后将分支传递给Testing.
分支测试完成后,将代码合并到Release Candidate分支中.
发布候选分支在每次合并后进行回归测试.
在所有dev分支合并后,在RC上执行最终QA和UA测试.
一旦QA和UAT通过,将发布分支合并到MAIN/TRUNK分支.
最后,在此时标记Trunk,并将该标记部署到Live.
京公网安备 11010802040832号 | 京ICP备19059560号-6 