问Jenkins升级和插件排序

EN

我只能从个人经验中发言，而不是最佳实践，但在我们公司，我们将复制jenkins实例，然后对其进行升级。我们先做主要的升级，然后再进行插件，然后运行测试，以确保我们的核心工作仍然有效。如果一切顺利，我们会在下班时间升级真正的詹金斯。

我们有90+作业，所以测试它们都是不现实的--我们努力找出了8到10个作业，这些作业跨越了我们90%的用例，并运行在站在jenkins上的作业，以确定一切都是健康的。

如果您在生产场景中使用jenkins，我强烈建议您做类似的事情。您永远不知道什么可能会中断-我们有一次升级，一个bug在10分钟内产生了150+ aws ec2实例，而不是真正需要的3 jenkins .另一次，我们对代码库的所有单元和e2e测试都失败了，因为结果是其中一个输出解析器插件升级到与我们的输出格式不兼容。我们甚至已经让Bitbucket集成变得糟糕，不再在每一次推动下就开始工作。

有时候，所有插件的升级都会造成混乱--我们曾经有过这样一种情况，即某些插件出现故障，并且很难找到原因，因为它可能来自两个不同的插件中的一个。最后，我们又推出了两个jenkins插件，并对其中一个插件进行了升级，以确定是哪个插件造成的。不过，通常情况下，一次升级就会很快显示出它的缺陷，只需进行一点测试。

不管你做了什么决定，先做个后援！

我从詹金斯那里学到了很多经验，这是我一直坚持的命令，它为我节省了很多时间：

1. 升级Jenkins本身(如果需要的话)
2. 升级Auth插件(即Github org auth)
3. 升级与最重要的管道/项目相关的插件(ssh-agent，ansible，k8s，docker，不管你们正在使用什么)
4. 升级当前使用的，但不是关键任务插件(蓝色海洋等)
5. 升级其他插件

我有“升级后”管道，将开始建设少数几个最重要的项目，它是运行后的每一步。

对我也有很大帮助的是在升级之间拍摄快照，这样我就可以轻松地进行回滚，而不是从一开始就开始，这可能很费时。显然，我不建议做就地升级，我总是去1:1拷贝和工作的副本，然后我只是改变DNS记录。