私達 Developer Productivity室は弊社のプロダクトチームの開発生産性を向上するため、日々活動を行っています。CDツールであるPipeCDの開発もその一つに位置づけています。こうした活動は「開発生産性の向上」という大きな目標を達成するためです。今回はそのひとつである「開発生産性の可視化」を社内の複数組織に導入した話になります。
開発生産性指標
私たちは開発生産性を現在広く認知されている DevOps Research and Assessment（DORA）チームが実施した研究で発表された指標を追うこととしました。これはソフトウェア開発チームのパフォーマンスを示す 以下の4 つの指標のことを言い「Four keys」などと呼ばれたりもします。
| デプロイの頻度 | 本番環境へのデプロイの頻度 |
|---|---|
| 変更のリードタイム | コードの変更から本番環境へのデプロイまでの所要時間 |
| 変更障害率 | デプロイが原因で本番環境で障害が発生する割合 |
| サービス復元時間（MTTR） | 組織が本番環境での障害から回復するのにかかる時間 |
変更のリードタイム
「変更のリードタイム」に関しては指標をどのように定義するのか、さらに深く議論しました。
Gitでの開発を行っている場合は複数の計測方法が候補にあたると考えました。
| デプロイに含まれる変更の中の最初のコミット | 情報が落ちて、改善がしにくくなる |
|---|---|
| デプロイに含まれるPRの最初のコミットの中央値 | 最初のコミットのあと、PRが何らかの理由で一定期間放置された場合に、メトリクスが外れ値に引っ張られる。そういった組織的な問題も含めて計測したいときはよさそう。 |
| デプロイに含まれるすべてのコミットの中央値 | PRが何らかの理由で一定期間放置された場合に、メトリクスが外れ値に引っ張られるのを防ぐ。逆に異常値のパターンの発見がしにくくなり、その場合の改善につながらない可能性がある |
最終的にどの定義を採用するかは各組織に委ねることになりましたが、どの組織も2つ目 or 3つ目を選択しました。
可視化データパイプライン
実際に各プロダクトの開発生産性を可視化するデータパイプラインを説明します。Four keysを計測するためのパイプラインはGoogleからOSSとして公開しているGCP/fourkeysが存在します。私たちが実際にパイプラインを構築する際にもこのプロジェクトを参考にしており、かなり似た構成になっています。
GCP/fourkeysのパイプラインは各Github、CDツール、モニタリングサービスからデータソースデータを受け取り、PubSubを経由して、BigQueryのテーブルにデータがたまります。最後にデータをダッシュボードで表示します。
DP室の計測共通基盤とGCP/fourkeysとの相違点
DP室の計測共通基盤はGCP/fourkeysを参考に設計されていますが、社内の要望に答えるためいくつかの部分で異なっています。
- リポジトリ毎に1つのテーブルにデータを入れています。またWebhookのURLに
https://example.com?project=<project>というようなprojectパラメータを入れるのと、WebhookのデータからOrg, Repoを特定しています。 - アプリケーションリポジトリと構成管理リポジトリを分けている。構成管理リポジトリはプライベートリポジトリに設定していますが、アプリケーションリポジトリは会社全体で公開されています。これにより、コードの閲覧やPRを自由に作ってもらうようにしています。後述するダッシュボードに関してもアプリケーションリポジトリにDashboard as a Codeとしてコミットしており、各組織がダッシュボードの自分のページを自由にカスタマイズできるようになっています。
変更のリードタイム／デプロイの頻度の計測
GitHub Deployments APIでデプロイを計測をする手法を取っています。おおまかには以下の理由からです。
- 組織やチームごとに様々なデプロイ方法に対応する
- 汎用的な計測基盤にしたい
- GitHub自体に可視化の機能が充実した場合に移行しやすい
GitHub Deployments APIを叩く時に前回のデプロイから積み上がったコミット一覧を同時に送ることで変更のリードタイムを計測できるようにしています。Deploymentが作成された時点で Webhookをパイプラインに飛ばすようにしておきます。あとはパイプライン側でコミットIDを受け取り、計測に使用します。
計測を導入したすべてのプロダクトはGithubを使用して開発していますが、ブランチ戦略やマージする方法それぞれことなっています。例えば、あるチームはRebaseマージしたり、またあるチームはスカッシュマージしています。そのようなチームごとに異なる部分は各チームで対応をお願いしています。Developer Productivity室が計測導入にコンサルのような形で参加し、アドバイスや実際にコードを書いて導入支援を行うこともあります。
MTTR／変更失敗率の計測
プロダクトによって、計測方法が異なっています。あるプロダクトでは障害数のみ記録してデプロイ数を分母にする形を取っており、あるプロダクトではIssueに障害の原因となったコミットIDを指定する形で変更失敗率を計測しています。
その他にDatadogを使用しているチームにはDatadog Webhookに必要なデータがなかったため、インシデントリストのAPIを叩いてもらってそのデータを投げてもらうなど個別に対応しています。
CI/CD
次にCI/CDを説明します。Gitリポジトリは2つ用意されており、パイプラインのサーバーやダッシュボードのコードがあるfourkeysと、構成ファイルがあるfourkeys-configです。PRが作成されるとPipeCDのPlan Previewが動きマージした際の変更がPRにコメントとして通知されます。各コードの変更がmainブランチにプッシュされるとCDツールであるPipeCDによって自動でデプロイされます
ダッシュボード
ッシュボード
テーブルの複数選択ができないため、GCP/fourkeysのテーブルビューは使っていません。複数のOrgやプロジェクトをまたいだグラフを作りやすくしている。前述しましたが、ダッシュボードはDashboard as a Codeとしてコミットしており、各チームが自由にカスタマイズ可能になっています。
リポジトリの任意のグルーピング
ダッシュボードを使用しているある組織では数多くのチームが複数のGithub Organizationを管理しています。そのため、ダッシュボードで各指標を見る際、リポジトリ毎やOrganization毎にまとめるのではなく、任意のグルーピングが必要になりました。そのため、グルーピングを定義したGoogle sheetsを作成してもらい、Grafaraで使用しています。
より詳しくはスプレッドシートをBigQueryのテーブルに手動でロードして使用しています。スプレットシートをBigQueryから直接参照することもできますが、弊社のセキュリティー・ポリシーのためにワークアラウンド的な対応になっています
開発生産性を可視化してみて
指標の可視化を複数のプロジェクトで導入しましたが、各組織で開発手法が異なるために個別に対応する部分と共通化する部分の切り分けが難しいと感じました。可視化は開発生産性の向上という目標の第一歩になります。今回可視化を導入した組織では、グラフを分析することでチーム毎に各指標で違いが明確になりました。さらに少しずつですが、指標を監視しながらより高みを目指すための施策を試し初めています。今後の記事ではどのように開発生産性を向上させていっているのかをお伝えできればと思います！
