3

私が取り組んでいるプロジェクトでは、継続的な展開のセットアップを行っています。目標は、誰かがこの機能を手動でオーバーライドしない限り、常に最新の作業ビルドを本番環境にインストールすることです。

これを機能させるために、

  1. 静的コード分析を実行する
  2. 単体テストを実行する
  3. 統合テストを実行する
  4. 可能な範囲で自動 UI テストを実行する

上記の手順のいずれかが失敗した場合、ビルド プロセスは停止し、ビルドは失敗としてマークされます。インストール パッケージが作成されている場合は、次の手順でインストールされます。

CI --> ステージング --> プロダクション

各ステップで、環境の統合と UI テストを実行して、後続の環境で失敗する新しいものを導入していないことを確認します。どのテストも失敗せず、誰もパニック ボタンを押さずに N 分が経過すると、ビルドは次の環境に昇格します。テストが失敗した場合は、パッケージを削除して完全に破棄します。ただし、インストール パッケージは他のサーバーに配信されるため、この手順を実行するには、一連のリモート (シェル) スクリプトを実行する必要があります。

問題は、通常の自動化されたサイクルでは確実にテストできない多くの失敗ケースがあることです。たとえば、ページ レイアウトや、一部の統合が本番環境でのみ失敗するなどです。

したがって、実際の質問:ビルドが昇格されたら、どのように降格/削除すればよいですか? ビルドを削除するときにリモート スクリプトを実行するか、プロモーション プラグインを使用してこの機能を実現することはできますか? 私が考えていなかったかもしれない、これに対する独創的な解決策はありますか？

4

3 に答える 3

1

ビルドを手動で削除する代わりに、ビルド番号をパラメーターとして受け入れ、それを削除してから、残りのハウスキーピングを実行するJenkinsジョブを作成することもできます。Jenkinsのアクセス権限を設定して、ユーザーが誤ってビルドを手動で削除しないようにすることができます。

于 2012-04-30T10:51:52.617 に答える
1

これは非常に特殊なケースかもしれませんが、特定のビルド番号に関連するすべてのログを 1 つの場所に保持するという非常に単純な理由から、ビルドを削除するための別のジョブを作成しないことにしました。セットアップは次のとおりでした。

ここでの昇格とは、特定のサーバーでインストール パッケージ (RPM) を利用できるようにすることを意味し、自動更新によってパッケージの実際のアップグレードが処理されます。

新しいコミットが利用可能になるたびにビルドされるメインビルドが 1 つあります。静かな時間などに関連する微調整がいくつかありましたが、基本的には、コミットの新しいプッシュ セットごとに新しいビルドが作成されました。ビルドには、関連する利用可能なすべてのテストが含まれていますが、完全にはほど遠いものであり、おそらく完成することはありません。

1 時間ごとに、個別の昇格ステップがステージングから実動への昇格を処理します。このビルドは、承認された最新のビルドを CI からステージングに移行する別のプロモーションを開始します。最後の 2 秒間のコミットで誤って昇格するのを防ぐために、ビルドが CI からステージングに昇格するまでに 30 分の遅延があります。一部の bash find スクリプトで遅延が発生しました。プロモーションの順序は次のとおりです。これは、ビルドがプロモーションに行く前に (少なくとも) 1 時間ステージングで利用可能であることを確認するためです。

実際の答え: 昇格の手順は個別のビルドとして行われました。個別のログを使用して個別のビルドを作成するのではなく、実際のプロモーションを行うために、ビルドはメイン ビルドで実際のプロモーションを開始し、curl を使用してリモート HTTP APIを呼び出します。これにより、関連するプロモーション スターがメインのビルド ログに残ります。異なる色を使用することで、キャンペーンは一目でわかります。

ビルドを降格するために、別の「ビルドの降格」プロモーション ステップを作成することにしました。これにより、ビルドに欠陥があることを示す紫色の星が表示され、削除されます。降格は、UI で正しいビルドにアクセスし、[ビルドの削除] ボタンを押すことによって行われます。このステップには自動化が追加されていませんが、別のテスト ステップを作成することで、降格も簡単に自動化できます。しかし、私たちはまだそこまで到達していません。

このアプローチの利点は次のとおりです。

  • ビルドは、パラメーターを指定することによってではなく、失敗したビルドにアクセスすることによって削除されます。文書化がはるかに簡単になり、プレッシャーにさらされます
  • このような「パニック ボタン」を誰でも押すことができるようにすることで、開発者だけでなくマネージャーや DevOps の間でもプロセスに対する信頼と所有権が築かれます。
  • ログは他のプロモーション ログに加えて利用できるため、デッド ビルドを見つけるのは非常に簡単です。
  • 関連するすべてのプロモーション呼び出しを同じビルドに含めると、さらにスクリプトを作成しやすくなります

まだ改善しなければならない深刻な問題には、ビルド パイプラインの後の段階でのテストの自動化と、降格後にビルドをダウングレードする適切な方法が含まれます。たとえば、本番環境では、欠陥のあるビルドと降格は、常に最後の正常なビルドのインストールにつながる必要がありますが、これを達成するのはかなり難しいことが判明しています。CI システムが配置されている開発 DC からこのレベルにアクセスできる運用データセンターはほとんど許可されていません。また、ビルド パイプラインの停止と開始は自動化する必要があります。そうしないと、手動の状態に戻る可能性があります。

当然のことながら、継続的な改善の精神では、常に改善すべき点があります。セットアップ全体は、bash/perl スクリプトの混乱のようなものですが、スクリプト化されており、反復可能であるため、一度に 1 つの小さな部分を改善するオプションが常にあります。最も重要なことは自動化です。これにより、手動のステップでは多かれ少なかれ防止される段階的なステップが可能になります。

于 2012-04-30T20:24:22.547 に答える