0

アプリケーションの 1 つで、展開プロセスを自動化しようとしています。このアプリケーションには、エンド ツー エンドの継続的インテグレーション (ビルド/テスト/パッケージ/レポート) が実装されています。現在、自動展開を実装しようとしています。このアプリケーションは、2000 台のサーバーと各サーバーの 50 台のクライアントにデプロイする必要があります。一部のコンポーネントはサーバーにインストールされ、一部はクライアントにインストールされます。
CI に使用されるツール: Jenkins、Github、msbuild、nunit、specflow、wix。

継続的デリバリーと継続的デプロイの違いを読み、継続的デリバリーはコード/変更がいつでも有効になることが証明されていることを意味し、継続的デプロイは証明されたコード/変更が本番サーバーに自動的にデプロイされることを意味することを理解しました。

ネット上のほとんどの記事では、サーバーの 1 つ (DEV/Staging/Preproduction/Production) への継続的な配信/展開の展開部分を自動化する方法について説明しています。多数のサーバーとクライアントにアプリケーションをデプロイする方法については、どの記事も触れていません。

ここで私の質問は次のとおりです。1) 2000 以上のサーバーとクライアントへのアプリケーションの展開は、継続的な展開の一部ですか、それとも CI/CD から処理する必要がありますか? 2) CI/CD 内で処理できる場合、Jenkins 配信パイプラインでこれをモデル化し、CI ツールからすべてのサーバーの展開をトリガーするにはどうすればよいですか? 3) CI ツールと統合して展開を自動化できるツールはありますか?

ありがとう

4

2 に答える 2

0
  1. 継続的デプロイの重要な要件 (IMHO) はプロセス オーケストレーションです。jenkins はこのための理想的なツールではありませんが、独自の groovy スクリプト ラッパーを作成するか、別のオーケストレーション ツールからジョブをリモートで呼び出すことができます。ジェンキンスのもう 1 つの問題は、少なくとも私にとっては、進行状況を追跡するのが難しいことです。

  2. 次のようにモデル化します。

    • 展開プロセスを論理レベル (データ センター -> アプリケーション -> プールなど) に分割し、各レベルのラッパーを作成します。メインラッパーで最高レベルの進行状況を確認し、必要に応じてドリルダウンすることができます。
    • すべてのラッパーは、すべてのダウンストリーム ジョブがである場合にSUCCESSのみ終了する必要があります。それ以外の場合は、またはです。この場合、低レベルのジョブで何かを見逃す可能性はありません。SUCCESSFULUNSTABLEFAILURE
    • 製品/アプリケーション/パッケージごとに 1 ジョブにつき 1 ジョブ
    • 1 つのシーケンス実行を制御する 1 つのジョブ。たとえば、mcollectiveを使用して、選択したサーバーでインストール ジョブを順次/並列に実行します。
    • 論理レベルごとに 1 つのラッパー ジョブ

  3. 私は使うだろう：

    • mcollective - 上記のように
    • 職長puppetは、シーケンス実行ごとにサーバーリストを選択するようにクエリします
    • サーバー上のパッケージ/アプリケーション/アーティファクトのインストールは、サーバーなどのネイティブ OS ソフトウェアで行うことを好みyumますlinux。インストール検証のメカニズムに頼ることができます

私は何かを逃したと確信していますが、それがあなたに受け入れられる出発点になることを願っています

于 2015-05-25T21:14:02.583 に答える