问题描述
在传统的部署中，尤其是在 Java 领域，”构建一次，到处部署” 是一个非常重要的理念。在发布时，构建的产物应该仅被构建一次，并且存储在像 Nexus 或 Artifactory 这样的仓库中，这些产物是不可变的，可以重复且安全地部署到各个环境中。
然而，GitLab 流程却推荐为每个环境创建一个分支，并在合并请求到分支时将代码部署到该环境。例如，将 master 分支合并到 staging 分支会在 staging 分支上运行 CI/CD，从而在该环境中部署代码。将 staging 分支合并到 production 分支时也会在生产环境中进行同样的操作（甚至可以手动确认运行）。
因此，GitLab 流程似乎会导致我们为每个环境重新构建产物，而不是遵循”构建一次，到处部署” 的原则。
那么，在使用现代工具如 GitLab/GitHub 时，我们是否应该完全放弃”构建一次，到处部署”？这样做好吗？
我们是否可以通过以下方式来增强 GitLab 流程：
– 在合并到 DEV 分支时构建产物，并存储在 Maven 等仓库中。
– 使用这些产物进行部署。
– 将合并到 staging/prod 的操作跳过构建/测试，仅使用相同的产物进行部署。
尽管如此，这似乎违背了 GitLab 等工具的设计理念，所以我认为这可能不是一个好主意。
此外，对于一些大型项目，如 Facebook 的 Presto，在每个环境中单独构建/测试/部署是如何可能的呢？毕竟，比如在 Maven 构建中可能会有数小时的测试时间。显然，我们不希望生产发布需要数小时，这似乎与现代化背道而驰。
你对这个问题有什么看法？
解决方案
在现代工具中，”构建一次，到处部署” 和 GitLab 流程之间存在一些权衡。以下是一些可能的思考和解决方案：
构建一次，到处部署
在许多传统的部署模式中，”构建一次，到处部署” 有其优势。它确保了部署的一致性，降低了风险，并提高了效率。这种模式适合于那些稳定、少有变动的环境，尤其是在需要确保代码在各个环境中都是一致的情况下。
然而，这种方法可能在现代敏捷开发环境中变得不太适用。快速迭代和频繁的变更可能导致构建一次，到处部署的效率降低，因为每次都需要重新构建和部署。此外，不同环境的需求可能不同，因此不同的构建可能更适合特定环境。
GitLab 流程
GitLab 流程和类似的现代 CI/CD 流程强调快速交付和频繁的部署。通过在每个环境中创建分支，可以更灵活地进行环境相关的测试和部署。这种方法在处理不同环境的需求时更加灵活，同时也鼓励更频繁的部署，有助于减少问题的风险。
然而，这种方法可能会导致在每个环境中进行多次构建和测试，可能会增加开发和部署的时间。尤其是在一些大型项目中，测试和构建可能非常耗时，可能会影响到快速的部署。
结合两种方法
你提到的增强 GitLab 流程的方式可以是一个折衷方案。通过在 DEV 分支中构建产物并存储在仓库中，可以确保构建的一致性。然后，可以使用这些构建产物在不同的环境中进行部署，从而减少每个环境中的构建和测试次数。这可以在一定程度上平衡构建一次，到处部署和快速部署的需求。
然而，你也正确地指出，这可能与 GitLab 流程的设计理念不太一致。因此，在采用这种方式时，确保充分考虑团队和项目的需求，并在实施之前进行充分的测试和评估。
结论
在现代化的开发环境中，没有一种通用的解决方案。”构建一次，到处部署” 和 GitLab 流程都有各自的优势和限制。最终的决策应基于团队的需求、项目的特点以及所采用的工具和流程。在制定决策时，确保充分考虑到快速交付、稳定性和效率等方面的权衡。