构建自动化过程

Posted 2023-03-30

【中文标题】构建自动化过程

【英文标题】：Build Automation Process

【发布时间】：2017-02-04 00:38:05

【问题描述】：

这是关于与应用程序构建相关的最佳实践。我们遵循git flow的发展原则。我们用竹子来建造，但这并不重要。我的问题是，计划构建、自动构建还是手动构建通常更好？我个人认为自动或手动构建是可行的方法，原因如下。

自动构建将轮询特定分支（很可能是开发分支），当它检测到更改时，它将启动构建。这很好，因为当有新代码要构建时，您总是会创建一个构建。不好的一面是，如果你有一个 5 人的团队，并且每个人在 1 分钟后将他们的功能分支合并到开发中，那么你将有 5 个不同的构建。

这让我明白了为什么我认为手动构建是最好的。一旦你得到了每个人的改变，你就可以开始构建了。这样可以减少构建数量。

SO 对这些选项有何看法？哪一个是高效 CI/CD 团队的标准行业实践？

【参考方案1】：

我认为关于您如何管理构建的任何意见都取决于您在流程中的价值，而这在您的问题中并不清楚。

顺便说一句；大多数构建系统不需要每次提交都有不同的构建。如果您在轮询间隔内有多个开发提交，您应该能够将它们全部测试/部署为一个构建。这对您来说可能是好是坏。

持续集成

持续集成应该让您的开发过程更加顺畅和快速，并确保您的项目处于可发布状态（或者至少通过了自己的测试，希望是同样的事情）。我发现手动构建通常无法实现相同的质量水平。提交重大更改太容易了，因为“知道”它将在下一次手动构建之前修复，然后开始越来越远，或者当构建确实失败时，突然不清楚几个更改中的哪一个导致了失败。对于持续集成，我不仅希望您的开发分支的自动化构建，而且每个功能分支的自动化构建都表明它们在合并到开发之前通过了您的测试。

在许多环境中，与开发团队的时间成本相比，CI 构建的成本可以忽略不计。例如，我目前正在研究一个项目，在过去 4 年左右的时间里，平均大约有 5 个活跃的提交者并且每天只有 12 个构建。保持测试快速可靠并不容易，但运行大量构建（同时在功能分支的情况下）应该是。

在某些环境中，测试构建的过程既不便宜也不快速，例如您需要运行需要数小时的硬件测试或性能测试。在这些情况下，您需要一种不同的方法，但您也可能实际上无法实践持续集成，您的开发/分支策略应该反映这一点。

持续交付

持续交付更进一步，通过部署所有可发布的构建，缩短了从开发到更改到达用户的周期时间。如果在发布（或回滚）这些构建的过程中有手动步骤，那么我认为您不应该将您的过程称为“持续交付”。

您可以拥有一个非常好的自动化部署过程，而不需要它是连续的。持续交付对于某些产品可能非常有价值，但也可能具有破坏性并且不适合其他产品。例如，我们目前持续部署到面向消费者的 Web 应用程序。我们还维护后端操作工具，我们对何时发布（或至少何时启用新功能）更加保守，因为对这些工具的更改可能会引入新的工作流程，我们不希望在没有警告的情况下出现在某人的轮班中.

tl;dr

自动化一切，不要因为尽量减少构建数量而减慢团队的速度。