SpotifyのプロダクトマネージャのMaria Jernström氏とJason Palmerが、開発チームの迅速なオペレーションと連携を可能にする方法について説明した。同社のPlatform Developer Experienceトライブ(tribe)はCI/CDツール、プロダクション開発用ツール、共通プロセスの自動化に重点を置いた既定手順(paved path)を構築する部隊である。
SpotifyではDevOpsモデルを採用しており、それぞれのチームが自身の機能を所有し、エンドツーエンドで責任を持っている。このようなチームは高度な自律性を持つ一方、"ツールセットやエンジニアリングプラクティスのフラグメントが発生する"、とJernström、Palmer両氏は指摘する。同社プロジェクトマネージャのGary Niemen氏は、このフラグメントが"風評駆動(rumour-driven)開発"、すなわち"何かを行う方法を知る唯一の手段が同僚に尋ねることだという状況を作り上げている、と指摘する。
フラグメントを低減する手段としてPlatform Developer Experience (PDX)トライブは、Golden Pathsという、一連のツールとプロセスを開発した。Golden Pathsは、クライアント開発、データサイエンス、マシンラーニングなど、エンジニアリングプロジェクトのタイプによって整理されたベストプラクティスのセットを提供する。Niemen氏のことばを借りれば、氏らは"'プロダクト構築'を'独断的に支援'するパス(path)"を提供しているのだ。これらのパスは、Spotifyの開発者ポータルであるBackstage内にホストされている。
Netflixの"Paved Road(舗装道路)"のコンセプトと同様に、Golden Pathsが提供するのは、プロジェクトに必須のスケルトンを足場にすることで標準化されたエクスペリエンスである。それぞれのパスには、この作業のベストプラクティスを説明した資料が添付されている。パスで使用するツールには、Backstage経由でアクセスする。
このような一貫性の重視は、Auto Trader UKでデリバリプラットフォームリーダを務めるKarl Stoney氏が説明する、Auto Traderが自社の開発チームで実現しているものとも一致する。実装の一貫性は必要不可欠だ、とStoney氏は強調する。このために同社のプラットフォームチームは、KubernetesやIstioといったツール上のプラットフォーム・アズ・ア・サービス(PaaS)を実装することを通じて、プラットフォームとは分離した、抽象的なプロダクトチームとなっている。このアプローチの結果として同社では、すべてのサービスのメトリクスやトレースを、一貫した方法で簡単に取得することができる。Stoney氏が言うように、"統一された可観測性のあるデータによって、プラットフォームレベルのツーリングが簡単に構築可能になることは、すべての人たちにとってメリットがあります。自動化によって関連情報を照合し、MTRを削減することができるのです。"
Golden Pathsを構築する際にNiemen氏が強調したのは、対象者の明確な定義と統一化された目標の必要性である。Spotifyでは、新規採用されたエンジニアを対象者として選択した。新規採用者のすべてが導入教育の一環としてGolden Pathsをレビューし、チュートリアルを受けることで、大量のフィードバックを収集することができる。対象者のニーズを満たすため、Golden Pathsは、パスを完遂するために必要なすべてのステップを含む、ステップ・バイ・ステップ形式のガイドになっている。Niemen氏の言うように、"Golden Pathはシステム構築を独断的に支援するパスであると同時に、このパスを巡るためのチュートリアルでもある"のだ。
パスがワークフロー全体を表現するものであるため、パスの資料が長大過ぎる、というフィードバックを受けることも多いのだが、Niemen氏は、資料ではなく実際のパスを短くするべきだ、と考えている。プロセスを部分的に自動化すれば、ステップ・バイ・ステップの資料を短くすると同時に、パスの全体的な成果を維持することが可能になる。
まずGolden Pathsを書き出した上で、ツールの開発や自動化によってパスを短くする、という手順を取ることで、Spotifyのプラットフォームチームは、自分たちが開発するコンポーネントの有益性を担保している。Two Sigmaでプラットフォームエンジニアリングの責任者を務めるマネージングディレクタのCamille Fournier氏も、InfoQとのインタビューで、これと同じことをアドバイスしている。Fournier氏が強調するのは、"開発のために開発するソフトウェア"に投資しないことの重要性だ。"プラットフォームチームが開発それ自体を目的とした場合、特に複雑な最終目標を、中間段階をほとんど置かずに達成するという壮大な目標を掲げている場合には、困惑とオーバーエンジニアリングの入り混じった、誰からも愛されないプロダクトに終わることになります。"
事前定義したパスを最適化する方法であれば、チームはユーザからのフィードバックを活用して、最も時間を要している部分を最初に自動化することが可能になる。同時にこれは、プラットフォームチームが提供可能なプロダクトを重視する、ということでもある。"自分たちが何を開発したのか、何を開発しているのか、それらのプロダクトがエンジニアリングチーム全体をより効率的にできる理由は何か、などを語ることのできるチームこそが、優れたプラットフォームチームです"、とFournier氏は述べている。
Spotifyはチームに対して、必要に応じてパスから外れる余地を認めており、チームの運用方法にフィットするツールやメソッドを選択することを推奨している。その場合でもPDXトライブによる開発の恩恵を引き続き受けられるように、活用するサービスには選択肢を設けている。ゼロコンフィギュレーションを体験したいのであれば、Backstageのテンプレートを直接使用することも可能だ。ある程度の設定を必要とするチームに対しては、独自のCI/CDパイプラインがサポートされている。最後に、構築済のテンプレートを使わずにプラットフォームを構築したいチームに対しては、同社のCI/CDツールであるTingleのAPIが公開されている。
PDXトライブの行った開発に関する詳しい情報を望むならば、Spotifyエンジニアリングブログで確認することができる。