如今，即使使用镜像，代理和缓存，许多公司也无法直接控制外部存储库中软件包的组成。这导致执行环境不断变化的事实，尤其是docker映像的构成比生产所需的变化更频繁。
在某些情况下，外部依赖项中包含的不必要更改会进入正在开发的产品的组成部分。在产品认证期间尤其如此。结果，在发布修补程序时，认证延迟，夜间测试和集成测试失败，本地生产（位于组织自己资源上的生产环境）崩溃。在一篇新文章中，我们描述了一种避免此类问题的方法。
我们想要实现的目标
在继续介绍该方法之前，请先简要介绍一下我们要解决的任务：
- 完全控制发行版中外部软件包的组成（可预测性）。
- 修复外部存储库的组成，以最小的附加测试（速度）快速推出修补程序。
- 为产品质量保证站提供可重复，可预测的固定环境（可重复性）。
- 独立于外部通讯渠道的存在（自治）。
- 如果发生故障（容错），可立即切换到正式存储库。
- 确保对装配流水线中的外部存储库的密钥进行验证（信任）。
- 最重要的是，将对外部软件包组成的管理和控制权移交给产品团队和发行经理（自我管理）。
功能构建生命周期分析
我们的方法解决了为特定日期，版本或功能固定外部存储库组成的问题。下图说明了版本，功能构建和修补程序生命周期的管理。
让我们以Debian Stretch条件存储库为例。此方法适用于Docker，SaltStack等存储库，在时间轴上记录了三个切片，分别为日期T1，T2和T3。
| T1 | T2 | T3 | |
|---|---|---|---|
| 伸展 | 20200305 | 20200420 | 20200615 |
| 功能1 | 20200304 | 20200304 | 20200501 |
| 功能2 | 20200304 | 20200304 | 20200601 |
| Feature3 | 20200301 | 20200406 | 20200406 |
我们已将用于构建Feature1，Feature2和Feature3发行版的外部Debian Stretch存储库的列表制成表格。从表中可以看到，外部存储库的组成由每个分支独立控制。我们已经为自己达成协议，每天提交Debian Stretch主分支，并以YYYYMMDD格式标记每个切片，例如，20202020年3月4日为2020304。下表总结了用于在三个不同时间在每个分支中进行分发的外部存储库的快照，以及Debian Stretch向导中的组成。每个功能或每个发行版的团队均会根据其开发周期，自行决定是否更新外部存储库的组成。
以Feature1为例：产品团队开始开发新功能，并从20200228开始在配置文件中修复外部存储库的组成（请参见上图）。
切换到20200228
deb http://repository.co/debian-stretch-20200228 stretch main contrib non-free
在开发过程中，由于新软件包的出现，有必要将软件包数据库更新为日期20200304。将工作存储库转换为所需日期。
切换到20200304
deb http://repository.co/debian-stretch-20200304 stretch main contrib non-free
接下来，将包基础更改为日期20200501，再切换
到20200501
deb http://repository.co/debian-stretch-20200501 stretch main contrib non-free
如果现在绘制时间片，我们将看到在时间点T1和T2 Feature1开发处于包基础上，即“冻结”于2020年3月4日。在T3削减计划中，已经在2020年5月1日开发新的套件基础上。
产品多版本依赖管理
现在，让我们看一下几个活动产品版本的依赖管理。支持三个版本，分别是2.5、2.6和2.7。
在表中，我们可以看到发布版本和快照的日期的对应关系。它显示了使用外部存储库组成的哪个快照来构建发行版的特定版本。
| 发布 | 组成 |
|---|---|
| 2.5.128、2.5.135、2.5.207 | 20200301 |
| 2.6.201、2.6.215、2.6.315 | 20200301 |
| 2.7.210、2.7.217、2.7.305 | 20200404 |
除了使用YYYYMMDD日期命名切片之外，我们还使用标签命名，格式为<ProjectName.ReleaseVersion>（产品的release_name.release_version，例如name.2.2）或<ProjectName-FeatureNumber>（添加功能编号，例如3）。
截至20200301的2.5的快照
deb http://repository.co/debian-stretch-projectname-2.5 stretch main contrib non-free # 20200301
因此，在版本2.5的开发过程中，团队修复了从20200301开始的从属存储库的组成。在四月的某个地方，该团队开始了新的2.6版本，并决定使用2.5外部存储库软件包的组成。从2.5快照创建一个新的2.6快照。将来，2.5和2.6版本的存储库可能会很容易分散。我们为2.6制作了自己的标签debian-stretch-projectname-2.6。
截至20200301的2.6快照
deb http://repository.co/debian-stretch-projectname-2.6 stretch main contrib non-free # 20200301
对于2.7版，团队可以从master分支开始开发-原始存储库的每日快照。
截至20200404的2.7快照
deb http://repository.co/debian-stretch-projectname-2.7 stretch main contrib non-free # 20200404
多产品依赖管理
让我们以具有不同发布周期的两个产品以及他们自己的产品团队为例来看看多产品依赖管理：Stealth和Infiniti。
让我们在桌子上评论发生的情况和时间。
| 产品 | 发布 | 组成 |
|---|---|---|
| 隐身2.2 | r2.2.124 | 20200301 |
| 隐身2.2 | r2.2.131，r2.2.162 | 20200305 |
| 英菲尼迪4.0 | r4.0.235，r4.0.241 | 20200303 |
| 英菲尼迪4.0 | r4.0.250 | 20200308 |
1.让Stealth项目的2.2版开发工作于2020年3月1日开始，为此，创建了当前日期包数据库组成的快照。版本2.2.124的发布是使用20200301的外部存储库的软件包基础进行的。Stealth
2.2
deb http://repository.co/debian-stretch-stealth-2.2 stretch main contrib non-free # 20200301
2.在第五天，软件包基础被更新。 debian-stretch-stealth-2.2工作存储库立即切换到所需的日期，使用来自20200305的外部存储库软件包发行了2.2.131和2.2.162版本。无需在环境中进行任何其他操作，该产品的所有100500微服务都会在组装管道中立即收到新的环境20200305。 ...
隐身2.2
deb http://repository.co/debian-stretch-stealth-2.2 stretch main contrib non-free # 20200305
3.在第三天的同时，开始开发Infiniti 4.0版项目，并为其创建日期为20200303的存储库组成的一部分，同时发布4.0.235和4.0.241版以及20200303的外部存储库软件包。Infiniti
4.0
deb http://repository.co/debian-stretch-infiniti-4.0 stretch main contrib non-free # 20200303
4.在发布4.0.241版之后，团队决定将存储库的构成更新为20200308，并发布具有新外部包构成的新版本。版本4.0.250与20200308的软件包捆绑在一起发布。Infiniti
4.0
deb http://repository.co/debian-stretch-infiniti-4.0 stretch main contrib non-free # 20200308
在存储库状态之间切换的两个选项使您可以选择一种对开发过程方便的方法。在第一种情况下，我们通过指定特定日期的存储库快照来切换到所需状态。在第二种情况下，对于多组分产品，我们使用命名切片并将其移至所需日期。该机制在所有100500个产品组件中提供了一次截止切换。
我们在单独的Docker容器中管理每个外部存储库的片段，因此在发生任何意外时，我们可以随时切换特定的存储库以从外部网络下载。
下载所有存储库的列表
# For example
curl repository.co/info/sources.list | grep $(lsb_release -cs) > /etc/apt/sources.list自动创建外部存储库片
根据GitLab调度程序，每晚都会更新存储库。添加新的存储库后，更改将自动应用于服务器。
提交外部存储库的新片时，将检查其证书，如果它与我们保存的证书不同，则不会进行更新，并且会收到错误消息。
结果
- 为发行版准备新版本的认证不再是一件令人头疼的事。在认证期内，我们会修复发行版本的组成，如果您需要立即进行修复，则很有可能由于环境的变化而导致发布的修补程序中没有错误。
- 所有功能部件都将获取外部存储库的托管状态。
- 修补程序推出和QA验证得到了加速，并获得了可预测，快速而成功的结果。
- Feature- , .
- .
请注意，Debian具有官方的snapshot.debian.org资源，其中包含每日快照和深度存储。对于某些任务，这已足够。
感谢Sergey Smirnov和社区提供了出色的工具来管理Aptly外部存储库的组成。来自我们-对在生产输送机中使用此有用工具的最佳实践的一小部分贡献。
在接下来的文章中，我们将讨论用于准备发行版ISO映像的Aptly + Simple-CDD捆绑包，将外部依赖项管理委派给产品团队，以及在管理外部依赖项过程中使用Aptly的问题。
作者：Nikita Drachev，Alexander Pazdnikov，Timur Gilmullin