这与应用程序构建相关的最佳实践有关。我们遵循git flow发展原则。我们用竹子来建造，但这并不重要。我的问题是，通常更好的是有预定的构建或自动构建或手动构建吗？我个人认为自动或手动构建是最佳选择，这就是原因。
自动构建将轮询特定分支（很可能是开发分支），当它检测到更改时，它将启动构建。这很棒，因为在构建新代码时总是会创建一个构建。不好的一面是，如果你有一个5人团队，每个人将他们的功能分支合并到1分钟后开发，那么你将有5个不同的版本。
这让我想到为什么我认为手动构建是最好的。一旦你获得了所有人的改变，你就可以开始构建。这将使构建数量保持较小。
SO如何考虑选项？哪一个是高效CI / CD团队的标准行业惯例？
答案 0 :(得分：1)
我认为您对如何管理构建的任何意见取决于您在流程中的重视程度，而且您的问题并不明确。
撇开;大多数构建系统不需要为每个提交创建不同的构建。如果您在轮询间隔内有多个要进行开发的提交，那么您应该能够将它们作为一个构建进行测试/部署。这对你来说既好又坏。
持续整合
持续集成应该为您提供更顺畅，更快速的开发过程，并确保您的项目处于可释放状态（或者至少通过自己的测试，希望这是相同的事情）。我发现手动构建通常无法实现相同的质量水平。很容易实现重大改变＆＃34;知道＆＃34;它将在下一次手动构建之前被修复，然后开始越来越远，或者当构建失败时，它突然不清楚几个变化中的哪一个引入了失败。对于持续集成，我不仅期望开发分支的自动构建，而且每个功能分支的自动构建都表明它们在合并到开发之前通过了测试。
在许多环境中，与开发团队的成本相比，CI构建的成本可能会微不足道。例如，我目前正在查看一个平均约5个活动提交者的项目，在过去4年左右每天只有12个版本。保持测试快速可靠并不容易，但运行大量构建（同时在功能分支的情况下）应该是。
在某些环境中，测试构建的过程可能不便宜或快速，例如您需要运行需要数小时的硬件测试或性能测试。在这些情况下，您需要采用不同的方法，但您可能实际上也无法实施持续集成，而您的开发/分支策略应该反映出来。
持续投放
通过部署所有可释放的构建，持续交付更进一步，缩短了从开发到达到用户的更改的周期时间。如果在发布（或回滚）这些版本的过程中有一个手动步骤，那么我不相信您应该打电话给您的流程＆＃34;持续交付＆＃34;。
您可以拥有一个非常好的自动部署流程，而不是连续的。对于某些产品而言，持续交付可能非常有价值，但也可能具有破坏性并且不适合其他产品。例如，我们目前不断部署到面向消费者的Web应用程序。我们还维护后端操作工具，我们对何时发布（或至少何时启用新功能）更为保守，因为对这些工具的更改可能会引入我们不希望出现在某人中间的新工作流程＆＃没有警告就转移了。
<强> TL;博士
自动化所有内容，通过尽量减少构建数量来减慢团队速度。