这是关于与应用程序构建相关的最佳实践。我们正在遵循git flow开发原则。我们用竹子来建造，但这并不重要。我的问题是，是否有更好的计划构建或自动构建或手动构建？我个人认为自动化或手动构建是要走的路，这就是为什么。构建自动化过程
自动构建将轮询特定的分支（很可能是开发分支），当它检测到更改时，它将启动构建。这非常棒，因为当有新代码构建时，您总是创建一个构建版本。不好的一面是，如果你有一个5人的团队，每个人都将他们的功能分支合并为1分钟后开发，那么你将有5个不同的版本。
这导致我为什么相信手动构建是最好的。一旦你有每个人的变化，你可以启动一个构建。这将保持较小的构建数量。
SO对选项有什么看法？哪一个是高效CI/CD团队的标准行业惯例？
我认为你如何管理构建的任何意见取决于你在你的过程中的价值，这是不明确的你的问题。
另外;大多数构建系统不需要每次提交都有独特的构建。如果您在轮询间隔内有多次提交开发，则应该能够将它们全部测试/部署为一个构建。这可能对你有好处或坏处。
持续集成
持续集成应该给你与你的项目处于释放状态（或者至少通过其自己的测试，希望这是同样的事情）保证一个更加顺利和迅速发展的过程。我发现手动构建通常无法实现相同的质量水平。对于“知道”在下一个手动构建之前将其修复的问题进行修改变得非常容易，因为在下一个手动构建开始滑动越来越远或者构建失败时，突然不清楚引发失败的几个变化中的哪一个会发生变化。对于持续集成，我不仅希望开发分支的自动构建，还希望每个功能分支的自动构建都显示他们在将测试合并到开发之前通过测试。
在许多环境中，与开发团队的时间成本相比，CI构建的成本可以忽略不计。例如，我目前正在寻找一个项目，平均约5个活跃的提交者，并且在过去4年左右每天只有12个构建。保持测试的快速和可靠并不容易，但应该运行大量的构建（同时在功能分支的情况下）。
有些环境下测试构建的过程不便宜或快速，例如您需要运行需要花费数小时的硬件测试或性能测试。在这些情况下，您需要一种不同的方法，但您实际上也可能无法实践持续集成，而您的开发/分支策略应该反映这一点。
持续交付
连续输送进了一步，并从发展缩短了循环时间的变化，通过部署所有这些松脱建立您的用户。如果在释放（或回滚）这些构建过程中有手动步骤，那么我认为您不应该将您的过程称为“持续交付”。
你可以有一个非常好的自动化部署过程，而不是连续的。持续交付对某些产品可能非常有价值，但也可能是破坏性的，对其他产品不适合。例如，我们目前不断部署到面向消费者的Web应用程序。我们还维护后端操作工具，我们对何时发布（或至少何时启用新功能）更为保守，因为对这些工具的更改可能会引入新的工作流程，而我们不希望在没有警告的情况下出现在某人的轮班中间。
TL;博士
自动化的一切，不要试图让小构建的数量放慢你的团队。