问题描述
在构建流程中存储构建产物时，有些疑虑，不确定是否仍然有必要这样做。他的构建速度相当快，采用了git标签版本控制，而且所有构建都是独立的微服务，互相不依赖。用户在构建流程中保留“Artifactory代码”是否有充分的理由？
解决方案
请注意以下操作可能存在版本差异及风险，请在操作前做好备份。
为什么存储构建产物是有意义的？
存储构建产物在持续交付流程中有许多合理的理由，尽管你的构建速度较快且构建之间相互独立。以下是一些支持存储构建产物的论点：
1. 促进环境一致性
从《持续交付》（Humble 和 Farley 著）中可以得知，存储构建产物可以在不同环境中部署时促进一致性。每次编译代码都存在引入差异的风险。后期阶段安装的编译器版本可能与您用于提交测试的版本不同。您可能会选择不同版本的某些第三方库，这并非您的初衷。甚至编译器的配置都可能改变应用程序的行为。通过仅构建一次产物，确保生产代码与经过测试的代码完全相同。在非常小的代码库和简单流水线中，这可能不会产生太大的影响，但始终遵循仅构建一次的最佳实践是明智的。
2. 管理依赖性
即使您不能确保每次构建都使用相同的依赖项，存储构建产物仍然可以让您在需要时回溯到特定的构建版本。这对于故障排除、问题定位以及回滚至已知工作状态都非常有用。特别是在微服务架构中，每个服务可能依赖于不同的库和依赖项，因此能够跟踪每个服务的构建版本变得尤为重要。
3. 便于回滚和发布
存储构建产物使您能够轻松地回滚到先前的构建版本，以便在出现问题时迅速恢复系统状态。此外，它还为部署到生产环境提供了便利。您可以将存储的构建产物用作生产部署的基础，确保您在发布到生产环境时使用的代码版本与经过测试和验证的版本一致。
结论
尽管您的构建速度快且微服务独立，但存储构建产物仍然具有许多合理的优势。它有助于确保环境一致性，管理依赖性，便于回滚和发布。虽然在某些情况下可能会引入一些额外的开销，但从长远来看，这是一个值得采用的最佳实践。
用户的评论：作为一名DevOps工程师，我不能保证所有构建每次都使用相同的依赖项。此外，尽管我的构建在Docker容器中运行，但这使我随时可以更新容器，而不会出现不一致性的风险。感谢解答。
在这里，用户提出了一些合理的顾虑，指出了他在特定情况下可能无法确保完全一致的依赖性。对于这种情况，使用存储构建产物的做法仍然有助于维护构建版本的可追溯性和一致性，以及提供灵活性来处理依赖项更新。所以，尽管存在一些情况，存储构建产物仍然是一个值得考虑的良好实践。