正しい方法が、最も簡単な方法でもある
新しい開発者がチームに加わりました。他のチームが依存するサービスを構築する必要があります。機能コードを一行も書く前に、彼らは多くの決断に直面します。どの言語とフレームワークを使うか、リポジトリをどう構成するか、ビルドとテストのパイプラインはどうあるべきか、ステージングと本番へのデプロイ方法、監視とロギングの設定はどうするか。それぞれの決断に時間がかかります。間違った選択をすれば、技術的負債やセキュリティホールが生まれます。開発者は、ビジネス価値を提供する前に、セットアップに数日から数週間を費やします。
この状況は、すべてのチーム、新しいサービス、プロジェクトのキックオフで繰り返されます。組織は、同じことを行うための、微妙に異なる方法を何十も蓄積していきます。それぞれのバリエーションは、メンテナンスの負担を増やし、チーム間を移動する開発者の認知負荷を高め、セキュリティと運用の死角を作り出します。
無限の選択肢という問題
すべてのチームが独自にインフラとパイプラインの決定を行うと、組織は隠れたコストを支払うことになります。各チームは車輪の再発明をしますが、そのやり方は微妙に異なります。あるチームは異なるCIツールの設定を使い、別のチームは異なるロギングライブラリを選び、さらに別のチームは独自の方法でデプロイスクリプトを構成します。これらの選択は個々には間違っていませんが、集合的に断片化を引き起こします。
運用チームは、サービスごとにメトリクスの公開方法が異なるため、監視を標準化できません。セキュリティチームは、パイプラインごとに承認ゲートが異なるため、一貫したポリシーを適用できません。共通の依存関係に重大な脆弱性が発見された場合、それを更新するための単一の場所はありません。修正は、独立して管理されている数十のセットアップにわたって適用する必要があります。
さらに悪いことに、新しい開発者は貢献する前に分析麻痺に陥ります。インフラストラクチャの決定を行うための認知オーバーヘッドが、実際のプロダクト作業から注意をそらします。チームは機能ではなく、配管工事にエネルギーを費やします。
ゴールデンパス：一本道ではなく、舗装された道
ゴールデンパスのコンセプトは、アプリケーションの構築、テスト、デプロイのための標準的で十分にテストされたルートを提供することで、この問題を解決します。これは、硬直した万能の解決策ではありません。それは、何が機能するかについて組織が蓄積した知識を捉えた、厳選されたテンプレートとプラクティスのセットです。
プラットフォームチームがすでに難しい決断を下していると想像してください。彼らは、サポートされる言語、推奨されるフレームワーク、標準的なリポジトリ構造、CI/CDパイプライン構成、監視統合、ロギング設定を選択しています。彼らはこれらの選択を複数のサービスと環境にわたってテストしています。彼らは、各決定の背後にあるトレードオフと理由を文書化しています。
開発者が新しいサービスを作成する必要がある場合、アーキテクチャパターンに一致するゴールデンパステンプレートを選択します。REST APIマイクロサービス用のテンプレート、バックグラウンドジョブプロセッサ用のテンプレート、フロントエンドアプリケーション用のテンプレート、内部ライブラリ用のテンプレートがあるかもしれません。各テンプレートには、開発者がすぐに機能コードの記述を開始するために必要なすべてが含まれています。正しい構造のリポジトリ、完全に構成されたパイプライン、開発環境とステージング環境の設定、監視ツールとロギングツールとの統合です。
開発者は、アイデアから実行中のコードまで、数日ではなく数分で到達します。プラットフォームチームは、テンプレートがセキュリティ基準を満たし、運用のベストプラクティスに従い、残りのインフラストラクチャとスムーズに統合されることをすでに検証しています。
ゴールデンパスが機能する理由
ゴールデンパスが効果的なのは、静的な成果物ではないからです。プラットフォームチームは、プロダクトチームからの実際の経験やテクノロジーの変化に基づいて、テンプレートを継続的に更新します。依存関係にセキュリティの脆弱性が見つかった場合、プラットフォームチームはゴールデンパステンプレートを更新します。新しいサービスはすべて自動的に修正を取得します。ゴールデンパスに従う既存のサービスは、体系的に更新できます。
デプロイプラクティスがより信頼性が高いことが証明された場合、プラットフォームチームはそれをゴールデンパスに組み込みます。すべての新しいサービスは、各チームが独立して発見する必要なく、改善の恩恵を受けます。ゴールデンパスは、組織全体にベストプラクティスを広めるための媒体となります。
ゴールデンパスはガードレールとしても機能します。開発者はそこから逸脱することもできますが、明確な理由が必要であり、通常は追加の承認が必要です。これは創造性を制限することではありません。逸脱が意図的であり、正当化されることを確実にすることです。チームが特定の技術的理由で本当に異なるアプローチを必要とする場合、彼らは別の道を進むことができます。しかし、彼らはトレードオフを理解し、カスタムセットアップを維持するための追加の責任を受け入れなければなりません。
実際には、ほとんどの開発者は、ゼロからすべてを構築するよりも本当に簡単で速いため、ゴールデンパスに従うことを選択します。組織にとって正しい道は、個々の開発者にとっても最も簡単な道なのです。
ゴールデンパス実装のための実践的チェックリスト
組織でゴールデンパスの採用を検討している場合、以下が実践的な出発点です。
- 組織内で最も一般的なアプリケーションパターンを特定する（REST API、バックグラウンドジョブ、フロントエンド、ライブラリ）
- 各パターンについて、セキュリティ、運用、開発に関する現在のベストプラクティスを文書化する
- それらのプラクティスを、完全なパイプラインを備えた動作するリポジトリにエンコードするテンプレートを作成する
- 広く展開する前に、実際のチームでテンプレートをテストする
- フィードバックと変化する要件に基づいてテンプレートを維持および更新するプラットフォームチームを割り当てる
- 逸脱を要求し、レビューするための明確なプロセスを確立する
- ゴールデンパスを使用するチームとゼロから構築するチームの、採用率と初回デプロイまでの時間を測定する
正しい方法が簡単な方法になる
ゴールデンパスがうまく機能すると、好循環が生まれます。プラットフォームチームは標準パスをより良くするために投資します。プロダクトチームは時間を節約しリスクを減らすためにそれを採用します。プラットフォームチームはプロダクトチームの経験から学び、パスをさらに改善します。セキュリティチームと運用チームはサービス全体で一貫性を得ます。開発者はユーザーにとって重要な機能の構築に集中できます。
ゴールデンパスはすべての選択肢を排除するわけではありません。毎回再作成する必要のない選択肢を排除します。組織の知識を捉え、すべてのチームがそれを再発見する必要がないようにします。正しい方法を簡単な方法にし、簡単な方法を正しい方法にします。
あなたの次の新しいサービスは、数週間ではなく数時間以内に本番環境で実行できるかもしれません。唯一の疑問は、あなたがすでに道を舗装したかどうかです。