如何在代码存储库中构建与DevOps相关的代码和配置？

作为一家公司，我们一直在发展，我们的产品也在扩展，与DevOps相关的活动和努力也在不断增长-我们已经使用部署管道和其他插件从Bamboo转变为更加灵活和可配置的Jenkins。切换到Ansible并开始在本地和本地使用Docker。

所有这些都需要一定程度的编码或配置-Ansible脚本和配置，Jenkins groovy脚本，Dockerfile和YAML配置。

现在，我们已经创建了一个独立的“OPS”资源库和高层次的目录jenkins，ansible，docker和other（这是一个可怕的名字，但现在所有的“其他”的DevOps自动化的东西在那里）。

我们的方法感觉不正确，可能无法扩展，但是将与DevOps相关的代码保留在一个或多个代码存储库中的最佳实践和建议是什么？

您描述的代码和配置的当前组织由所涉及的技术解决方案构成。这是一个糟糕的设计，将在我们的维护活动中增加很多开销，并且也会以我们的方式增加很多陷阱。相反，该组织应该围绕我们正在部署的工件进行组织。

这样做的原因是我们希望将人工制品（例如 docker映像或软件包）视为以下动词的对象：

• 建立
• 测试
• 部署

考虑我们要执行的最少自动化任务集。如果我们要更改测试动词的实现方式，则可以在适当的存储库中轻松访问与该工件对应的文件夹，然后发现需要更新的特定于詹金斯的自动化项目。相反，如果自动化配方是围绕技术解决方案构建的，那么我们需要立即弄清詹金斯参与了测试程序，并在此处找到了与工件相关的自动化项目。在复杂的情况下，围绕技术解决方案的组织很难进行更新，因为我们必须事先了解某些服务中涉及的所有技术解决方案才能进行相应的更新。

例如，包含网站代码和微服务“ a”的存储库可以具有以下专用于操作的子目录：

./ops/website
./ops/micro-service-a

分别具有三个脚本调用build，test和deploy。既然自动化项目的组织方式已经阐明，那么让我们将注意力转移到配置上。

有关配置组织的主要条件和要求由deploy动词应用于类似服务的人工制品时设置。该deploy动词应具有以下参数：

• 要部署的人工制品的版本，
• 工件的部署目标，它描述了部署的工件将在其中运行的具体环境（例如，集群和应该与之通信的端点）
• 连接到其他端点（例如数据库）时应使用的凭据
• 的运行时配置（例如高速缓存条目应保留多长时间等）

从操作的角度来看，此参数的细分与部署问题的自然自由度相匹配-除了可以与运行时配置捆绑在一起的凭据外，但最好将它们分开，以免不慎分散它们。

我可以回答关于docker的问题，使用docker的最佳实践之一是将docker文件和compose文件保存在项目的同一存储库中，因此无论您在哪里克隆项目，都可以构建docker映像，这对保留多个版本的docker compose文件（例如prod，staging，dev），以便您可以构建映像并为每个env运行具有特定选项的容器，例如对于dev机器，您可以使用特定的网络并运行更多的依赖容器或其他。

每个工具的代码都放入其自己的存储库中。例如

1. Jenkins Groovy模板到Jenkins回购中
2. 自己的存储库中的Ansible YAML剧本（具有角色，任务，清单子目录
3. 自己的仓库中的Cloudformation / Terrform模板
4. Docker文件在自己的5.中。依此类推

这将帮助您更好地进行流程编排，并为每个环境维护各种分支

这将为您提供更精细的控制，并将所有版本控制开销转移到版本控制系统。还要为每个环境创建单独的分支，并为每个生产版本标记代码（就像我们对应用程序代码库所做的一样）。根据代码考虑基础设施和流程。（与过程类似，任何过程更改都必须进行整理并发送给QA，SIT，UAT，然后发送给PROD）。

例如，您可能在生产环境（主分支）中运行了Ansible的V2.1，但是在生产产品（主分支）中运行了Docker容器的V2.0

同样，将您的数据库脚本/ bash脚本保存在自己的存储库中，也许您可​​以配置运行状况检查文件（JSON / YAML）以显示每个部署的URL中所有工具/部件的版本，以进行跟踪和自动化。（以便您的Web钩子读取URL并自动执行部署）

在Ops，Dev和DevOps之间进行区分可以促进隔离，并强制执行“扔在墙上”的思维定势。为了增强团队之间的合作，应该将所有内容都放入构建和部署项目所需的存储库中。

话虽如此，问题的答案是：

如何在代码存储库中构建与DevOps相关的代码和配置？

如果要运行该项目需要配置，则应将其放在同一目录中。