问题描述
随着公司的发展壮大，产品范围的扩展以及DevOps相关活动的增加，我们从Bamboo切换到了更灵活和可配置的Jenkins，使用部署流水线和其他插件；我们转向了Ansible，并开始在内部逐渐使用Docker。所有这些活动都需要一定程度的编码或配置，包括Ansible脚本和配置、Jenkins Groovy脚本、Dockerfile和YAML配置等。
目前，我们创建了一个名为”ops”的单独代码库，其中包含高级目录：jenkins、ansible、docker和other（虽然”other”并不是一个好的名称，但目前所有其他的DevOps自动化内容都在这里）。然而，我们目前的做法并不合适，可能无法很好地扩展。那么，在代码库或代码库中保留与DevOps相关的代码和配置的最佳实践和建议是什么？
解决方案
将DevOps代码与应用程序代码一起组织
当前，您描述的代码和配置组织是基于涉及的技术解决方案来结构的。然而，这是一个不好的设计，会在维护活动中增加很多开销，并且会在我们前进的道路上设置很多陷阱。相反，这种组织应该是围绕着我们正在部署的构件来构建的。
这样做的原因在于，我们希望将构件（例如Docker镜像或软件包）视为以下动作的对象：
– 构建
– 测试
– 部署
这会考虑到我们要执行的最小一组自动化任务。如果我们想要更改有关测试动作的任何内容，只需要访问与相应构件对应的仓库中的文件夹，然后找到需要更新的与Jenkins特定的自动化项。然而，如果自动化方案是围绕技术解决方案构建的，那么我们就需要从无到有地弄清楚Jenkins在测试过程中的角色，并在那里找到与构件相关的自动化项。在复杂情况下，围绕技术解决方案的组织会使更新变得非常困难，因为我们必须事先知道涉及某个服务的所有技术解决方案，然后相应地进行更新。
以构件为中心的组织结构
为了更好地解释构建和部署流程的组织方式，让我们以一个包含网站和微服务“a”代码的仓库为例：
– ./ops/website
– ./ops/micro-service-a
每个目录中包含了名为build、test和deploy的脚本。这种自动化项的组织方式已经在一定程度上变得清晰，现在让我们将注意力转向配置。
配置的组织结构
在应用于类似服务的构件上的deploy动作设置了配置组织的主要条件和要求。在deploy动作中，应该有以下参数：
– 部署的构件版本
– 构件的部署目标，描述了构件将在其中运行的具体环境（例如集群和端点）
– 构件连接到其他端点所使用的凭据（例如数据库）
– 运行时配置（例如缓存条目的生存时间等）
从操作角度来看，这种分解的参数化方式符合部署问题的自然自由度。此外，将凭证与运行时配置分开以避免不加防范地传播凭证，是更好的做法。
总结
综上所述，将DevOps相关的代码与应用程序代码结合在一起是最佳实践。通过将自动化项组织结构围绕构件而不是技术解决方案构建，可以实现更好的可维护性和可扩展性。同时，将自动化项与应用程序代码放在同一个仓库中，可以提高团队之间的合作，并避免“投掷石头过墙”的思维方式。这种组织结构可以帮助您更好地管理流程编排，并在每个环境中维护各种分支。
请注意，这只是一种建议的组织方式，您可以根据实际情况进行调整和优化。
参考链接
补充回复
- 采用此方法的一个风险是，如果v2.1在QA中没有经过验证，而您必须紧急修补生产环境，则无法修改v2.0。如果为此修补程序创建了v2.2，那么当v2.1进入生产环境时，v2.2有很高的风险被覆盖或丢失。在一个代码库中包含多个分离的代码会导致紧急补丁的噩梦（尽管它是可行的，但我必须在此添加这个免责声明）。
- 使用分支来跟踪环境/部署特定信息，我认为这是一种反模式：如果我们有