開発から製品への構成の変更を効果的に追跡

この質問では、例としてSpring Bootサービスを取り上げていますが、これはどのようなテクノロジーでもかまいません。

次のように仮定します。

• 環境（dev / QA / prod）は異なるチームによって所有されています。これは、開発者が製品構成にアクセスできないようにする必要があることを意味します。
• 構成（application.propertiesとしましょう）は外部化されています。つまり、バイナリの一部ではありません。
• 同じバイナリ/パッケージ（service.jarとしましょう）が各環境にデプロイされ、自動デプロイメントによって制御されます

バイナリアーティファクト（service.jar）への変更は自動的に各環境に伝達されますが、構成への変更には依然として手動による介入が必要であり、必然的に各環境で非同期化されます。

たとえば、開発チームが環境内のapplication.propertiesにいくつかのキーと値のペアを追加するとします。これらの新しいキーを記録する最良の方法は何ですか？それで、運用チームで展開が行われるときに、追加するキーが正確にわかっているため、新しいサービスを開始し、キーが見つからないために失敗することを確認するリスクが最小限に抑えられますか？

手動の手順が含まれることはわかっていますが、人々がこれをどのように処理し、最も効果的な方法を見つけるか知りたいです。

これは主に通信の問題ですが、いくつかの単純な技術的および組織的対策により、エラーを少なくすることができます。最初に、構成ファイルのすべてのエントリの適切で高品質なドキュメントと、簡単にアクセスできる例または「デフォルト」構成ファイルを提供する必要があります。サンプルファイルは、prodチームが直接変更することを目的としていないため、各環境に自動的にデプロイできます。

次に、新しいリリースごとに、重要な変更が文書化されている変更ログを提供します。欠落しているときにシステムが機能しなくなる可能性のある構成の変更は常に重要であるため、情報がそこにあることを確認してください。

たとえば、開発チームが環境のapplication.propertiesにいくつかのキーと値のペアを追加するとします。これらの新しいキーを記録する最良の方法は何ですか？そうすることで、展開がopsチームで発生したときに、追加するキーが正確にわかるため、新しいサービスを開始して、キーが見つからないために失敗するというリスクが最小限に抑えられますか？

失敗のリスクを減らす最善の方法は、新しいキーを必要とする方法でアプリケーションを変更しないようにすることです。そのため、アプリケーションは可能な限り古い構成ファイルと下位互換性を保つ必要があります。多くの場合、アプリケーションは、新しいキーが欠落している場合に備えて、組み込みのデフォルト値を提供することにより、適切な方法で動作できます。

ただし、それが不可能な場合は、システムにより、prodチームがキーが欠落しているときに新しいサービスの開始に失敗する理由をできるだけ簡単に見つけられるようにする必要があります。どのファイルにどのキーが欠落しているか、必要に応じて欠落しているキーに関する情報の場所、またはこのキーの意味のあるエントリに関するヒントまたは例を示す明確なエラーメッセージが表示されます。

構成が複雑で、手動編集でエラーが発生しやすい方法でフォーマットが変更される場合は、構成を編集して新しいバージョンに移行するためのツールを提供することも検討してください。

たとえば、Firefox Webブラウザーを使用していて、新しいリリース（自動的に取得される）ごとに、「about：config」ページで検査できるローカル構成に特定のものが追加されます。これは、「実稼働」環境の構成に相当します。構成全体が完全に下位互換性を維持しているため、ブラウザーの新しいリリースがあるという理由だけで、手動で構成に新しいキーを追加する必要はありません。そして、そこで何かを変更したい場合（おそらく、以前のバージョンの一部ではなかった新しいエントリ）、[ツール]メニューの[オプション]または[about：config]ページを使用して、エントリに加えて一種のドキュメント。だから私はあなたのシステムを同等の方法で実装しようとすることを勧めます。

私がかつて働いたある場所で、彼らは同様の問題を抱えていました。プロダクション構成はビルドチームによって制御され、コードリポジトリ内の構成のみにアクセスできました。dev、qa、testなどの構成は、誰でも見ることができます。

あなたの例では、開発者はファイルをローカルで更新し、ソース管理にチェックインし、次に誰かがビルドチームに、構成ファイルをチェックアウトしてデプロイしたが、再コンパイルもデプロイもしない新しい「構成のみ」のビルドを要求するでしょうアプリケーション全体を再デプロイします。

他の環境の構成ファイルを適切なタイミングで更新するのはチームメンバーの責任でした。本番用に更新するとき、ビルドチームは、開発チームリーダーからの明示的な要求を介してファイルを更新する必要がありましたが、通常、要求は単に「app.configファイルをQA1からPRODにコピーする」のように見えました。パスワードなどの機密性の高いものは別の構成ファイルに含まれており、ビルドチームのみが本番パスワードファイルにアクセスできました。違いは、開発者は通常、やったということでしたではありません本番パスワードがなかったため、パスワードファイルの変更をリクエストします。ビルドチームに更新を依頼するのは、新しいサービスに新しいパスワードを追加するときだけでした。それでも、開発者はおそらくプロダクションパスワードを知らないでしょう。ファイルに追加するキー（ "newService2.password"など）しか知りません。

これの多くを管理するために使用された技術はジェンキンスでした。Jenkinsを介してビルドをリクエストおよびスケジュールするために使用される社内ツールもありました。