現代のソフトウェア開発、とりわけ新バージョンのリリース時には、同じアプリケーションを異なる構成でデプロイしなければならない場面が頻繁にあります。デプロイ先や関連する要因・要件によって、構成はアプリケーションの挙動そのものを左右します。たとえば、複数の地域への展開、新しいロケール、ユースケースの違いなどが挙げられます。
Developer’s Choice
**ソフトウェアの構成とは**
ここで「異なる構成」と言っても、ソフトウェアの大部分は共通で、ごく一部だけが異なるという点を押さえておくことが大切です。たとえば、小売チェーンを運営していて、レジ端末用のソフトウェアをデプロイするとしましょう。基本的にどのレジへのデプロイも中身はほぼ同じで、店舗の場所ごとにまったく別のソフトウェアを用意する必要はありません。もちろん、状況によってはそうしたケースもあり得ます。
構成の話に戻りましょう。先ほどの小売向けレジアプリケーションの例で続けます。アプリケーションを動かす各レジには固有の識別子が必要で、これが構成にあたります。国ごとに既定の言語を切り替える必要があるかもしれません。これもまた構成です。さらに、開発者には独自の「開発環境」が必要で、ここでも構成が少しずつ異なります。しかし、いずれの場合もソフトウェア本体は同じです。だいたいイメージしていただけたかと思います。
私たちはすでに、ソフトウェアのソースコードの変更履歴をすべてバージョン管理で保管しています。場合によっては、ソースコードをさまざまなバイナリ成果物、アーカイブ、Docker コンテナへとコンパイルする仕組みを備えていることもあります。理由はシンプルで、適切な「バージョン」のソフトウェアをより効率的に配布するためです。
切り離してこそ、高度化と最適化が進む
配布されたソフトウェア資産は、実行される環境の構成と噛み合う必要があります。通常、構成はさまざまなレベルに関わる複数の要素から成り、階層構造を伴います。構成をアプリケーションに渡す方法はいくつもあります。環境変数を介する方法、構成データを格納した所定のファイルを読み込む方法、ハードコードされた、あるいは別の方法で「構成された」API 呼び出しの応答として受け取る方法などです。
ポイントは、構成は動的であり、時間とともに変化するということです。もちろん、構成をすべてひとまとめにし、毎回アプリケーションと一緒に「あらゆる場所」にデプロイすることもできます。しかし、それは無駄が多く、もっと最適化できる(そして最適化すべき)作業です。アプリケーション本体とは別のリズムで構成データをデプロイ・リリースすることで、これは実現できます。
これこそが最適化の核心です。つまり、バージョン管理と構成データの管理を、アプリケーションコードから切り離すということです。 この分離は、構成専用のバージョン管理の場所を設け、構成変更のデプロイ・リリースに専用のプロセスを用意することで、より効果的に機能します。アプリケーションのデプロイとは切り離し、独自のリズムで運用するプロセスにするのです。
みなさんはどう思われますか?
お読みいただきありがとうございました。最新情報は DoiT Engineering Blog、DoiT LinkedIn チャンネル、DoiT Twitter チャンネル でご覧いただけます。採用情報については、 https://careers.doit-intl.com をご覧ください。