Jenkinsプラグインを展開する前に、どのように変更をテストしますか？

いくつかの機能を壊したプラグインのアップグレードにかまれたことがあるなら、この問題について考えたことがあるに違いありません。Jenkinsプラグインのアップグレードポリシーはどうあるべきでしょうか？変更を展開する前にどのようにテストしますか？

新しいバージョンをテストするためにダミージョブを実行するテストインスタンスを持っている人はいますか、バージョンをアップグレードしても何も壊れないことを祈っていますか？

私が働いている会社のポリシーによると、dev、preprod、およびprod環境があります（一部のサービスdevが欠落している場合があります）。そして、新しいバージョンのパスpreprod-> tests-> validation-> prod。

私たちの場合、preprodの仕事は、prodに実装するときに祈る必要がないことを確実にするほど重く、複雑です:)

注：svnを使用して構成を維持および配信します。その場で変更を加えることはありません。

100％HA Jenkins環境が必要でした。プラグイン/ Jenkins自体を頻繁にアップグレードします。

アップグレード後にビルドが壊れると、これは大きな頭痛の種になります。

これをソートする最も安全な方法は、実際にデモジェンキンスのセットアップを取得することです。複数のTomcatアプリケーションを使用している同じマシン上で、おそらくこれをより安く実現できます。

行ったのは、別の（デモ）VMを作成し、デモVMにprodセットアップを複製したことです。変更またはアップグレードする前に、両方のVMのスナップショットを作成します。次に、デモVMでアップグレードをテストします。うまく機能する場合は、Prodで変更します。

計画しているプラ​​グインで問題が発生した場合は、SE / SOなどのコミュニティを検索できます。

それぞれのプラグインを使用するすべての関連プロジェクト/ブランチで、少なくとも1つの最近の緑（またはほぼ緑）のラベルで再実行または2つを常に手動でトリガーし、同じ結果が得られることを確認します。念のために。

結果の不一致は、プラグインの更新によるものかどうかを判断するために調査する必要があります。古いプラグインと新しいプラグインの両方でさらに数回再実行される可能性がありますか？