菜单
技术

预检构建

May 2020
评估?

尽管相比 Gitflow 来说,我们强烈推荐 CI,但我们知道直接向主干提交然后在 master 分支上跑 CI,在团队过大的时候是低效的。构建会变慢或不稳定,也可能团队会缺乏在本地运行完整测试集的纪律。在这种情况下,一次红色的构建可以阻塞多名或多对开发者的工作。许多团队通常依赖功能分支来绕过这些问题,而不是解决潜在的根本原因——构建缓慢、不能本地运行测试或迫使许多人在同一位置工作的单体架构。我们不鼓励功能分支,因为它可能需要巨大的努力来解决合并冲突,并且还可能在解决冲突的过程中拉长了反馈周期和引入缺陷。取而代之的是,我们提议使用 预检构建 作为替代方案:它是基于 Pull Request 的构建,针对只在流水线运行期间存在的为每个commit建立的微型分支。为了自动化这一工作流,我们已经见到了类似 Bors 这样的机器人程序,它将合并 master 分支和删除迷你分支(当构建成功时)的工作自动化。我们正在评估这个流程,你也应该试试看,但请不要用它去解决错误的问题,因为这样的话可能会带来分支滥用,导致弊大于利。