持续的构建和敏捷vs提交经常[关闭]

有什么比什么事情出错的禁忌更不敏捷呢?我会争辩说,禁忌是让构建中断,而不是完全中断构建。偶尔的建筑破损是可以的。这正是您运行连续构建和测试的原因。CI构建/测试确定构建何时被破坏,理想情况下是谁破坏了它。这样可以确保快速修复。如果偶尔发生这种情况,你就没事了。如果一天发生20次,团队可能会遇到麻烦。

禁忌是干涉别人完成工作。当你破坏构建时,他们会收到一封电子邮件,说“我们的源分支被破坏了”。他们将无法集成其他人的更改,或他们的更改与主线,直到他们得到全部清楚的电子邮件。

在这种持续集成的环境中工作的真正挑战是: 1)保持团队规模较小。一般来说,在团队中有大约25个开发人员之后,我们开始发现问题。事情开始变得脆弱。使用团队级别的分支、组件或带有流的多级CI可以帮助较大的团队进入较小的团队。

2)选择小的工作单位。一般来说,定期检查改进和不破坏一切之间不应该有冲突。提交应该在进行小的工作更改时完成。新特性可能还没有向用户公开,但是如果一致的API更改没有破坏测试,请签入。

3)快速、准确的构建。有很多比赛条件,当速度加快时,球队往往会赢得更多的比赛。另外,可复制的构建将确保开发人员在自己的机器上完成构建(因为它速度很快,所以她有时间完成这个构建),从而合理地准确地预测提交时的成功。

在大多数源代码管理系统中,分支/标记可以解决这个问题。

它们允许您标记或只是“分支”(双关语的意思是)代码的段/修订,并将其作为“稳定发布”。然后,您可以提交对主干、或“补丁”分支或其他方法的更改。

这两个概念协同工作。

实际上,一个常见的敏捷哲学(我一直很满意)是这样的:“如果你在回家之前不能承诺,那就恢复原状。”

起初这听起来很残酷,所以我通常先从本地复制源代码树或将其分支,然后再返回到我开始的位置。第二天我重新开始工作。它通常运行得很快,我比前一天所做的有所改进,而且我很少查看副本(有时我会撤回一些我已经“完成”的课程,并确信并重新整合它们)。

我几乎没有必要不登记就去几个小时以上。我尝试使用重构(它们总是很短且无害的,或者它们不是重构),并且我添加代码的方式使事情不会中断。这可能涉及到添加测试代码(一个新的方法或对象),并在链接其余代码之前将其签入。

总的来说,单元测试应该始终运行。我倾向于每分钟运行几次测试,很少每十分钟运行一次。

采取这些小步骤可能需要更长的时间,但您将避免那些3-4天的代码重写会话,在这些会话中,您无法运行任何测试或签入,这些操作可能很残酷,而且浪费大量时间!

我再补充一个答案,因为在我看来,一些最重要的问题还没有提到。

我对版本控制的理解 经常承诺更好吗? 因为你有历史和 能够返回到以前的更改 以细粒度的方式。

我完全同意这一点。

我对敏捷的理解 持续建设就是为了 给开发者施加压力 始终具有工作代码。

它是 不 为了给开发人员带来压力,我宁愿将持续集成描述为一种友好的 安全网 这有助于您在提交问题时及时发现问题,而解决问题通常很容易。(检查马丁·福勒的 seminal article 为了更多的CI利益。) 是 重要的是要始终有工作代码,这就是版本控制分支出现的地方,如 silky pointed out . 但与他描述的传统场景不同(福勒谈到的是:“每个人每天都致力于主线建设”),我建议相反:让你的主干线保持稳定,最好始终保持可释放的形状,并在临时工作分支中进行所有主要的开发。

我已经接通了稳定的后备箱,所以 here 和 here ;请参阅这些文章,了解此模型的一些理由和经验。同时,我也热情推荐这篇影响我思考的文章: Version Control for Multiple Agile Teams 亨里克·奈伯格。

在开发分支中破坏构建远非禁忌,尽管您仍然应该尝试保持所有编译和所有测试都通过。打破 大旅行箱 在这种情况下,构建会更为严重,但我仍然不认为这是一种禁忌,这些事情经常发生,而不是找人来负责,团队只需解决它就变得极其重要(并且很高兴发现了问题) 现在 而不是很晚,也许是客户)。

使用git可以方便地进行分支、合并和重新平衡。

Silky是点对点,分支/标记解决了这一问题(此功能的SVN插头)。

我经常是commit的忠实粉丝,我个人发现它更容易防止破坏构建,因为我每次都在单元测试少量的代码。

TDD让你两个都有

解决这个明显矛盾的一个方法是 Test Driven Design (TDD)。实践很好,经常提交代码很容易 和 具有很少被非工作代码破坏的连续构建。

首先从存储库中获取最新的代码并运行所有测试。(如果他们没有全部通过,就破坏最后一个提交的人。)为一小部分功能编写一个测试。( 之前 您已经实现了功能),然后实现了功能,并再次运行所有测试。从版本控制系统更新您的代码,以防在您工作时发生任何更改,再次运行所有测试,如果它们都通过,那么您可以立即提交。这就是敏捷概念的“红-绿”重构。之后,执行任何需要的重构,并再次运行所有测试。如果你还是绿色的,你可以在那个时候再次承诺。

大多数敏捷团队都有 Continuous Integration 按常规计划运行的服务器(通常每小时或更长时间运行),并有一个大的可见指示器(如红绿灯),显示最近的生成是否已通过、失败或正在进行中。

如果必须,请使用本地版本控制数据库

如果你绝对不能摆脱“大的代码更改”,那么使用你自己的本地版本控制库,使用类似 git 正如戈登·波特所建议的,当你完成了你的改变后,你要承诺。即使您的团队使用其他版本控制产品,也可以这样做。

对于可能破坏依赖代码片段的重大或大的更改,分支是合适的。在您希望集成这个变更并检入主干或您要将其提升到的任何集成分支的时候,处理好这些破损并让测试全部工作是必要的。
我认为这两件事不应该互相矛盾。使用分支或分布式源代码管理将使这更容易管理。

在合并过程中,您必须检查什么样的历史是有意义的。假设您有一个使用许多可加载模块的程序,可以是内核。网络服务器,随便什么。

在编写一个模块时,您需要提交200个,当您与主项目合并时,您可能只需要一个(尽管很大)补丁,可能需要两个:

• 介绍FOO模块
• 更新makefiles以生成foo

这就是为什么Git在数字视频通信领域占据主导地位的原因之一。

您对提交频率的选择实际上与您想要使用的软件开发方法无关。您可以提交200个经过良好测试的修订,或者一个,只要人们提取您所推的内容,而不会吸收由您自己引起的有害修订或代码回归(当然,除非您的代码暴露了他们的问题)。

我(个人)喜欢做出许多小小的承诺,原因与你所做的相同。事实上,如果每个人都在一个中心分支上工作,这通常是理想的。但是,如果您在某个子系统上工作了6个月,我真的希望您给我发送一些大补丁,而不是继承您的整个历史。你在自己的工作报告中总是有自己的历史,这可能只是你感兴趣的一点:)

如果较大的代码更改位于单独的分支中,则不一定会破坏构建。通过将一个分支放到自身上,在完成更改之前,这些更改都不会出现在代码中,然后整个事情就可以合并回主干或主代码行中。关键是,虽然有一个持续的构建正在发生,但不一定包括那些不需要的东西 "done-done."

在我看来,Git解决了这个问题。保留一个本地存储库并尽早提交,经常提交,然后当代码到达一个未中断的里程碑时,将其推送到主共享存储库。如果整个团队都使用Git,那么当其他人进行更改时,所有的存储库历史记录都可以保存在他们的存储库中。所有这些都不必破坏建筑。

通过重新平衡,您甚至不必在推出里程碑时公开整个本地提交历史记录。