在代码库中组织DevOps相关代码和配置的最佳实践

120次阅读
没有评论

问题描述

随着公司的发展壮大,产品范围的扩展以及DevOps相关活动的增加,我们从Bamboo切换到了更灵活和可配置的Jenkins,使用部署流水线和其他插件;我们转向了Ansible,并开始在内部逐渐使用Docker。所有这些活动都需要一定程度的编码或配置,包括Ansible脚本和配置、Jenkins Groovy脚本、Dockerfile和YAML配置等。

目前,我们创建了一个名为”ops”的单独代码库,其中包含高级目录:jenkinsansibledockerother(虽然”other”并不是一个好的名称,但目前所有其他的DevOps自动化内容都在这里)。然而,我们目前的做法并不合适,可能无法很好地扩展。那么,在代码库或代码库中保留与DevOps相关的代码和配置的最佳实践和建议是什么?

解决方案

将DevOps代码与应用程序代码一起组织

当前,您描述的代码和配置组织是基于涉及的技术解决方案来结构的。然而,这是一个不好的设计,会在维护活动中增加很多开销,并且会在我们前进的道路上设置很多陷阱。相反,这种组织应该是围绕着我们正在部署的构件来构建的。

这样做的原因在于,我们希望将构件(例如Docker镜像或软件包)视为以下动作的对象:
– 构建
– 测试
– 部署

这会考虑到我们要执行的最小一组自动化任务。如果我们想要更改有关测试动作的任何内容,只需要访问与相应构件对应的仓库中的文件夹,然后找到需要更新的与Jenkins特定的自动化项。然而,如果自动化方案是围绕技术解决方案构建的,那么我们就需要从无到有地弄清楚Jenkins在测试过程中的角色,并在那里找到与构件相关的自动化项。在复杂情况下,围绕技术解决方案的组织会使更新变得非常困难,因为我们必须事先知道涉及某个服务的所有技术解决方案,然后相应地进行更新。

以构件为中心的组织结构

为了更好地解释构建和部署流程的组织方式,让我们以一个包含网站和微服务“a”代码的仓库为例:
./ops/website
./ops/micro-service-a

每个目录中包含了名为buildtestdeploy的脚本。这种自动化项的组织方式已经在一定程度上变得清晰,现在让我们将注意力转向配置。

配置的组织结构

在应用于类似服务的构件上的deploy动作设置了配置组织的主要条件和要求。在deploy动作中,应该有以下参数:
– 部署的构件版本
– 构件的部署目标,描述了构件将在其中运行的具体环境(例如集群和端点)
– 构件连接到其他端点所使用的凭据(例如数据库)
– 运行时配置(例如缓存条目的生存时间等)

从操作角度来看,这种分解的参数化方式符合部署问题的自然自由度。此外,将凭证与运行时配置分开以避免不加防范地传播凭证,是更好的做法。

总结

综上所述,将DevOps相关的代码与应用程序代码结合在一起是最佳实践。通过将自动化项组织结构围绕构件而不是技术解决方案构建,可以实现更好的可维护性和可扩展性。同时,将自动化项与应用程序代码放在同一个仓库中,可以提高团队之间的合作,并避免“投掷石头过墙”的思维方式。这种组织结构可以帮助您更好地管理流程编排,并在每个环境中维护各种分支。

请注意,这只是一种建议的组织方式,您可以根据实际情况进行调整和优化。

参考链接

补充回复

  1. 采用此方法的一个风险是,如果v2.1在QA中没有经过验证,而您必须紧急修补生产环境,则无法修改v2.0。如果为此修补程序创建了v2.2,那么当v2.1进入生产环境时,v2.2有很高的风险被覆盖或丢失。在一个代码库中包含多个分离的代码会导致紧急补丁的噩梦(尽管它是可行的,但我必须在此添加这个免责声明)。
  2. 使用分支来跟踪环境/部署特定信息,我认为这是一种反模式:如果我们有
正文完