如何跟踪损坏的发布版本

53次阅读

问题描述

在进行金丝雀发布时，遇到了一个问题：如果发现某个发布版本存在问题，如何标记该版本为损坏版本，并且应尽快从生产环境中删除，不再部署到其他地方？

用户提出了几种解决方案的想法：
1. 使用GitLab，在标记的发布说明中添加**broken**，部署任务将调用GitLab API来确保要部署的标记未被标记为损坏。
2. 在代码库中创建一个文本文件，列出损坏的标记。在部署任务中，检查要部署的标记是否未列在该文件中。
3. 不保存有关发布问题的信息：只需部署一个新的稳定、修复的版本到生产环境中，然后不再关注。

用户想知道如何处理这个问题，并希望得到一些建议或相关链接。

解决方案

请注意以下操作注意版本差异及修改前做好备份。

方案1

对于常规发布，可以发布一个新版本并添加一个新的标记。
对于LTS/稳定版本，可以删除指向有问题的发布的标记，或者更改标记指向的提交。

方案2

另一种方法是使用一些工具来解决这个问题。你可以使用docker run命令手动控制容器的启动顺序，或者使用一些第三方工具来管理容器的依赖关系。

方案3

你可以使用一些第三方工具来解决这个问题。例如，Reliza Hub是一个可以解决这个问题的产品。你可以将所有发布的详细信息发送到Reliza Hub，并使用客户端根据标记、批准等条件选择需要的发布版本。对于损坏的发布，你可以不批准它们或将它们标记为“REJECTED”，这将阻止它们在你的流水线中传播。

方案4

你可以区分“发布”和“发布候选版本”。如果你确实将软件版本发布给其他人使用，并且该版本“完全损坏”，那么肯定出了很大的问题。为了避免这种情况，开源项目通常会有里程碑发布和快照发布（也称为“夜间发布”或“最新发布”）。这些发布通过预发布的公共测试来排除关键故障。一旦不再有完全损坏的风险，软件就会被标记为最终发布。之后，如果存在错误（通常总会有错误），则可以通过发布说明发布警告和有关旧版本的信息。

请注意，如果你不是将软件发布给其他人运行，而是自己运行软件作为服务，那么你的第三种方案可能很有效：不保存有关发布问题的信息，只需部署一个新的稳定、修复的版本到生产环境中，然后不再关注。

此外，你的Git服务器可能具有“最新发布功能”。GitHub和GitHub Enterprise都有这个功能。即使通过构建流水线发布到某个构件存储库，将发布在Git服务器中也可能很有帮助，这样对GET /repos/:owner/:repo/releases/latest API的调用将返回最新版本的详细信息，包括应与发布版本匹配的git标记。然后，你的部署流水线可以从构件存储库中拉取相应的预构建代码进行部署。

以上是几种处理损坏发布版本的解决方案，你可以根据自己的需求选择适合的方法。希望对你有所帮助！