なぜ開発者自身にデプロイパイプラインを構築させるべきではないのか

新しい社内開発者ポータルを構築しました。一般的なサービス種別向けのゴールデンパステンプレートも作成しました。開発者は数クリックで新しいマイクロサービスを立ち上げられます。しかし、その後彼らは真っ白なCI/CD設定ファイルを前にしてこう言います。「さて、どうすればいいんだ？」

これこそが、多くのプラットフォームイニシアチブがつまずく瞬間です。ただ機能を追加したいだけの開発者が、突然CI/CDエンジニアになります。コードのビルド方法、テストの実行方法、ステージングへのデプロイ方法、本番リリースの扱い方、ロールバックの仕組みの設定方法をすべて自分で考えなければなりません。これらの作業は、本来彼らが届けたい機能とはまったく関係ありません。

セルフビルドパイプラインの問題点

各チームが独自のパイプラインを構築すると、断片化が発生します。チームAはチームBとは異なるビルド戦略を使います。チームCはセキュリティスキャンを実施していますが、チームDはその存在すら知りません。共有ライブラリで脆弱性が発見された場合、プラットフォームチームは各チームを個別に追いかけてパイプラインを修正してもらわなければなりません。

より深い問題は認知負荷です。開発者が下さなければならないパイプラインの判断はすべて、ユーザーを理解したり、ビジネスロジックを書いたり、バグを修正したりする時間を奪います。単純な内部APIをリリースするためだけに、開発者がローリングアップデートとブルーグリーンデプロイの違いを知る必要はないはずです。

マネージドパイプラインの実際の姿

マネージドパイプラインとは、事前に構築され、テストされ、標準化された一連のステージであり、プラットフォーム上のすべてのサービスが使用します。開発者がポータルからサービステンプレートを選択すると、パイプラインはすでに組み込まれています。すべてが含まれています。

次の図は、断片化されたDIYアプローチと統合されたマネージドパイプラインを対比しています。

• コードチェックアウトと依存関係のインストール
• ユニットテストと統合テスト
• セキュリティと脆弱性スキャン
• ビルドとアーティファクトの作成
• ステージング環境へのデプロイ
• 本番環境への承認ゲート
• 適切な戦略による本番デプロイ
• 障害発生時の自動ロールバック

マネージドパイプラインとチーム構築のパイプラインの重要な違いは一貫性です。すべてのサービスが同じチェックを通過します。すべてのビルドが同じツールを使用します。すべてのデプロイがそのサービス種別に対して同じ戦略に従います。プラットフォームチームがパイプラインのセキュリティ問題を修正すると、すべてのサービスが自動的にその修正を受け取ります。

頭痛の種なしのセルフサービスデプロイ

マネージドパイプラインは、さらに価値のあるものを可能にします。それはセルフサービスデプロイです。開発者はプラットフォームチームや運用チームを介さずに、自分たちのサービスをデプロイできます。コードを理解していない人からの承認を待つ必要もありません。

セルフサービスは無謀を意味しません。プラットフォームがサービス種別に基づいてデプロイ戦略を制御します。開発者はデプロイをトリガーするだけで、パイプラインが残りを処理します。何か問題が発生した場合、パイプラインが障害を検出して自動的にロールバックします。

これはチームの運用方法における根本的な変化です。「今夜誰かが私のコードをデプロイしてくれる必要がある」と言う代わりに、開発者は「コードをプッシュしたらパイプラインが処理してくれた」と言います。プラットフォームチームはボトルネックからイネーブラーへと変わります。

サービス種別に合わせたデプロイ戦略

すべてのサービスに同じデプロイ戦略が必要なわけではありません。マネージドプラットフォームは、各サービスカテゴリに適した戦略をエンコードする必要があります。

内部ツールや低リスクサービスは、recreate戦略を使用できます。古いインスタンスを停止し、新しいものを起動します。シンプルで高速であり、数秒のダウンタイムが問題にならないサービスに適しています。

顧客向けAPIやWebサービスは、ローリングアップデートまたはブルーグリーンデプロイを使用する必要があります。新しいインスタンスが徐々に起動し、トラフィックがゆっくりと移行し、エラー率が急上昇した場合、デプロイは停止して自動的にロールバックします。

ステートフルサービスとデータベースは、最も慎重な取り扱いが必要です。変更前の自動バックアップ、段階的なロールアウト、手動承認ゲート。一部のチームでは、アプリケーションデプロイの前に、データベースマイグレーションを独立した観測可能なステップとして実行することを要求しています。

開発者はこれらの戦略を選択しません。プラットフォームがサービステンプレートに基づいて割り当てます。チームが異なる戦略を必要とする場合、プラットフォームチームにリクエストし、プラットフォームチームがリスクを評価して全員のテンプレートを更新します。

マネージドパイプラインが可能にすること

パイプラインが中央で管理されると、断片化されたセットアップでは達成が難しいいくつかのことが可能になります。

スケールするセキュリティ。 1つのセキュリティスキャン設定がすべてのパイプラインに適用されます。1つの脆弱性修正がすべてのサービスにデプロイされます。チームに「新しいスキャナーを含めるようにパイプラインを更新してください」と依頼する必要はもうありません。

デフォルトの可観測性。 すべてのデプロイが同じメトリクス、ログ、トレースを出力します。プラットフォームチームは、すべてのサービスにわたるデプロイ健全性を示すダッシュボードを構築できます。デプロイが問題を引き起こした場合、シグナルは明確で即時的です。

実際に機能する監査証跡。 すべてのデプロイが同じ構造で記録されます。誰が、何を、いつ、どの承認でデプロイしたか。コンプライアンスチームは、異なるパイプライン形式を解析することなく、一貫したデータを取得できます。

より高速なオンボーディング。 新しいチームメンバーはCI/CDツールを学ぶ必要がありません。プラットフォームのパターンを一度学べば、組織内の任意のサービスをデプロイできます。

プラットフォームチームの継続的な役割

マネージドパイプラインは、設定して終わりではありません。プラットフォームチームは、パイプラインがどのように使用されているか、開発者がどこで行き詰まっているか、どの戦略が異なるサービス種別に最適かを監視する必要があります。パイプラインテンプレートは、組織が何が機能するかを学ぶにつれて進化する必要があります。

しかし、中核となる原則は変わりません。プラットフォームはテスト済みのパスを提供し、開発者はそれに従います。開発者が標準パスの外で何かを行う必要がある場合、それはプラットフォームチームにとってパスを拡張する必要があるというシグナルであり、各チームに独自のパイプラインを構築させる理由にはなりません。

マネージドパイプラインの実践的チェックリスト

プラットフォームチームを構築している場合、または現在のアプローチを評価している場合、ここに簡単なチェックリストがあります。

• 開発者はパイプライン設定を一切書かずに新しいサービスをデプロイできますか？
• すべてのサービスが同じセキュリティスキャン設定を使用していますか？
• デプロイ戦略はサービス種別によって割り当てられ、個々のチームが選択するものではありませんか？
• 失敗したデプロイは手動介入なしに自動的にロールバックしますか？
• プラットフォームチームはパイプラインロジックを一度更新するだけで、すべてのサービスに適用できますか？
• 開発者はプラットフォームチームの承認なしにセルフサービスでデプロイできますか？

成功の本当の尺度

マネージドパイプラインとセルフサービスデプロイの目標は、開発者を制御することではありません。コードを書くことと価値を届けることの間の摩擦を取り除くことです。開発者がコードをプッシュし、パイプラインが残りを処理してくれると信頼できるとき、あなたは実際に機能するプラットフォームを構築したことになります。

その代替案は、すべてのチームがデプロイを再発明し、すべてのパイプラインに独自の癖があり、プラットフォームチームが改善ではなく火消しに日々を費やす世界です。それはプラットフォームエンジニアリングではありません。それは単なる組織化されたカオスです。