持续集成的重大修订
内容提要
这篇文章探讨了持续集成中处理分支的不同策略，介绍了分支的目的、正确集成的含义和高频集成的价值。它从更广泛的角度探讨了持续集成与其他分支模式的关系。
延伸解读
“半集成”不是持续集成
文章指出，许多团队虽然频繁从主干拉取变更到特性分支并构建测试，却未将工作推回主干，这被称为“半集成”。这种做法无法防止分支分叉和冲突积累，因为其他成员看不到你的代码，无法提前发现冲突。真正的持续集成要求代码在几小时内推入主干，确保所有变更共存于单一分支，从而快速暴露并解决冲突。
构建失败必须立即修复
持续集成依赖主干始终健康。一旦集成构建失败，团队需立即优先修复，通常最快的方式是回滚最新提交，让系统回到已知良好状态，其他人可继续工作。文章强调，修复构建是最高优先级任务，但通常只需少数人处理。若团队频繁出现红色构建，应考虑采用预测试提交（Pending Head）等机制，但更应通过改进实践来避免。
用部署流水线平衡速度与反馈
提交构建必须快速（约十分钟），以提供即时反馈。为此可将测试分阶段：提交构建运行快速单元测试，用测试替身替代慢速服务；后续阶段再运行涉及真实数据库的端到端测试。若后续阶段发现缺陷，应尽量在提交构建中补充能捕获该缺陷的测试，从而持续强化快速反馈的质量。并行与云环境也能进一步缩短构建时间。
隐藏未完成代码的常用技术
持续集成要求尽早集成，但功能可能未完成。文章介绍了多种管理潜在代码的技术：拱心石接口（最后添加用户入口）、暗发布（在生产中测试但不暴露给用户）、特性开关（通过配置启用或禁用代码）、抽象分支（内部接口路由新旧逻辑）以及并行变更（将重命名等操作拆分为可逆步骤）。这些技术帮助团队在保持主干可发布的同时集成未完成的工作。
Q&A
持续集成（CI）的核心做法是什么？
持续集成的核心是团队每位成员至少每天一次将代码集成到受控的源代码仓库的主干中，并且每次提交都应触发构建，以确保代码健康。
为什么持续集成强调高频集成？
高频集成能减少集成过程中的复杂性和不确定性。集成越频繁，冲突发现得越早，需要排查的地方越少，修复也越容易；长时间不集成会导致冲突难以解决。
持续集成中构建应该具备哪些特性？
构建应自动化，以减少人为错误；构建应具备自测试能力，在集成前发现潜在问题；构建应保持快速，以便快速反馈和修复问题。
如何处理未完成的功能代码而不影响生产？
可以使用特性标志（Feature Flags）和暗发布（Dark Launching）等技术管理未完成的代码。特性标志在运行时控制代码是否执行，暗发布则允许在生产中测试但不对用户可见。
为什么测试环境要尽可能模拟生产环境？
测试环境与生产环境的差异会带来风险，可能导致测试中未发现的问题在生产中出现。因此应尽可能克隆生产环境进行测试，以减少环境差异带来的风险。
持续集成对团队沟通有什么要求？
持续集成强调团队之间的沟通，确保每个人都能看到系统状态和变更。集成主要是关于沟通，频繁集成让开发者快速了解彼此的修改，及时发现冲突。
