有没有人试过运行虚拟作业的测试实例来测试新版本，还是只是祈祷升级版本不会破坏任何内容？
#1 楼
根据我工作所在公司的政策，我们拥有开发人员，预生产环境和生产环境（某些服务上的开发人员可能会丢失）。以及新版本preprod-> tests-> validation-> prod的路径。在我们的案例中，preprod中的工作非常繁琐，足以确保在prod中实现时我们无需祈祷： ）
注意：我们使用svn维护和交付配置。我们不会就地进行更改。
评论
您如何维护不同Jenkins服务器的配置？手动吗？
–迈克尔·佩雷拉（Michael Pereira）
17-2-28在17:26
我们使用svn维护和交付配置。我们不会就地进行更改
–罗密欧·尼诺夫（Romeo Ninov）
17-2-28在17:27
我觉得这还不能完全回答问题。此答案描述了如何部署更改，但没有描述如何通过部署管道测试更改。
– Jayhendren
18年2月19日在20:12
#2 楼
我们需要一个100％HA Jenkins环境。我们通常会升级插件/ Jenkins本身。如果升级后版本中断，这会造成很大的麻烦。
最安全的排序方式实际上是获得Demo Jenkins设置。也许在同一台使用多个Tomcat应用程序的计算机上，您可以实现这种便宜。
我们所做的是创建一个单独的（Demo）VM，并在Demo VM上复制了产品设置。在更改/升级任何东西之前，我们将对两个虚拟机进行快照。然后，我们将在演示VM上测试升级。如果效果良好，请在Prod上进行更改。
如果有人对您计划的插件有任何问题，我想您可以查找社区（例如SE / SO）。
#3 楼
我总是会在使用各自插件的每个相关项目/分支上，至少在最近的一个绿色标签（或几乎绿色标签）上手动触发一两次重新运行，并检查是否得到相同的结果。只是为了安全起见。任何结果差异都需要进行调查以确定它们是否由插件更新引起。也许新旧插件都可以重新运行？
评论
好没问题。
–丹·科尼莱斯库（Dan Cornilescu）
17年3月15日在20:08
从过去的经验来看，我的意见通常并不那么受欢迎，因此总的来说，如果可能的话，我倾向于避免引起人们的注意：)我也不熟悉mod工具。但我不介意提供帮助，尤其是在需要时-我对该网站寄予厚望。
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 16 '17 at 0:04
评论
您是说让金斯的团队政策还是您（组织的）政策？在升级之前，我将对Jenkins节点进行快照，然后对其进行测试。根据我的经验，詹金斯从来都不是关键任务组件。如果由于某个插件升级使它“故障”了15分钟，则通常不会以任何方式阻止生产，因此可以接受手动干预。当然，如果不是您这种情况（并且Jenkins必须为100％HA），那不是正确的方法。
@DanCornilescu我的组织政策，因为这是针对我们内部Jenkins服务器的
@AssafLavie这在很大程度上取决于Jenkins的运行方式：独立服务器，VM，docker容器，kubernetes pod（我们的情况）。拍摄当前状态的快照以按原样还原可能并不容易。在我们的案例中，我们可以克隆保存Jenkins数据的EBS卷，但这是将容器和数据卷都恢复到特定状态的手动且耗时的过程。
嗨，@ MichaelPereira，如果以下两个答案中的任何一个都解决了您的问题，请考虑通过选中对勾来接受它。这向更广泛的社区表明您已经找到了解决方案，并为答题者和您自己赢得了一定声誉。没有义务这样做。如果您不满意，请随时与作者联系。