CI/CDロードマップを計画する前に、まずは棚卸しをしよう

チームでCI/CD導入の計画を話し合うとき、誰かが「最も重要なアプリケーションから始めよう」と言い出す。別の誰かは「一番問題が多いデプロイプロセスを直したい」と主張する。さらに別のメンバーは「新しいパイプラインをゼロから構築すべきだ」と提案する。どの意見にも一理あるが、チームが実際に何を抱えているのかを正確に把握している人は誰もいない。

ここが、多くのCI/CDロードマップが失敗するポイントだ。現状を理解せずに決断から始めてしまう。何が存在するのかを知らなければ、何を変えるべきかの優先順位はつけられない。最初のステップは計画ではない。最初のステップは棚卸しだ。

何をカタログ化すべきか

棚卸しは管理的な作業に聞こえるかもしれないが、その後のあらゆる決断の基盤となる。これなしでは、どの変更が最も重要かは推測でしか判断できない。棚卸しをすれば、パターン、ギャップ、依存関係が見えてくる。これらは、進捗を妨げるまで表面化しないことが多い。

アプリケーション

まず、チームが管理するすべてのアプリケーションから始める。ほとんど変更されないもの、誰も話題にしない内部ツール、誰もが避けているレガシーシステムも含める。各アプリケーションについて、以下を記録する。

• プログラミング言語とフレームワーク
• ソースコードの保存場所（リポジトリ、ブランチ戦略）
• 現在のビルドプロセス（手動コマンド、スクリプト、既存の自動化）
• そのアプリケーションを最もよく知っている人

最後のポイントは見た目以上に重要だ。特定のアプリケーションのパイプラインを変更し始めると、そのアプリケーションの癖を理解している人が必要になる。その人があなたの主要なリソースだ。その人がいなければ、物事を壊すような仮定をしてしまうだろう。

データベース

多くのチームは、データベースがデリバリープロセスの一部であることを忘れている。アプリケーションコードを処理してもデータベースの変更を無視するCI/CDパイプラインは、本番環境でマイグレーションが実行された瞬間に失敗する。アプリケーションに接続されている各データベースについて、以下を記録する。

• データベースの種類とバージョン
• スキーマ変更の現在の管理方法（手動スクリプト、マイグレーションツール、何もなし）
• データベース変更を担当する人、およびマイグレーションが失敗した場合の対応者
• データベース変更が本番環境に到達する前にテストされているかどうか

データベースの変更は、アプリケーションコードの変更とは異なるリスクを伴う。デプロイの失敗は多くの場合すぐにロールバックできるが、マイグレーションの失敗はデータを破損したり、復旧に何時間もかかる可能性がある。データベース環境を把握することで、どの程度の自動化とテストを適用すべきかを判断できる。

インフラストラクチャ

アプリケーションとデータベースはどこかで動作している。すべてのコンポーネントについて、その「どこか」を記録する。

• 物理サーバー、仮想マシン、クラウドサービスのいずれか
• 環境の作成方法と設定方法
• 設定が文書化されているか、手動のSSHセッションで管理されているか
• 本番環境へのアクセス権を持つ人
• 通常、インフラストラクチャの問題を処理する人

手動で管理されているインフラストラクチャは、導入できる自動化の範囲を制限する。すべてのサーバーが独自の設定を持つスノーフレーク状態であれば、パイプラインはそれらのいずれにも確実にデプロイできない。棚卸しによって、インフラストラクチャのどの部分が自動化に対応可能で、どの部分を先に整理する必要があるかが明らかになる。

既存のパイプライン

チームには、不完全であっても、すでに何らかの自動化が導入されているかもしれない。存在するものを文書化する。

• どのアプリケーションに自動化されたビルド、テスト、またはデプロイプロセスがあるか
• 各パイプラインが実際に何をしているか（ビルドのみ、ビルドとテスト、完全なデプロイ）
• 何が欠けているか（セキュリティスキャンなし、データベースマイグレーションなし、手動承認ステップ）
• 既存のパイプラインの信頼性（頻繁な障害、不安定なテスト、長い実行時間）

既存のパイプラインは、不完全だからといって役に立たないわけではない。それらは、チームがすでに解決したことと、ギャップがどこにあるかを示している。ビルドとテストは行うがデプロイは手動のパイプラインは、次にどこに焦点を当てるべきかを教えてくれる。

所有権

すべてのコンポーネントには所有者が必要だ。各アプリケーション、データベース、インフラストラクチャの責任者を記録する。所有権が重要なのは、パイプラインの変更には調整が必要だからだ。他のチームが所有するアプリケーションのパイプラインを、そのチームを巻き込まずに変更することはできない。データベース変更を処理する人と話さずに、データベースマイグレーションの実行方法を変更することはできない。

また、変更について決定を下せる人も記録する。コンポーネントを維持している人が、その変更を承認する人とは限らない。決定の連鎖を把握しておくことで、後々の遅延を防げる。

棚卸しの進め方

完璧を目指してはいけない。不完全でも大まかな棚卸しの方が、部分的で洗練されたものよりも優れている。チームが使いやすいツール（スプレッドシート、共有ドキュメント、デジタルホワイトボード）を使えばよい。形式よりも内容が重要だ。

以下のフローチャートは、推奨される棚卸しプロセスを示している。

まずは知っていることから始める。明白なエントリを先に埋め、その後チームメンバーに確認と担当領域の入力を依頼する。全員で棚卸しをレビューする短いミーティングを設定する。これにより、忘れられていたコンポーネントや、想定されていたが確認されていなかった依存関係が明らかになることが多い。

ギャップが見つかることを想定しておく。明確な所有者がいないアプリケーションもあるだろう。文書化されていないマイグレーションプロセスを持つデータベースもあるだろう。誰も覚えていない認証情報で動作しているインフラストラクチャもあるだろう。これらのギャップは失敗ではない。次のステップを計画するために必要な情報そのものだ。

棚卸しで明らかになること

棚卸しが完了すると、パターンが見えてくる。あるチームは成熟したパイプラインを持っている一方で、別のチームはまだ手動デプロイを行っているかもしれない。データベースの変更は慎重に扱われているが、インフラストラクチャのプロビジョニングは混沌としているかもしれない。最も重要なアプリケーションに最も自動化が進んでいないことが判明するかもしれない。

これらのパターンは、どこから始めるべきかを教えてくれる。成熟したパイプラインを持つチームはモデルとして機能する。手動デプロイだが所有権が明確なアプリケーションは、自動化の良い候補だ。すでにマイグレーションスクリプトがあるデータベースは、一度もバージョン管理されたことのないデータベースよりもパイプラインに統合しやすい。

棚卸しはまた、無視できない依存関係も明らかにする。マイグレーションプロセスのないデータベースに依存するアプリケーションは、データベース側が対処されるまで完全に自動化できない。手動で設定されたインフラストラクチャ上で動作するアプリケーションは、パイプラインが確実にデプロイできるようになる前に、インフラストラクチャの変更が必要になる。

実践的なチェックリスト

棚卸しの取り組みをガイドするために、このチェックリストを使用する。

• チームが管理するすべてのアプリケーションをリストアップする（内部ツールやレガシーシステムを含む）
• 各アプリケーションについて、言語、リポジトリ、ビルドプロセス、主要な連絡先を記録する
• それらのアプリケーションに接続されているすべてのデータベースをリストアップする
• 各データベースについて、種類、バージョン、マイグレーションプロセス、責任者を記録する
• 各アプリケーションとデータベースがどこで動作しているか（サーバー、VM、クラウド）を文書化する
• 環境がどのように作成され、設定されているかを記録する
• 既存のパイプラインを文書化する：何をしているか、何が欠けているか、信頼性はどうか
• すべてのコンポーネントの所有権を記録する
• 各コンポーネントの変更を承認できる人を特定する

具体的な takeaways

棚卸しは官僚的な作業ではない。CI/CDの改善を計画する前に行う、最も有用な作業だ。自分たちが何を持っているかを正確に把握しているチームは、推測ではなく事実に基づいて決断できる。棚卸しをスキップしたチームは、実装の途中で次々と驚きを発見し続けることになる。そして、それらの驚きは時間、信頼、勢いを損なう。

自分たちがすでに所有しているものを把握することからロードマップを始めよう。棚卸しの中のパターンが、次にどこへ進むべきかを教えてくれる。