问题描述
在进行DevOps流程时，是否合适将DevOps资源存放在与项目源代码不同的代码库中，以执行DevOps流程？用户提到了一些预期的好处，包括：
– 将文件（如Dockerfile、Jenkinsfile或Kubernetes部署文件）版本化存放在不同的代码库中。
– 确保部署流程的安全性。
– 能够管理项目的部署流程，因为某些项目可能由多个代码库组成。
用户了解单体库（monorepo）和多库（multirepo）的概念，但他提到的情况略有不同。他的意思是将部署文件的代码库与源代码的代码库分开。
这种方法可行吗？你有类似的实践经验吗？这种方法是否有用？这种方法有特定的名称吗，或者是否就是多库（multirepo）的一种表现形式？
期待您的建议，感谢大家！
解决方案
请注意以下操作可能存在版本差异或个人实践经验，请酌情参考。
分离DevOps资源与项目源代码的方式是一种有效的实践，通常被称为GitOps。以下是我在容器化微服务构建和部署流程中的一些做法：
每个服务的代码库包含其自己的Dockerfile、Kubernetes部署文件等，以便在本地构建和测试项目。Dockerfile的基础镜像可能由另一个代码库管理，但由组织进行构建和托管。
CI步骤通常外部化到一组公共库或模板中。如果有Jenkinsfile或类似的文件，它会设置一些变量并调用通用模板来构建并生成构建产物。
构建产物包括Docker镜像，推送到镜像仓库，以及部署文件（Compose文件、Kubernetes部署文件、Helm模板）以及其他部署所需的变量。这些部署文件和变量被推送到一个独立的部署代码库，该代码库包含所有微服务的部署文件。每个应用堆栈只有一个部署代码库，因此这个提交成为一个汇聚步骤。将部署文件推送到这个代码库是在微服务代码库的CI流程中自动化的，当拉取请求被足够多的受信任的人批准并合并到受保护的分支时会触发这个步骤。这提供了所需的安全检查。
部署代码库的提交会触发其自己的流程，实际上是遵循接近GitOps设计的流程。这也可以是一个监视代码库并应用更改的GitOps工具，但目前我一直在使用一个单一的CI工具来完成这两个操作，简化了工作流程，并允许一些脚本在部署时运行。对于我来说，这些脚本会加载提交的变量，应用额外的变量（例如，部署到哪个环境），渲染模板（当前是Helm的Umbrella Chart），然后进行部署。
到其他环境的部署成为部署代码库分支之间的拉取请求。也可以是不同的代码库来强制执行安全控制。重要的是，渲染的部署文件应该指向一个不变的镜像标签或SHA哈希，以确保在开发和测试阶段推送的内容与生产环境一致。我将这些镜像标签包含在提交到部署代码库的值文件中。
这种方法的一个重要优势是，相互交互的多个微服务可以一起进行测试，并作为一个单元一起部署。所有服务都汇聚到一个部署代码库中，包含它们的部署文件和要使用的镜像标签。不会出现这样的情况，即服务A获得了一个新功能，但有bug；服务B依赖于该新功能进行构建，然后服务B在服务A之前发布到生产环境（当每个服务在隔离的流水线中构建和部署时，这是一个常见问题）。如果服务A阻塞了堆栈的部署，那么可以向部署代码库提交拉取请求，将服务A的提交还原。然后，如果服务B在旧版本的服务A上通过了测试，服务B就会发布到生产环境。
综上所述，通过将部署文件与源代码分开存放，并采用GitOps的方式进行构建和部署，可以实现更加灵活、可靠的DevOps流程。这不仅能够提高多服务之间的协作效率，还能够确保部署的一致性和安全性。