|
|
|
作者 |Roy Osherove
头图 | CSDN 下载自东方 IC
出品 | CSDN（ID：CSDNnews）以下为译文：
我们需要根据代码的反馈来决定是否应该继续修改代码还是应该发布，而构建（即编译+运行测试+部署+更多测试等）正是获取该反馈的瓶颈。影响构建的主要因素有两个：
[list,
[*,构建运行的频率（每次代码提交、每小时、每周等等）
[*,构建需要花费多长时间才能完成
[/list,许多公司还会下功夫减少对手动QA环节的依赖等，但在过渡过程中（例如建立更多的自动化测试，或存在目前无法实现自动化的测试），仍需一些手动测试或验证。因此，我们还需要考虑一个额外的因素：
[list,
[*,何时需要手动验证
[/list,有时，由于部署要求、环境要求或构建可执行文件的要求，只能在构建完成后才能进行手动验证。这意味着构建是流程中的约束之一。
频率是新的约束
根据“限制理论”，我们可以做以下假设：
[list,
[*,版本之间的时间越长，每个版本所容纳的改动就越多
[*,这意味着修改的批量越大，这又意味着：
我们需要测试/验证的内容就越多——手动测试需要的时间更长，从而导致反馈循环加长
由于变化更多，所以每个人的紧张程度加剧，风险也越高，并且更有可能要求进行更多的验证
[/list,那么，我们怎样做才能缩小每个构建的批量，并获得更迅速的反馈循环呢？
答案简单明了：更频繁地运行构建。但是，究竟多久一次呢？
我发现许多团队都在背道而驰，他们会想：
由于构建过程需要花费很长时间（4个小时），所以我们只能每晚或每周运行一次。
其实，这种想法正好相反，我们应该想：
因为构建需要花费四个小时，因此我们应该每四个小时就运行一次。
这种做法的好处？
[list,
[*,反馈循环时间从每天构建一次的24个小时，或者每周构建一次的好几天，减少到4-8个小时。假设开发人员现在修改了代码，那么他们就能赶上下一次（几个小时内开始，并在4个小时后结束）的构建。虽然这个方法并不完美，但总胜于等到第二天或本周末才能把修改的代码推送到主分支。
[*,我们始终有一个“最新的稳定版本”，每4个小时就能产生一个最新的成功版本。假设这个构建能够部署到动态演示环境中，则意味着我们始终有最新的演示版本来展示，最多只需等待4个小时。
[*,大幅削减批量：4小时能有多少代码修改？肯定比24小时修改的代码少，对不对？这意味着验证速度也会加快。
[/list,这还意味着，如果我需要手动验证已解决的问题，那也不必等到明天再验证集成版本，最坏的情况，也只需等待8个小时（当天就可以到手！）。
构建的时长是下一个约束
现在（在我们设置了恰当的构建运行时间之后），我们减少了构建之间的等待时间，下一个阻碍反馈循环缩短的重大约束就是构建时长。
我们为缩短构建时间而做出的每项变更（例如，通过并行测试或步骤）都会影响到反馈循环的缩短，而现在构建时间就是我们的反馈周期。如果构建只需要一个小时（而不是四个小时），那么我们可以每小时运行一次。
因此，在修改完代码、提交并推送之后，我需要在1-2小时内手动验证集成版本所包含的代码改动。这些工作都发生在同一天。
如果构建需要30分钟怎么办？同理，循环周期就是30-60分钟。
环境可能是最原始的约束（瓶颈）
如果你的环境有问题，那么本文等于白说了。
有时，团队不得不减少运行构建的次数，因为他们不想部署到静态环境，有可能别人也在用同一个环境。我之前曾提过：静态环境是一个巨大的瓶颈。
因此，一个重要的因素是：你是否可以在指定的时间或其他限制内，每完成一次构建就重新部署一次环境。好消息是，如果你使用的是Docker和Kubernetes之类的工具，那么每完成一次构建，只需5分钟就能动态生成Kubernetes的命名空间。
99%的静态环境都应已成为过去，我们需要思考的是，如何要求因循守旧的IT部门采用新工具来引入这些新的观念。
你可能也需要解决这个问题，或者至少创建一个不需要人介入、完全自动化的静态环境，这有这样你才能摆脱这个约束，并着眼本文讨论的这个话题。
原文：http://pipelinedriven.org/article/if-builds-take-4-hours-run-them-every-4-hours
你点的每个“在看”，我都认真当成了喜欢 |
|
发表于 2020-5-13 00:47:52
