ソフトウェア開発と CI/CD の文脈において、構成管理とは、変更が導入されたタイミングを特定できるように、特定のインフラストラクチャ環境の詳細の記録を指します。
CI/CD パイプラインには、リリース前にソフトウェアをテストしてステージングするための環境がいくつかあります。 パイプラインとテストが効果的に動作するには、本番前の環境でできる限り緊密に本番が再現されており、テストランごとに一貫している必要があります。
これを実現させるには、これらの環境をホストする一連の物理的なマシンまたは仮想マシンをセットアップすることができます。 ただし、時間の経過とともに、特定の課題をトラブルシューティングするためにパッチが適用されたり、新しいパッケージがインストールされたり、ネットワーク設定が変更されたりすると、これらのサーバーは元の構成からは多様に離れ始めてしまいます。
こうなれば、スノーフレークサーバーが次々と生まれてしまいます。 さらには、変更の詳細がどこにも記録されていなければ、 サーバーが失敗した場合、またはテスト操作をスケーリングするために再現が必要となった場合に、同じ環境を再作成することがより困難になってしまいます。 構成管理はこの問題を解決することを目的としています。
バージョン管理システムで構成の詳細を保管しておけば、変更をわかりやすくなり、何らかのエラーが発生した場合にその変更を元に戻し、同じ変更を他のマシンにも適用して一貫性を維持することがより簡単になります。
これらの構成の詳細が YAML や XML ファイルなどの構造化されたフォーマットで保管されている場合は、構成管理をさらに高いレベルに引き上げて、サーバーの構成を自動化することができます。
変更がバージョン管理にコミットされると、これらの変更は関連する環境に自動的に適用されます。
Infrastructure as Code の手法を取ることで、仮想マシンの取り壊しと再作成を自動的に行えるようになります。CI/CD パイプラインをセットアップして、デプロイ間で環境をリフレッシュすることができるのです。 こうすれば、テスト量が多くなっても大量のマシンの操作が可能になり、環境を簡単に再作成できるようになります。
ソフトウェアのデプロイにコンテナーを使用している場合は、ソフトウェアの依存関係といった一部の構成要素はそのコンテナーイメージに移動します。 ただし、そのコンテナーをホストしているサーバーを構成しなければならないことには変わりません。 それでも、こういった環境の作成をコード化して自動化することのメリットはたくさんあります。