问题描述
提到了一个关于在超过1000个客户中存储、更改和部署配置片段的问题。他们正在进行向“配置即代码”（CaC）的过渡，目前许多站点仍然是手动配置的。手动配置的一个副作用是有时配置会出现问题，而且没有人知道发生了什么。通过应用CaC，可以在环境出现问题时查阅版本控制系统（VCS），然后更容易找出问题的原因。另一个优点是人们无法直接在生产系统上更改配置。
用户提到一个关于配置是否在多个客户之间共享的问题。目前来看，这并不是一个问题，而且用户希望防止过多的共享，因为过多的共享也可能导致复杂的配置，即混乱。
总结来说，每个客户站点有多个配置文件。
解决方案
方案1：单独的VCS仓库
在这种方法中，为每个客户创建单独的VCS仓库，这样每个客户的配置更改将导致特定环境的部署。以下是该方法的一些优缺点：
优点：
– 客户之间没有干扰的风险，隔离性较好。
– 可以为不同的客户实施不同的访问控制。
– 可以为不同的客户实现不同的CI/CD流水线或配置。
– CI/CD配置较为简单/标准化。
– 每个客户的仓库历史保持干净。
– 更容易计算每个客户的资源使用情况。
– 维护风险较低 – 最好只有一部分客户受到影响，而不是全部客户。
缺点：
– 需要更多资源（每个客户一个CI/CD流水线），但这些成本可以体现在服务定价中。而且由于自动化，这些成本应该会大大降低。
– 跨客户共享配置/流程变得困难。
方案2：单一的VCS仓库（Monorepo）
这种方法是将所有配置放入单一的VCS仓库，并为每个客户创建一个文件夹。以下是该方法的一些优缺点：
优点：
– 清楚地知道所有配置都存储在一个仓库中。
– 在单一仓库下管理所有客户的配置，更容易维护。
缺点：
– 如何在特定的客户文件夹更改时触发特定的构建并将其部署到客户环境仍然是一个问题。
解决方案：
如果想要在单一的VCS仓库中实现统一的视觉展示，可以在单一的Umbrella仓库下管理所有客户的个别仓库，具体做法如下：
- Umbrella仓库只包含一个清单文件，列出了每个客户仓库，它们的版本以及其他相关信息。
- 对于个别仓库的更改需要在Umbrella仓库中进行相应的清单更改，以推动整体项目的进展。
- 使用一小组封装工具在Umbrella仓库级别操作，但控制个别仓库。
最佳答案
下表给出了不同VCS和CI/CD工具的优缺点概述：
| VCS | Monorepo | CI/CD | 优点 | 缺点 |
|---|---|---|---|---|
| CircleCI | ||||
| Jenkins | 需要使用Groovy脚本进行筛选 | |||
| Jenkins | 代码更改导致部署到 | 需要超过1000个Jenkins任务 | ||
| 客户环境 | ||||
| git |
在这些方案中，最终的选择取决于你对于维护、资源利用率和清晰度的权衡。将个别的客户仓库与Umbrella仓库相结合可能是一种中间地带的解决方案，可以在一定程度上平衡这些优缺点。