Trunk-based development（TBD）是一种分支管理策略，所有开发者频繁地——至少每天一次——直接将代码集成到主分支（trunk/main），使用最长24小时的短期分支，从而消除长期分支和复杂的合并。
我们的立场明确且不可协商：没有自动化视觉测试，你不能实践 trunk-based development。就像以200公里时速开车不系安全带。技术上可行。根本上不负责。
Trunk-based development 是一种强大的实践。它加速交付、减少合并冲突、强制持续集成纪律。采用它的团队交付更快、合并痛苦更少、工作流更顺畅。
但这种强大有代价：每个 commit 快速到达主分支。每个变更在数小时内对整个团队可见。每个回归——包括视觉回归——以部署速度传播。
在 GitFlow 模型中，您有数天或数周在视觉问题到达 main 之前检测它。在 trunk-based 中，您只有数小时。有时只有几分钟。传统安全网——长时间手动评审、专用测试阶段、QA 的视觉验证——不再存在。您需要用与集成节奏一样快的东西来替代它。
那个东西就是自动化视觉测试。
为什么 Trunk-Based 放大视觉风险
Trunk-based development 不只是另一种分支策略。它是一种建立在简单原则上的激进哲学：主分支始终可部署。始终。每个到达 main 的 commit 必须让系统处于功能正确状态。
这个原则对速度来说很美妙。对视觉回归来说则很可怕。
提交频率倍增风险点
在 trunk-based development 中，一个五人团队每天轻松在 main 上产生15到25个 commit。每个 commit 都是一个视觉风险点。这里一个 CSS 变更，那里一个依赖更新，再远一点一个共享组件重构。
在长分支模型中，这些变更在功能分支上累积并在合并时被集体评审。团队可以分配时间进行完整的视觉验证。在 trunk-based 中，每个变更单独到达且必须单独验证。总量相同，但验证粒度根本不同。
而这正是自动化视觉测试变得不可或缺之处。没有人能在每次日常 commit 后视觉验证20个页面5种分辨率。自动化可以。
短分支限制评审时间
在 trunk-based 中，分支存活时间为几小时到最多24小时。这是一个有意为之的约束，防止长分支漂移。但这个约束也压缩了可用的评审时间。
当开发者在上午开启一个 merge request 而它必须在当天结束前合并时，代码评审时间有限。评审自然聚焦于业务逻辑、代码质量和单元测试。视觉验证是第一个被跳过的——它被认为不太关键、更主观、更耗时。
但当视觉回归到达生产环境时，它们既不主观也不微不足道。自动化视觉测试通过在代码评审期间并行运行来解决此问题，无需开发者或评审者额外时间。
副作用在 diff 中不可见
trunk-based 中视觉回归最阴险的方面是，它们通常由不直接触及界面的变更引起。主题文件中的一个变量变更将效果传播到数十个组件。CSS 库更新修改了默认值。共享组件重构影响了使用它的每个页面。
在 merge request 的 diff 中，一切看起来干净。变更是局部的、受控的、有良好单元测试的。但在视觉上，它具有代码中不可见的连带影响。视觉测试是唯一捕获这些副作用的机制——因为它看的不是代码，而是渲染结果。
视觉测试作为主分支门禁
在 trunk-based development 中，主分支是神圣的。它必须始终处于可部署状态。为保证这一状态，团队设置门禁——commit 被接受到 main 之前必须通过的自动化检查。
这些门禁通常包括单元测试、集成测试、静态代码分析，有时包括端到端测试。视觉测试必须是其中之一。
非阻塞测试在 Trunk-Based 中毫无用处
有些团队将视觉测试集成为"信息性"检查：测试运行、结果展示，但不阻塞合并。在 trunk-based development 中，这是个错误。
trunk-based 的速度意味着信息性结果会被忽视。开发者想在当天结束前合并他们的短分支。他们看到单元测试通过。他们看到一个视觉警告。他们还是合并了。"我回头再看。"
在 trunk-based 中，没有"回头"。下一个 commit 在一小时内到达。视觉回归被埋在十个新变更之下。直到生产环境才被发现——当用户报告订单表单在手机上不可读时。
如果检测到未批准的回归，视觉测试必须阻塞合并。 这是保证主分支保持视觉完整的唯一方式。
三步工作流
trunk-based development 中的视觉测试工作流故意保持简单，因为任何复杂的东西都会被绕过。
步骤1：开发者推送到他们的短分支。 CI/CD 管道触发。视觉测试自动运行，将分支截图与 main 的参照进行比较。
步骤2：结果出现在 merge request 中。 如果没有检测到视觉差异，测试通过。合并被授权（以其他门禁为条件）。如果检测到差异，merge request 被阻塞直到解决。
步骤3：开发者处理差异。 如果视觉变更是有意的（新组件、计划中的重新设计），他们更新参照。如果是回归，他们修复。无论哪种方式，决策都是明确的且可追溯的。
这个工作流每个 merge request 只需几分钟。视觉报告是可视化的（双关）——无需阅读日志，只需查看并排图像并做决定。
Trunk-Based 特有的风险场景
Trunk-based development 创造了在长分支模型中不存在（或较少出现）的视觉风险场景。
静默视觉冲突
两个开发者分别开发两个不同功能。Alice 修改了 Header 组件以添加通知徽章。Bob 修改了 Footer 组件以添加法律链接。每个变更单独看都是视觉正确的。
但 Alice 的变更轻微改变了 Header 的 z-index。而 Bob 的变更给 Footer 增加了额外高度。组合结果在小屏幕上：主内容被放大的 Header 和 Footer 挤压，部分文字不可见。
代码评审检测不到，因为每个 diff 都是干净的。单元测试检测不到，因为每个组件单独工作正常。视觉测试能立即检测到，因为它捕获的是整个页面渲染后的样子。
不可见的依赖更新
您更新了一个 CSS 库或组件框架。更新日志没有提到视觉变更（"breaking change: none"）。单元和集成测试通过。一切似乎正常。
但新版本更改了某些属性的默认值。间距略有不同。一个 border-radius 变了。添加了一个过渡效果。单独看，这些变更都很微小。合在一起，它们改变了应用的外观。
在 trunk-based 中，这个更新快速到达 main。如果没有视觉测试，微妙的变化就成了新常态。没人注意到它们，直到某天有人把三个月前的截图拿来比较，纳闷应用为什么看起来不一样。
配置错误的 Feature Flag
Feature flag 通常与 trunk-based development 配合使用，用于交付未激活的代码。开发者在禁用的 feature flag 后面添加一个新组件。代码在 main 上，但组件不可见。一切正常。
除非该组件的 CSS 没有被正确隔离。除非隐藏组件的样式影响了相邻元素。除非生产环境中 flag 的意外激活产生了一个从未有人见过的视觉效果——因为它从未被视觉测试过。
视觉测试必须覆盖 feature flag 的主要状态——至少包括 flag 启用和不启用的行为。这是保证交付到 main 的代码在所有计划状态下视觉正确的唯一方式。
Trunk-Based 的最优配置
要使视觉测试在 trunk-based development 中有效，其配置必须反映此策略的约束。
执行速度
在 trunk-based 中，您不能等30分钟才拿到视觉测试结果。管道必须快速以避免成为推动开发者绕过门禁的瓶颈。
策略是在每个 merge request 上测试关键页面（5-10个页面，2-3种分辨率），在合并后在 main 上运行完整测试套件。第一个门禁很快（几分钟）。第二个是穷尽的但对开发者不阻塞。
共享引用管理
在 trunk-based 中，视觉参照与主分支绑定。当开发者在他们的短分支上更新参照时，此更新必须干净地合并到 main。
最佳实践是将视觉参照存储在集中系统（不在 Git 仓库中）并相对于 main 的状态进行版本管理。这样，两个同时视觉修改同一页面的开发者不会在参照上产生冲突。
适配的容差阈值
Trunk-based development 产生频繁的、细粒度的变更。视觉测试容差阈值必须经过校准，以避免误报而不掩盖真实回归。
过严的阈值（容许0%差异）会在机器间的亚像素渲染差异上产生误报。过宽的阈值（容许5%差异）会放过真实回归。0.1%到0.5%的阈值通常是良好的起点，可根据您的上下文调整。
在 Trunk-Based 中不做视觉测试的代价
对于认为视觉测试在 trunk-based development 中是可选奢侈品的怀疑者，让我们谈谈缺失它的代价。
晚期发现的代价。 在开发阶段检测到的视觉回归修复需要5分钟。在预发布环境检测到，需要一小时（上下文切换、调查、修复、重新部署）。在生产环境检测到，至少需要半天（告警、调查、热修复、沟通、重新部署）。
信任侵蚀的代价。 在 trunk-based 中，主分支是真相源。如果它在视觉上不稳定，开发者失去信心。他们犹豫合并。他们推迟集成。trunk-based 悄然变成更长的分支，您失去了该实践的好处。
品牌形象的代价。 每个到达生产环境的视觉回归都对用户可见。一个错位的按钮、被截断的文字、手机上破损的页面——这些都是疏忽的信号。在 B2B 中，信任是商业关系的基础，每个视觉缺陷都在消耗信誉。
从哪里开始
您正在实践 trunk-based development（或正在考虑采用它）并希望在视觉上保护您的主分支。以下是行动计划。
第1天：识别关键页面。 列出浏览量最大或对业务最重要的5到10个页面。首页、产品页、转化漏斗、仪表盘——用户最常看到且破损影响最大的页面。
第2天：配置无代码视觉测试工具。 使用 Delta-QA，几次点击即可创建视觉参照。无需脚本，无需复杂配置。定义 URL 和分辨率，工具捕获您的参照。
第3天：集成到您的管道。 将视觉测试作为门禁添加到您的 CI/CD 管道。结果出现在 merge request 中。未批准的回归阻塞合并。
第1周：校准阈值。 观察结果。调整容差阈值。遮蔽动态内容。细化测试页面列表。
第2周及以后：扩展覆盖范围。 逐步添加次要页面、额外分辨率、界面状态（已登录/未登录、空购物车/满购物车等）。
Trunk-based development 是一种精英实践。它需要纪律、工具和对管道的信心。自动化视觉测试是必备工具的一部分。没有它，您的主分支就是一条没有护栏的高速公路。
常见问题
视觉测试会减慢 trunk-based 的节奏吗？
不会，只要配置得当。针对关键页面的视觉测试在2到5分钟内运行，与管道中的其他测试并行。不是视觉测试在拖慢速度——是未检测到的视觉缺陷在拖慢速度，当它们需要紧急热修复时。
多人同时修改界面时如何管理引用更新？
这是 trunk-based 特有的挑战之一。最佳实践是在独立于 Git 仓库的版本化系统中集中管理视觉参照。当开发者更新参照时，它立即对后续 merge request 可用。现代工具以原子方式处理这些更新以避免冲突。
小团队不做视觉测试能用 trunk-based 吗？
小团队常觉得他们能控制风险，因为"每个人都了解代码"。这是一种虚假的安全感。即使在两人团队中，副作用导致的视觉回归也很常见。只要 main 上每天超过一个 commit，自动化视觉测试就有价值——无论团队大小。
测试每个 commit 还是只测 merge request？
在 trunk-based 中，在每个 merge request 上做视觉测试（阻塞门禁），在每次合并后在 main 上做（集成后验证）。merge request 上的测试是主要过滤器。合并后测试是捕获 commit 间组合问题的安全网。
视觉测试如何与 trunk-based 中的 feature flag 交互？
视觉测试必须至少覆盖每个活跃 feature flag 的两种状态：flag 启用和 flag 禁用。对于有显著视觉影响的 flag，将两种状态都添加到视觉测试套件中。当 flag 被移除（功能对所有人启用时），从测试中移除"flag 禁用"状态并相应更新参照。
能只用端到端测试实践 trunk-based 吗（不做视觉测试）？
技术上可以。但您的端到端测试不会检测视觉回归——一个在 DOM 中仍可点击的不可见按钮、与图片重叠的文字、一个溢出容器的组件。端到端测试验证行为。视觉测试验证外观。在集成速度最大的 trunk-based 中，您需要这两层保护。
延伸阅读
Trunk-based development 是强力加速器。视觉测试是让您安全使用它的制动系统。二者缺一不可。