1

アーティファクトのライフ サイクルを管理するためのビルド パイプラインがあります。パイプラインは 4 つの段階で構成されます。

1.commit (ユニット/取り込みテストの実行)
2.at (アーティファクトを at 環境にデプロイし、自動化された受け入れテストを実行します)
3.uat (成果物を uat 環境にデプロイし、手動受け入れテストを実行します)
4.pt (pt 環境にデプロイしてパフォーマンス テストを実行)
5.//TODO 本番環境をサポートしようとしています。

パイプラインは環境変数をサポートしているため、オプションでトリガーすることにより、さまざまな構成でアーティファクトをデプロイできます。問題は、構成項目が多すぎて、展開スクリプトに含まれる置換タスクが多すぎることです。

集中型の構成管理システム (短い名前の ccm) を構築するという考えがあるので、そこに構成アイテムを維持し、デプロイ スクリプトに url (ccm に接続) 置換タスク (さまざまな段階を処理する) のみを残すことができます。したがって、アーティファクトは構成値を保持せず、ccm に要求します。

これは実現可能ですか、それともそもそも悪い考えですか?

私の懸念は、構成キー (アーティファクトで定義) と値 (ccm で設定) の間の潜在的な不一致が、このソリューションでは解決されず、さらに悪化する可能性があることです。

4

1 に答える 1

2

構成ファイルは、プロジェクトに残すか、実行する構成変数として設定する必要があります。この背後にある理由は、アーキテクチャに新しい障害点を追加しているためです。構成サーバーがダウンして、それに依存するすべてのものを破壊する可能性があることを考慮する必要があります。
このような状況に身を置くことはお勧めしません。

プロジェクトに定義された環境変数の長いリストを持っていても問題はありません。それは、あなたが物事を適切に行っていることを意味することさえあります.

何らかの理由で構成ファイルを頻繁に変更している場合 (例: データベース接続文字列、API ednpoints など)、多くの構成を変更する必要があることが問題である可能性があります。

于 2013-07-08T08:48:19.687 に答える