所有这些都需要一定程度的编码或配置-Ansible脚本和配置，Jenkins groovy脚本，Dockerfiles和YAML配置。
现在，我们已经创建了一个单独的“ ops”存储库，其中包含
jenkins，ansible，docker和other的高级目录（这是一个糟糕的名称，但是现在所有“其他” DevOps自动化我们的方法感觉不正确并且可能无法扩展，但是将与DevOps相关的代码保留在一个或多个代码存储库中的最佳实践和建议是什么？
#1 楼
您描述的代码和配置的当前组织由所涉及的技术解决方案构成。这是一个糟糕的设计，将在我们的维护活动中增加很多开销，并且也会以我们的方式增加很多陷阱。相反，该组织应该围绕我们正在部署的工件进行组织。原因是我们希望将工件（例如docker映像或软件包）视为以下动词的对象：
构建
测试
部署
，以考虑我们要执行的最少自动化任务集。如果我们要更改测试动词的实现方式，则可以轻松地在适当的存储库中访问与该工件相对应的文件夹，然后发现需要更新的特定于詹金斯的自动化项目。相反，如果自动化配方是围绕技术解决方案构建的，那么我们需要立即弄清詹金斯参与了测试程序，并在那里找到了与工件相关的自动化项目。在复杂的情况下，围绕技术解决方案的组织会使更新变得非常困难，因为我们必须事先了解某些服务中涉及的所有技术解决方案才能相应地进行更新。
例如，包含用于一个网站和一个微服务“ a”可能具有以下专门用于运营的子目录：现在已经以某种方式阐明了自动化项目的组织，现在让我们将注意力转移到配置上。
当将
build动词应用于类似服务的人工制品时，有关配置组织的主要条件和要求由test动词来设置。 。 deploy动词应具有以下参数：要部署的工件的版本，
文物的部署目标，它描述了已部署文物将在其中运行的具体环境（例如，群集和应与之对话的端点）
用于连接到其他端点（例如数据库）的凭据
运行时配置（例如，高速缓存条目应保留多长时间等）
从操作的角度来看，这种参数分解除符合凭据外，还与部署问题的自然自由度相匹配可以与运行时配置捆绑在一起，但最好将它们分开，以免不慎分散它们。
#2 楼
我可以回答关于docker的问题，使用docker的最佳实践之一是将docker文件和compose文件保存在项目的同一存储库中，因此无论您在哪里克隆项目，都可以构建docker映像，这对保留多个版本的docker compose文件（例如prod，staging，dev），以便您可以构建映像并为每个env运行具有特定选项的容器，例如对于dev机器，您可以使用特定的网络并运行更多依赖项容器或其他任何东西。#3 楼
每个工具的代码都放入其自己的存储库中。例如将Jenkins Groovy模板转换为Jenkins存储库
在其自身存储库中的Ansible YAML剧本（具有角色，任务，库存子目录
在自己的仓库中
在自己的仓库中的Docker文件中
5 ..依此类推
，这将帮助您更好地扩展流程编排并维护每个环境的各种分支br />
这将为您提供更精细的控制，并将所有版本控制开销转移到版本控制系统，还为每个环境创建单独的分支并为每个生产版本标记代码（就像我们对应用程序代码库所做的一样） 。以代码的方式考虑基础设施和流程（任何流程变更都必须进行整理，并发送给QA，SIT，UAT，然后发送至PROD），类似于应用程序。例如，您可能拥有V2 .1的Ansible在Production（主分支）中运行，而V2.0的Docker容器在Prod（主分支）中运行
类似地保留您的数据库cripts / bash脚本存储在它们自己的存储库中，也许您可以配置运行状况检查文件（JSON / YAML）以显示每个部署的URL中所有工具/部件的版本，以进行跟踪和自动化。 （以便您的Web钩子读取URL并自动执行部署）
评论
这种方法的陷阱是，v2.1在qa中且未经验证，您必须紧急修补生产，无法修改v2.0，如果为此修补程序制作v2.2，则存在很大的风险v2.1投入生产时丢失或被覆盖，再乘以一个回购中的单独代码量，您很快就会产生噩梦般的反向移植（它可以正常工作，但我必须添加此免责声明:)）
–滕西拜
17年8月25日在5:02
对我来说，使用分支来跟踪特定于环境/部署的信息似乎是一种蚂蚁模式：如果我们有20个环境，则意味着我们有20个分支保持同步……这可能是错误和混乱的根源。您能否解释为什么不使用配置文件来跟踪特定于环境/部署的信息，以及这些分支机构的工作流程是什么？这些不是小问题！
–MichaëlLe Barbier
17年8月29日在13:03
#4 楼
在Ops，Dev和DevOps之间进行区分可以促进隔离，并强制执行“扔掉”的思维定势。为了增强团队之间的合作，应该将所有内容都放入构建和部署项目所需的存储库中。这么说，问题的答案：
如何在代码存储库中构建与DevOps相关的代码和配置？
是如果需要config来运行项目，则应将其放在同一目录中。
评论
在厨师中，我采用“每个部分都是一个应用程序，每个应用程序一个回购”的方法，这意味着每个食谱有1个回购。@Tensibai对，我担心单个“操作”回购将很快变得不切实际。谢谢。
这一直是厨师管理菜谱的传统形式，所有菜谱都有1个回购协议，并且在大多数情况下被证明是步枪，因此是改变的地方，但是我不太愿意说它也适用于Jenkins管道（如果是v2）和docker文件应该与它们处理IMO的项目一起使用，并且我不知道您将其他内容放在什么下，所以我在这里真的不能给出任何建议
@Tensibai知道了！其他的大部分由bash和python实用程序组成，或者由多个内部工具定期执行的脚本组成。.它们真的不适合任何地方，我们无法想到一个比“ other”更好的地方。.我看看是否可以发布内容目录中的问题。谢谢。
我通过“亲和力”工作将它们分成多个存储库，脚本在应用X上一起工作，您可能在两个应用上使用了一个脚本，但是如果应用A更改了脚本必须处理与之通信的应用的方式，最好有两个分开的版本，所以ATEOTD我将它们与它们相关的应用程序一起存储，或者如果它们在每个任务的特定存储库中跨越多个应用程序，那么您始终拥有一个与已部署的应用程序一致的版本，而您不会无需同时标记不相关的脚本。