最近，我发现我们经常提到左移。诚然，左移已是一大趋势，帮助发布经理面对挑战。我认为左移也正是发布经理真正需要的，帮助提高发布管理质量和速度。毕竟，如果不能保障产品及时、高质量发布，那发布管理也就无从可说了？
也许有读者正挠头困惑什么是左移。简单来说，左移就是尽量在开发早期多做一些准备工作（主要是测试，但不止局限于测试，我会稍后解释），以便在开发过程中尽早发现缺陷，然后将它们左移。
例如针对测试，可以将测试向左移动，在开发人员提交代码之前执行，而不用等到后续的持续集成构建才运行。开发人员在提交之前测试代码，快速找到错误（如果测试失败），并及时修复。而不用苦等 CI/CD 进程通知失败，才又从头开始。除了更快地找到错误，并锁定在上下文中，这种方法还将 CI/CD 中失败的几率最小化，从而使开发过程更加高效和灵活。
左移还与“敏捷”相关，还有一些其他大家经常提到但并不总是执行的流行词汇有关。但，理解和执行是两码事。虽然 “左移”和“敏捷”都已经出现在很多人的梦呓里，但当具体采取左移措施以实现敏捷开发时，往往心有余而力不足。
看看《2020 年测试自动化报告》就知道了。该报告发现，只有 19% 的受访公司依赖开发团队进行测试。除了测试之外，他们不了解其他可以进行左移的方式。
从最常见的开始：测试左移
左移通常被解读为早期测试，把问题留给开发团队，而不是 QA 团队。“通常”，意味着这种误解到现在也是广泛存在。
我要说的是，在发布管理中，左移不仅仅是测试左移。当然，测试左移的方式很好，尤其是涉及到版本管理和 CI/CD 管道时，测试左移是救命稻草。这意味着在周期的早期就解决了测试问题（例如集成测试、功能测试和单元测试）。如果进行测试驱动开发并尽早修复这些问题，或者说失败得越早，节省的时间也就越多，因为我们可以迅速“锁定”出现问题的区域并及时修复。否则就要等到 CI/CD 进程失败，问题才暴露，已经太晚了。很明显，这也大大节省了发布经理的时间，因为测试失败而导致构建中断的情况减少了。另外，反馈循环更频繁紧密，所以产品质量也相应提升（可以想象 QA 团队和发布经理脸上的笑容了）。
唯一的问题是这个过程需要时间，尤其是在构建时间很长的情况下。代码、构建、测试的恶性循环（夸张一点来说），受害者是开发人员，他们需要经历漫长的等待过程，这也是让人沮丧的。由于开发团队有严格的截止日期，所以许多开发团队选择测试左移，反正早晚都要进行测试。但是，如果你编译速度很快，测试也很快，那么你就真正具备了在测试左移中取得成功的条件。
所以，你已经将测试转移到了开发阶段，并确保快速测试和编译，保证在截止日期前完成测试，然后呢？你能喘口气，然后放松一下吗？很难。左移不仅仅是测试左移。要高效实现发布管理，你不能只满足于测试左移，否则，就会被同行超越。
要实现真正的敏捷开发，你需要扩展左移区域，将通常位于发布自动化过程右侧的其他区域也向左移动，并将它们包括在发布自动化进程中。
将“安全（Sec）”移入 DevOps
除了测试，还有另一个与左移相关的高频词：DevSecOps！
DevSecOps 也是个热词，但也是敏捷的一部分。安全漏洞本应该在发布之前检测出来。在许多组织中，安全性曾经属于发布自动化或 DevOps 流程的部分（通常是在部署之前的最后一个周期），现在是发布自动化的一部分。
诚然，有些人认为安全测试是测试的一部分，因此是测试左移的一部分。但其他人认为这是一种新的左移，一种自力更生的左移，突出了曾经在发布自动化过程中靠右的进程，现在融入发布自动化（与测试左移相反，测试左移从发布自动化过程转移给开发人员）。这种转变能有效节省大量的工作量和资金，正如 IBM 的这份报告所显示：平均 80 美元用于修复开发早期发现的缺陷和漏洞，7600 美元用于修复生产中发现的漏洞，成本翻了 95 倍多。
图片来源: IBM
“过渡”优先
另一个左移到发布自动化内部的例子是过渡环境自动化。这意味着，作为发布自动化的一部分，你可以在生产之前自动检查生产代码，而不是在最后手动检查。
将每个阶段左移
还有另一种类型的左移：及时左移。例如，代码分析之类的进程再也不用拖到周末运行，而是可以经常、每天甚至每次提交前进行。一旦加快了这些耗时的进程，一切都有可能。代码分析可以从 36 小时（是的，很长）缩短到 8 小时，而且你可以每晚运行代码分析进程。时间缩短，进一步帮助白天运行测试，并及时修复缺陷。
我们可以向左自由移动到“任何时间”，而不用限定在在开发周期中的特定阶段。你看，左移不仅仅是将流程从发布自动化转移到开发团队，或者从发布自动化之外转移到发布自动化，还包括在开发周期的早期以更强的节奏运行进程。
每夜构建左移成每次构建
还记得我前面提到的每次构建吗？从每夜构建到每次提交构建是发布自动化中左移的另一个例子。想想这种转变的含义。你可以加快编译时间，并在每次提交时运行构建，而不是因为运行构建耗时太长（即使只需要几分钟），不断地在时间上妥协。每一次提交。这意味着可以比以前更早地修正构建。
游戏规则已改变。
游戏规则的原因，并不是因为左移提升了速度、避免了内容切换、在周期的早期发现错误并快速反馈，而是因为它明确指出了到底是谁破坏了构建。对于发布经理来说，这一点至关重要。这意味着他们不必花太多时间去讨论构建失败的原因，找出谁应该对此负责。此外，他们可以自动生成通知，以便向破坏构建的开发人员发出通知。甚至更进一步，创建一个封闭签入，这样一旦构建失败，“有问题的”提交就不会污染存储库。因此，存储库对错误提交保持“距离”。发布经理也能始终保持一个“无污染”的正确版本，以便发布给客户或最终用户。
你能随心所欲进行全量重建吗？
作为一个发布经理，如果每个开发人员都能在提交更改之前，在最需要时候进行全量重建，像增量构建一样，这不是很好吗？
在开发阶段更早地运行全量重建，在进程中发现缺陷且及时修复，避免了CI/CD 构建失败，这与在 CI/CD 进程中妥协而不得不全量重建不同。同样，想要经常运行全量重建，前提是大幅缩短构建时间，否则也不可行。不要妥协！
我相信我们都会喜欢在代码提交之前运行测试，但是我们会妥协，因为这需要很多时间。我们当然希望每天都运行代码分析进程，但是这也需要时间。你明白了么？这些“但是”大多是由于缺乏计算能力而导致的耗时进程，不过，很多人甚至不知道可以打破计算能力的限制，从而不用妥协！
Incredibuild 能做什么？
我很高兴能在一家像 Incredibuild 这样的公司工作，因为它是左移的重要推动者，也是整个敏捷方法的践行者。
测试左移，安全左移，每夜构建左移，全量重建左移——我们都能做到！通过全马力加速开发，为每个开发人员主机和构建服务器提供成百上千个 CPU，Incredibuild 极大地减少了编译、测试和其他进程的时间，使构建在开发周期中运行更频繁、更早！
具体案例，可以参考 Retalix，看看他们是如何使用 Incredibuild 将测试左移，将每个开发人员的单元测试执行时间从 2 小时减少到 12 分钟。
你也希望有这样的“惊喜”吗？
“左移”可能是一个相对较新的趋势，但这种转变已经持续一段时间了。二十年来，我们一直在为客户左移测试和构建，并将矢志不渝地左移所有测试和构建。
