为了账号安全,请及时绑定邮箱和手机立即绑定

如何维护开发代码和产品代码?

/ 猿问

如何维护开发代码和产品代码?

慕仰8121524 2019-07-19 10:16:30

如何维护开发代码和产品代码?

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

你们是如何维护开发代码和产品代码的?


查看完整描述

3 回答

?
ITMISS

现在,这个问题将在使用Git的上下文中看到,并且使用了10年的时间。分布式发展工作流(主要合作通过GitHub)展示了一般最佳做法:

  • master

    是否随时准备将分支部署到生产中:下一个版本,并将所选的一组特性分支合并到

    master.

  • dev

    (或整合分支,或‘

    next

    )是为下一个版本选择的特性分支一起测试的一个
  • maintenance

    (或

    hot-fix

    )分支是当前版本演化/bug修复的分支,

    与可能的合并回到dev和或master

那种工作流(不合并)devmaster,但是您只将功能分支合并到dev,如果被选中,则master,为了能够轻松地删除未为下一个版本做好准备的特性分支,将在Gitrepo本身中实现,并使用gitflow(一句话,图解).
见更多rocketraman/gitworkflow.

https://github.com/rocketraman/gitworkflow/raw/master/docs/images/topicgraduation.png

(资料来源:Git工作流:一种面向任务的入门器)

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


原答案(2008年10月,10多年前)

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

首先,你后备箱里的东西都是真的是为了下一个版本?您可能会发现,当前开发的一些函数是:

  • 太复杂了,还需要改进
  • 没有及时准备好
  • 有趣,但对于下一个版本来说不是

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

当涉及到生产代码时,您还需要管理您的贴片枝,同时铭记:

  • 实际上,第一组修补程序可能在第一次发布到生产之前就开始了(这意味着您知道您将带一些您无法及时修复的bug进入生产阶段,但是您可以在一个单独的分支中启动这些bug的工作)。
  • 其他修补程序分支机构将拥有从定义良好的生产标签开始的奢侈。

当涉及到dev分支时,您可以有一个主干,除非您需要进行其他的开发工作。并行比如:

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

现在,如果您的开发发布周期是非常连续的,那么您可以按照其他答案进行:一个主干和几个发布分支。这适用于小型项目,在这些项目中,所有的开发都肯定会进入下一个版本,并且可以被冻结,并作为发布分支的起点,在那里可以进行修补程序。这是名义上的过程,但一旦你有一个更复杂的项目.这还不够。


要回答Ville M.的评论:

  • 请记住,dev分支并不意味着“每个开发人员一个分支”(这将引发“合并疯狂”,因为每个开发人员都必须合并其他开发人员的工作以查看/获得他们的工作),而是每个开发工作都有一个开发分支。
  • 当需要将这些工作合并回主干(或您定义的任何其他“主”或发布分支)时,这是开发人员的工作,

    -我重复一遍,不是-SC经理(他不知道如何解决任何冲突的合并)。项目负责人可以监督合并,这意味着要确保它按时启动/完成。
  • 不管您选择谁来实际进行合并,最重要的是:
    • 若要在单元测试和/或程序集环境中部署/测试合并结果,请执行以下操作。
    • 定义标记

      以前

      合并的开始为了能够回到以前的状态,如果说合并证明自己太复杂或太长而无法解决。


查看完整回答
反对 回复 2019-07-19
?
12345678_0001

我们使用:

  • 专门开发部门

直到项目接近完成,或者我们正在创建一个里程碑版本(例如。产品演示,演示版),然后我们(定期)从我们当前的开发分支到:

  • 释放枝

发布分支中没有新特性。只有重要的bug在发布分支中被修复,修复这些bug的代码被重新集成到开发分支中。

有一个开发和一个稳定(发布)分支的两部分流程使我们的生活变得更容易了,我不相信我们可以通过引入更多的分支来改进它的任何部分。每个分支也有它自己的构建过程,这意味着每隔几分钟就会产生一个新的构建过程,所以在代码签入之后,我们在大约半小时内得到了所有构建版本和分支的新可执行文件。

有时,我们也有一个开发人员的分支,致力于一项新的、未经证实的技术,或者创建一个概念的证明。但通常情况下,只有当更改影响到代码基的许多部分时,才会这样做。这种情况平均每3-4个月发生一次,这样的分支通常在一两个月内重新整合(或报废)。

一般来说,我不喜欢每个开发人员都在自己的分支中工作,因为你“跳过去,直接搬到集成地狱”。我强烈反对。如果你有一个共同的代码库,你应该一起工作。这使得开发人员对他们的签入更加谨慎,每个程序员都知道哪些更改可能会破坏构建,因此在这种情况下测试更加严格。

关于入住早期的问题:

如果你只需要完美码要签入,实际上什么都不应该签入。没有任何代码是完美的,对于QA来验证和测试它,它需要在开发分支中,这样才能构建一个新的可执行文件。

对于我们来说,这意味着一旦一个特性完成并由开发人员进行测试,它就会被签入。如果有已知的(非致命的)错误,甚至可以签入,但在这种情况下,通常会通知受bug影响的人。不完整和工作中的代码也可以签入,但前提是它不会造成任何明显的负面影响,如崩溃或破坏现有的功能。

有时,不可避免的合并代码&数据检查会使程序在新代码生成之前无法使用。我们做的最起码是在签入注释中添加一个“等待构建”,并/或发送一封电子邮件。


查看完整回答
反对 回复 2019-07-19
?
蝴蝶不菲

不管它有什么价值,我们就是这样做的。

大多数开发都是在主干中执行的,尽管实验特性或可能严重破坏系统的东西往往会得到自己的分支。这很好的工作,因为它意味着每个开发人员总是有最新版本的一切在他们的工作副本。

这确实意味着保持躯干在模糊的工作状态是很重要的,因为它完全有可能完全破坏它。在实践中,这种情况并不经常发生,也很少是一个重大的问题。

对于生产版,我们将分支主干,停止添加新特性,并致力于修复和测试分支(定期合并回主干),直到它准备好发布。在这一点上,我们进行最后的合并到主干,以确保所有的东西在那里,然后释放。

然后,可以在发布分支上执行必要的维护,并且这些修复可以很容易地合并回主干中。

我并不认为这是一个完美的系统(而且它仍然有一些漏洞-我认为我们的发布管理还不够严密),但它的工作足够好。


查看完整回答
反对 回复 2019-07-19

添加回答

回复

举报

0/150
提交
取消
意见反馈 邀请有奖 帮助中心 APP下载
官方微信