持续集成的演变

在本周的《Dev Interrupted》节目中，联合主持人Conor Bronsdon和LinearB的开发者关系总监Ben Lloyd Pearson详细介绍了Continuous Merge的发展及其背后的工具gitStream。DevCycle的工程副总裁Nik LeBlanc也加入了对话。

Nik 分享了他的团队使用 gitStream 简化代码审查的方法，并为希望在自己团队中实施该工具的人提供了实用建议。他还探讨了拆分和重组工程团队这一颇具争议的做法，DevCycle 采用这一策略取得了很好的效果。Nik发现这种做法有助于平衡团队，管理多样化的知识库，并降低组织的风险。

最后，Conor和Ben通过展望未来结束对话，重点关注gitStream的潜力和方向。

“人们非常关注PR，以及PR的持续时间。讨论他们愿意让PR在接受审查前停留多久，已经成为团队工作协议的重要组成部分。”

集锦

(2:50) 分拆和重组开发团队

(9:20）DevCycle 如何利用工具实现积极变革

(14:50）团队为何 "更加关注 "PR？

(17:00) Nik 对 DORA 和航运的看法

(21:20) 要关注的主题和社交活动

(23:35) Ben 和 Conor 分析他们与 Nik 的对话

(27:30) 将预计审核时间应用于 PR

(31:30) gitStream 集成

(32:30）gitStream 的未来

剧集节选

Conor Bronsdon：你们是如何利用工具来实现团队结构和组成的这些变化的？

Nik LeBlanc：是的。这个问题问得好。我们用Jira做了一些疯狂的事情，我知道每个人都讨厌Jira。我是它的粉丝，我已经爱上了它。基本上，每个团队都有一个板块，他们称之为 "聚焦板块"，在任何时候，一个团队都在为一个特定的史诗而工作，这个史诗就是一个功能。在这里，史诗等同于功能的迭代。他们要做的是，基本上在他们的重点板上，他们可以看到与史诗相关的所有票据，或者他们只能看到与史诗相关的票据，他们还能看到分配给他们团队的与史诗无关的任何特定 bug。我们还有公会，这也是另一个历来很难做好的事情。公会既可以成为讨论平台或技术某一特定部分的机会，也可以成为志同道合的人专注于堆栈某一特定部分的机会，建立起不以产品为中心，而以技术债务或调查为中心的工作积压。他们可以尝试将这些工作纳入自己团队的路线图。因此，基本上我们通过 Jira 建立了团队，任何产品工作或项目工作都会通过 Jira 交给一个团队。然后，我们有与公会票据相关联的标签，这些标签会自动分配给团队，或者也会出现在团队的板块上。

因此，我们对这些板块进行了大量试验，研究如何更好地体现团队手头的工作，以及如何确定团队希望优先处理哪些 Guild 票务，哪些票务不需要处理。

Conor Bronsdon:我的理解是，你们正在利用持续合并工具来实现更频繁的部署。你能分享一下这对你们开发的团队结构有什么影响吗？

Nik LeBlanc：是的。有一件事我们还没有用持续合并或 gitStream 完成，但我很想知道如何根据团队分配 PR。我知道你们的文档中有很多例子关于如何根据对正在变化的代码的熟悉程度或对正在变化的代码的不熟悉程度来分配它们，这是我们在不久的将来会着重学习的东西。

但目前我们使用它的主要目的是估算审核 PR 所需的时间，并在 PR 上贴上这些标签。自动合并任何依赖机器人的 PR，或者任何只涉及测试或文档的 PR。我认为这只是你们文档中的一个典型例子，对我们来说效果很好。

我们的很多 DORA 前置时间指标都受到了依赖机器人PR的影响，这些PR被闲置在那里，无人问津。因此，我们不得不对它们采取行动。那么，我们该如何处理它们呢？我们真的要合并它们吗？还是干脆不合并？现在，我们终于不用再纠结这个问题了，只要通过测试就可以合并，这真是太棒了。

这就是目前 gitStream 的主要功能，但这也是我们采用它的主要原因，那就是 DORA 指标。我们发现我们的流水线中存在堵塞，我们想把它们疏通，现在我想用它来让人们有机会探索他们尚未探索过的代码领域。

关注微信公众号【赛希咨询】，了解更多精彩内容。