すべてを一度に構築しようとしてはいけない理由
チームがCI/CDについて話し始めるとき、最初に思い浮かぶのは大規模な変革です。すべてのアプリケーションにパイプラインが必要です。データベースは自動化しなければなりません。インフラはコードとして宣言する必要があります。すべての環境が同一でなければなりません。そして、すべてを同時に完了しなければならないのです。
そのイメージは圧倒的であり、当然そうあるべきです。なぜなら、すべてを一度にやろうとすると、最も起こりやすい結果は変革ではなく、混乱だからです。
一度に変更しなければならないことを考えてみてください。開発者がコードを送信する方法、データベースチームがスキーママイグレーションを処理する方法、インフラがサーバーをプロビジョニングする方法、QAがテストを実行する方法、リリースマネージャーがデプロイを承認する方法、そして全員が何が変更されたかを追跡する方法。これらすべてが、既存のアプリケーションがユーザーにサービスを提供し続けている間に行われます。
これはビッグバン変革と呼ばれます。名前は記念碑的に聞こえますが、実際にはたいていビッグバン失敗で終わります。一度にあまりにも多くのことが変わります。あまりにも多くの変数が制御不能になります。そして、何かが壊れたとき、すべてが新しいため、誰もどこを見ればよいかわかりません。
段階的なアプローチは派手さに欠けますが、はるかに現実的です。すべてを一度に変更する代わりに、成功の可能性が最も高い部分を1つ選び、それを完了し、そこから学び、次の部分に進みます。
これら2つの道の違いは、並べて見ると明らかです。
段階的アプローチがビッグバンより優れている理由
すべてのチームには異なる出発点があります。あるチームは本番環境でアプリケーションを実行しているが、まだ手動でデプロイしているかもしれません。別のチームはアプリケーションのパイプラインを持っているが、データベースにはSSHで直接サーバーに接続して管理しているかもしれません。3つ目のチームはインフラを自動化しているが、アプリケーションの自動テストを一度も書いたことがないかもしれません。
すべてのチームに適合する単一の設計図はありません。他人の設計図をそのままコピーしようとすると、たいてい痛みを伴う調整で終わります。段階的アプローチは、チームの実際の出発点を尊重します。他人が考えるべき場所からではなく、今いる場所から構築できるようにします。
段階的アプローチは、学ぶ余地も与えてくれます。各ステップは実際の経験を生み出します。パイプラインがチームのコードベースでどのように動作するか、データベースが自動マイグレーションにどのように反応するか、インフラが設定変更にどのように応答するか。その経験は、あらゆるツールのドキュメントや理論よりも価値があります。なぜなら、それは自分たち自身のコンテキストから直接得られるからです。
リスクも、ステップバイステップで進むもう1つの理由です。1つの部分だけが変更され、何か問題が発生した場合、どこを見ればよいか正確にわかります。すべてが一度に変更された場合、問題はどこからでも発生する可能性があります。チームは影響を修正する代わりに、原因の追跡に時間を費やすことになります。
最後に、段階的な変更は人々が受け入れやすいものです。大きな変革は、人々が慣れ親しんだワークフローに慣れているため、抵抗を生み出します。しかし、変更が小さなステップで行われる場合、各ステップはより軽く感じられます。チームは結果を目にし、メリットを実感し、次のステップに対してよりオープンになります。
最初のステップの見つけ方
最も難しいのは、どこから始めるかを決めることです。多くのチームは、行動を起こす前にロードマップ全体を計画しようとするため、ここで行き詰まります。それは間違いです。完全な地図は必要ありません。価値を提供する明確な1つのステップが必要です。
まず、現在のデリバリープロセスを見てください。最も問題が多い部分、または最も時間がかかる部分を見つけてください。それが通常、最初のステップの良い候補です。
以下は、一般的な出発点の例です。
- 本番環境へのデプロイに何時間もかかる手動チェックリストが必要な場合、重要でない1つのサービスのデプロイを自動化することから始めてください。
- データベースの変更が手作業で適用され、しばしば本番インシデントを引き起こす場合、リスクの低いデータベースのスキーママイグレーションを自動化することから始めてください。
- チームがすべてのリリースを手動でテストするのに何日も費やしている場合、最も重要なユーザーフローの自動テストを書くことから始めてください。
- インフラの変更が数週間かかるチケットリクエストを通じて行われている場合、1つのインフラコンポーネントをコードとして宣言することから始めてください。
重要なのは、妥当な時間で完了できるほど小さく、かつチームが改善を実感できるほど意味のあるものを選ぶことです。
典型的な段階的ロードマップの例
段階的ロードマップは、すべてのステップを事前に計画することを意味しません。方向性を把握し、一度に1つのステップを踏むことを意味します。
典型的な順序は次のようになります。
- 1つのアプリケーションのビルドとデプロイを自動化する。他のすべては手動のままにする。
- そのアプリケーションの最も重要なパスに自動テストを追加する。
- パイプラインを拡張して、そのアプリケーションのデータベースマイグレーションを含める。
- 学んだことに基づいて調整しながら、同じパターンを2つ目のアプリケーションに適用する。
- インフラプロビジョニングを徐々にパイプラインに移行する。
- モニタリングとロールバック機能を追加する。
- 残りのアプリケーションに拡張する。
各ステップが前のステップの上に構築されていることに注目してください。手動デプロイからいきなり完全なインフラ自動化に飛躍するのではありません。各ステップが次のステップに情報を提供するようにします。
最初のステップのための実用的チェックリスト
始める前に、この簡単なチェックリストを確認してください。
- リスクが低く、重要でないアプリケーションまたはサービスを1つ特定できますか？
- このステップの「完了」の定義は明確ですか？
- このステップを担当し、最後までやり遂げられるチームメンバーはいますか？
- これが恒久的なプロセス変更ではなく、実験であることをチームに伝えましたか？
- 何か問題が発生した場合にロールバックする方法はありますか？
これらの質問に「はい」と答えられるなら、始める準備はできています。そうでない場合は、まずこれらの点を明確にするために時間を費やしてください。
まとめ
すべてを一度に変革する必要はありません。チームが見て、触れて、学べる、機能する1つのステップが必要です。そこから始めてください。発見したことから次のステップを生み出してください。段階的に学ぶチームは、持続可能なプラクティスを構築します。すべてを一度に変えようとするチームは、たいていゼロから再構築することになります。