私が働いているショップでは、継続的インテグレーションに jenkins を使用し、そのプロモートされたビルド プラグインを使用してビルド アーティファクトをデプロイしています。ただし、構成の数が増えるにつれて、このセットアップの管理に問題が生じています。だから私の質問は：
可能なすべての組み合わせを手動でスクリプト化することなく、さまざまな構成でさまざまな成果物を展開できる便利な CI システムをセットアップするにはどうすればよいですか?
詳細:
Aビルド構成 (つまり、ブランチ)とがあるBとしましょうC。3 つのデプロイメント ターゲットIとがJありKます (たとえば、さまざまなクライアントまたはコンシューマーの場合)。最後に、デプロイされた各インスタンスにはX、さまざまなサービス (Web サイト、バックグラウンド タスク、データ サービスなど) がありますY。Z通常、さまざまなサービスが一緒に宣伝されます。しかし、特に修正プログラムを公開するために、そうでない場合もあります。
現在、これらの組み合わせごとにプロモーションを行っています。したがって、典型的なビルドをインストールするには、 Promotions を実行し、 config で実行する必要がJ/Xあります。サービスの数は残念ながら増加しており、これらすべての構成をジェンキンでエラーを発生させずに取得し、さらに展開時にコンポーネントを忘れたり混同したりしないようにすることは難しくなっています。そしてもちろん、3 つ以上のビルド構成と 3 つ以上のターゲットがあるため、すべて手に負えなくなります。J/YJ/ZC
うまくいかないいくつかのオプション:
さまざまなコンポーネントを無効にするためのパラメーター化されたプロモーション。Jenkins ではパラメーター化されたプロモーションが可能ですが、値は最初にプロモーションするときに固定されます。いくつかのパラメーターをプロモートして設定するだけで自由度を取り除くことができました
Jが、新しいバージョンが壊れた場合、壊れたコンポーネントだけをロールバックすることはできず、デプロイ全体をロールバックする必要があります。依存するパラメータ化されたビルド。Jenkins は依存するビルドを選択するパラメーターをサポートしていないようです。オプションを手動でコーディングすると、もちろん「実行」選択パラメーターは機能しません。
私が本当に欲しいもの：
ビルドが展開の準備ができているとして手動で受け入れられた後、どのターゲットの引数とどのコンポーネントの引数を含めて、そのようにマークする必要があります。
インストール履歴は、ビルドごとではなく、コンポーネントごと、ターゲットごとに記録されます。