船/展示/询问

现代分支策略

Ship/Show/Ask是一种分支策略,它结合了Pull Requests的特性和保持交付更改的能力。变更分为Ship(不经评审就合并到主线中),Show(打开一个pull请求进行评审,但是立即合并到主线中),或者Ask(在合并之前打开一个pull请求进行讨论)。

2021年9月08


Rouan Wilsenach的照片

Rouan是一名软件工程师和技术领导者,帮助建立优秀的团队和高质量的软件。他曾为金融服务、教育、休闲和能源行业的公司工作过(包括Thoughtworks的顾问)。他关心的是保持事情简单,建立包容性的团队,并把他学到的东西写下来。


如何与拉取请求进行持续集成?

把请求已被许多软件团队广泛采用。有些人喜欢它们,而有些人则渴望它们的日子持续集成-你从来没有创建过分支,你的团队总是把他们的变化放在一起。

在某些方面,Pull Requests是游戏规则的改变者。代码托管工具提供了极好的代码审查功能。有很多SaaS供应商提供的服务可以在你的pull请求上运行——从运行你的测试和检查代码质量到部署成熟的预览环境。

但是采用Pull Requests作为贡献代码的主要方式也产生了问题。在进行持续集成时,我们已经失去了一些“准备就绪”的心态。正在开发的特性由于延迟集成而被搁置一旁,因此我们陷入了低频集成的缺陷持续集成试图解决的问题。

有时候Pull Requests呆坐着,变得乏味,或者我们在等待审核时不确定要做什么。有时他们会变得浮肿,因为我们会想“好吧,我还是趁我在这里的时候做这个吧。”

我们也厌倦了我们必须审查的拉请求的数量,所以我们不再讨论代码了。我们不再关注,我们只是点击"批准"或者说"我觉得不错"

介绍船/表演/提问

我在我的团队中使用了一种软件分支方法。效果很好,所以我想和大家分享一下。

每次你做出改变时,你会从三个选项中选择一个:发布、展示或请求。

图1:更改直接在主线上进行

这感觉最像持续集成。你想做些改变,就直接在你的主线.当您这样做时,您不会等待任何人将您的更改带到生产环境中。你不是在要求代码评审。没有什么大惊小怪的——只需进行更改,使用所有常用的持续集成技术使其安全。

作品大当:

  • 我使用已建立的模式添加了一个功能
  • 我修复了一个不起眼的错误
  • 我更新了文档
  • 我根据你的反馈改进了我的代码

显示

图2:打开PR去获取反馈,但是直接将其合并

这就是我们采用持续集成思维的地方,并且仍然利用Pull Requests给我们带来的好处。您在一个分支上进行更改,打开一个Pull Request,然后无需等待任何人就可以合并它。您可能希望等待您的自动检查(测试、代码覆盖、预览环境等),但您不会等待任何人的反馈来继续执行更改。

这样做,你就能迅速地做出改变,同时还能为反馈和对话创造空间。你的团队应该收到你的pull请求的通知,然后他们可以审查你所做的事情。他们可以为您的方法或代码提供反馈。他们会问你问题。他们可以从你的所作所为中学习。

作品大当:

  • 我希望您能对如何改进这段代码给出反馈
  • 看看我使用的这个新方法或模式
  • 我重构了X,现在它是这样的
  • 多么有趣的虫子啊!看看我是怎么解决的。

图3:打开PR查看反馈,并在合并前等待

我们暂停。我们在一个分支上进行更改,我们打开一个Pull Request,然后在合并之前等待反馈。也许我们不确定我们采取了正确的方法。也许有一些代码我们不是很满意,但我们不确定如何改进它。也许你做了一个实验,想看看人们是怎么想的。

现代代码审查工具为这种对话提供了一个很好的空间,你甚至可以让整个团队一起查看并讨论一个Pull Request。

作品大当:

  • 这工作吗?
  • 我们对这种新方法感觉如何?
  • 我需要你的帮助,好吗
  • 我今天就做完了,明天就合并

规则

  • 代码审查,或“批准”,不应该是合并Pull Request的要求。
  • 人们可以合并他们自己的Pull Requests。这样,他们就可以控制自己的改变是“展示”还是“要求”,他们还可以决定什么时候开始。
  • 我们必须使用所有伟大的持续集成持续交付帮助保持主线可发布的技术。取功能切换作为一个例子。
  • 我们的分支不应该活得太久,我们应该经常将它们重新建立在主线上。

谈话

虽然Pull Requests是讨论更改的一种有用的方式,但它们也有一些陷阱。最迷人的反模式就是它们可以取代其他的对话方式。

分支的一个常见问题是,人们没有讨论就决定了一种方法。当一个Pull Request被打开的时候,时间已经被投入到一个可能不是最优的解决方案上了。评审人员会受到所选解决方案的影响,发现很难提出替代方法。变更集越大,分支存活时间越长,这个问题就变得越严重。在你开始之前和你的团队谈谈,这样你就可以有更好的想法,避免返工。

记住,拉请求并不是展示或要求的唯一方式。接个电话或走到某人的办公桌前。尽早并经常展示你的工作成果。尽早、经常地寻求帮助和反馈。一起完成任务。

不打开Pull Request也不是避免讨论代码的理由。重要的是,你的团队仍然有一个良好的反馈文化,并相互交流你的想法和学习。

平衡

现在有三个选择,我应该经常选择哪一个?

视情况而定。我认为每支球队在任何时候都有自己的平衡。

当您在一个已建立的模式中交付特性时,您将进行更多的“交付”。当你对团队有了高度的信任,并且团队成员拥有相同的质量标准时,你也会做更多的“发布”工作。

但如果你们还在互相了解,或者你们都在做一些新的事情,那么就更需要对话,所以你们会做更多的“展示”和“要求”。一个初级工程师可能经常“展示”和“要求”。高级工程师可能会“发布”很多东西,但偶尔“展示”一种每个人都应该尝试的新技术或重构。188足球比分直播

有些团队没有太多的灵活性。某些行业受到严格监管,每一次变更都需要经过批准或审查。有很多种方法来实现这个——不管你有没有分支——我在这里就不讲了。

我的团队应该采用这种方法吗?

你已经有了。

想想你的团队是如何运作的,你会注意到你正在平衡Ship/Show/Ask。我见过的大多数团队都分为两种类型:“主要发布”或“主要要求”。

如果你大部分时间

如果你很少进行分支,所有提交都直接提交到主线,那么你就是“主要交付”。如果你是这样的人,考虑一下做一些“展示”是否会对你有帮助。

Pull Request模型之所以如此流行,很大程度上是因为它们支持远程优先和异步团队。明确地向他人“展示”你工作中有趣的部分,可以帮助他们学习并感觉融入到对话中,尤其是当他们远程工作或不同时间工作时。

我还发现(尤其是在那些说话不够的团队中[1]),总是致力于主线可能意味着有问题的更改只有在几周后才会被发现。到了这个时候,就很难进行有用的对话了,因为细节已经模糊了。鼓励团队成员使用“Show”方法意味着您可以在执行过程中进行更多关于代码的对话。

如果你经常问

如果你的团队为大多数更改打开了Pull Requests,你就是“主要要求”。虽然Pull Requests对于质量和反馈来说是一个有用的工具,但是它们有一个可伸缩的问题。等待批准不可避免的是,它需要时间。如果等待反馈的修改太多,要么反馈的质量就会下降,要么进度就会减慢。多尝试“展示”,这样你就可以得到两个世界的好处。

你依赖很多“请求”的原因可能是你有信任问题。“所有变更都必须被批准”或“每个pull请求都需要2个评审员”是常见的策略,但它们显示出对开发团队缺乏信任。

这是有问题的,因为批准步骤只是一个创可贴——它不会解决你潜在的信任问题。多做一些“展示”,这样你就可以在开发过程中释放一些压力。然后将您的努力集中在建立信任的活动上,例如培训、团队讨论或集成编程。每一次开发人员“展示”而不是“要求”,都是他们与团队建立信任的机会。

你依赖大量“请求”的另一个原因可能是,你没有一个安全的方式将更改放在主线上。在这种情况下,您需要学习和实现一些技术来保持主线的可发布性。与此同时,更多的“展示”可能是一种减少对生产进行安全更改的障碍的方法。减少的障碍对团队成员也会起到激励作用——如果你能找到一种让你的改变安全的方法,它就能更快地生效。

结论

那么什么是Ship/Show/Ask?从根本上讲,这是两件事:

首先,这是一个帮助你两全其美的技巧——合并你自己的pull请求而不等待反馈,然后在反馈来的时候注意反馈。

第二,以一种更具包容性的、动态的方式来看待分支策略。Ship/Show/Ask提醒我们,每个团队的方法都位于“总是Ship”和“总是Ask”之间。它鼓励我们独立思考每一个变化,并问自己——我应该发布、展示还是提问?


确认

感谢那些对早期草稿提供详细反馈的人:Martin Fowler, Brian Guthrie, Federico Blancato, Ste188bet足球充值phen Cresswell和Paul Hammant。

还要感谢Matthew Harward、Kief Morris、Giuseppe Pereira、Marcos Vinícius da Silva、Birgitta Böckeler、Prashanth R、Premanand Chandrasekaran、Joao Paulo Moraes和Mark Taylor,他们在ThoughtWorks内部邮件列表上讨论了这篇文章的草稿。

脚注

1:结对编程是否有一种有效的技术来鼓励团队中的持续沟通

重大修改

2021年9月08:发表