Enable javascript in your browser for better experience. Need to know to enable it? Go here.
已发布 : May 19, 2020
不在本期内容中
这一条目不在当前版本的技术雷达中。如果它出现在最近几期中,那么它很有可能仍然具有相关参考价值。如果这一条目出现在更早的雷达中,那么它很有可能已经不再具有相关性,我们的评估将不再适用于当下。很遗憾我们没有足够的带宽来持续评估以往的雷达内容。 了解更多
May 2020
评估 ? 在了解它将对你的企业产生什么影响的前提下值得探索

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

Radar

下载第25期技术雷达

English | Español | Português | 中文

Radar

获取最新技术洞见

 

立即订阅

查看存档并阅读往期内容