CI/CD Conference 2023、DMMのエンジニアが解説するCIを加速するトランクベースの開発とは

CI/CDに特化したカンファレンスCI/CD Conference 2023から、合同会社DMM.comのエンジニアが解説するCIパイプラインを加速するトランクベースの開発手法改善に関するセッションを紹介する。「トランクベース開発の実現に向けた開発プロセスとCIパイプラインの継続的改善」というタイトルのセッションでは、CIのプロセスを改善することでソフトウェア変更のリードタイムを短縮する手法について解説。DMMのチーム内で実践したトランクベースのCIパイプラインについてビルド、テスト、レビューなどのプロセスをどう組み立てるべきか？ について、例を挙げて説明している。プレゼンテーションを行ったのはDMM.comの認証許可に関するソフトウェアを開発するチームのリーダーである小林杏理氏だ。

●動画：トランクベース開発の実現に向けた開発プロセスとCIパイプラインの継続的改善

●資料：トランクベース開発の実現に向けた開発プロセスとCIパイプラインの継続的改善

プレゼンテーションを行う小林氏

前半はGitをベースにしたバージョン管理の基本を説明した。GoogleのDevOps Research and Assesment（DORA）の定義から引用し、ソフトウェア開発チームのパフォーマンスを測定する4つの指標を挙げる。

• デプロイ速度
• 変更のリードタイム
• 変更障害率
• サービス復元時間

上述の指標の中から「変更のリードタイム」を短縮することで、全体の処理時間を改善する内容となっている。

要件定義からPRのマージまでをサイクルタイムとして、ここを短縮するのが目標

一般的にソフトウェアの変更（機能追加や修正）についてはソースコードのメインブランチに対して複数の枝分かれ（フィーチャーブランチ）が発生し、それぞれが開発を行い、最終的にメインブランチにマージされることで並行的に開発が進むが、ここでの問題点はメインから枝分かれした時点以降で別のエンジニアが機能追加のためにブランチを実行することで、最終的なソフトウェアにおいてコンフリクトが発生してしまうことを説明。

メインブランチに対してさまざまなブランチが発生し、最終的にマージされる

ブランチAがマージされる前に別のブランチが発生することでメインブランチで衝突が起こる

この状況が発生してしまう要因として「フィーチャーブランチのサイズが大きい（機能追加要件が大きい）」ことと「コーディングが完了してもそれがレビューされ、マージされるまでの時間差が大きい」ことであると説明。

衝突が起こってしまう要因は「機能の大きさ」と「レビューからマージまでの時間の長さ」

その上で、フィーチャーブランチを使わないでメインブランチに直接修正をコミットする手法、トランクベース開発を説明した。

トランクベース開発を解説。直接、コードをメインブランチにコミットする

ここでは本来、実装しなければいけない機能ができあがっていないのにコミットが行われてしまう可能性について言及し、それを防ぐための手法、フィーチャーフラグについて簡単な説明を行った。

フィーチャーブランチを使わないトランクベース開発のまとめ

ただし実際にこの手法を小林氏のチームで検証したところ、「フィーチャーブランチを使わずに開発を行うのは難しい」という判断に至ったという。その理由についてはコミットと同時にコードレビューを行うことが難しいこと、CIのチェック（単体テストなど）を実行せずにコミットして良いかを判断できないことなどを挙げた。

フィーチャーブランチを使わない開発は難しいことを説明

ここからはフィーチャーブランチを使う開発手法、特にフィーチャーブランチが存在する期間を極端に短くすることでフィーチャーの肥大化を防ぎ、プルリクエストによるレビューを可能にするShort-lived Feature Branch（短期間だけ存在するフィーチャーブランチ）による開発を紹介した。

Short-lived Feature Branchの紹介

Short-lived Feature Branchは「数日以内にマージすること」「メインブランチ以外にマージしない」「開発者以外はコミットしない」などのルールを挙げて、短期間でマージまでを終わらせるための工夫を紹介した。

Short-lived Feature Branchのルールを紹介

これによってプルリクエストによってレビューが行えること、CIパイプラインによってマージ前のコードチェックが可能になることなどの利点を挙げた。

ここからはDMM内部での事例としてGitHubをソースコード管理として使い、Goを使ってコードを記述、実行環境はKubernetes、CIはGitHub Actions、CDはArgoCDというプラットフォームについて紹介した上で、トランクベース開発の背景を説明した。マイクロサービス化に向かって、開発チームの中から認証許可チームが最初に実証実験の場となったことを説明した。

開発着手から1日以内にメインブランチにマージするためのプルリクエストを作成すること

ここで短期間でフィーチャーブランチを終了するために、開発着手から1日以内にプルリクエストを作成、レビューはプルリクエストを作成後、2日以内にマージし、フィーチャーブランチを削除するというルールが紹介された。

コードレビューはコミットとは非同期で実施

マージまでの時間がかかってしまうことの大きな要因であったコードレビューについては「非同期で行うこと」「24時間以内に実施すること」「自動化された単体テストやLintによる文法チェック」などが実施されたことを説明し、レビュワーそのものが少人数であるにも関わらず、短期間でのレビューとマージを目指していることを強調した。

コードの変更がどのようにマージされているのかを可視化するCode Climate Velocityについて簡単に紹介した上で、1日以内のプルリクエスト作成、2日以内にマージが守れなかった場合の振り返りのための反省シートを紹介。毎週のチームミーティングで確認を行うというプロセスを導入し、開発サイクル短縮化を継続したと説明した。

反省シートを作ってルールが守れない要因を分析。「頑張りや注意が足りない」は禁句に

実際にこの開発手法を取ってからの成果についても簡単に紹介されており、平均サイクルタイムが全社平均は68.8時間となっているのに対し、認証許可チームは約11時間であることから、着実に成果が現れていると説明。

サイクルタイムの比較を実施。確実に認証許可チームの時間は短縮されている

ただ、短期間でフィーチャーブランチを終わらせることは難しいとして、その要因について解説した。

フィーチャーブランチが短時間で終わらない要因を分析

フィーチャーブランチの肥大化については、機能要件が大きいほどレビューからマージまでの時間が長くなることを解説し、ここでは600行を超えるコード追加は原則拒否するなどのルールを紹介した。

フィーチャーブランチ肥大化を解説

肥大化を防ぐためにはタスクを分解し、タスク開発途中で必要な別タスクが発見されてもそのブランチでは実行しないなどのコツを説明したが、実際にコーディングを行う前に実装するタスクを洗い出すことは難しい、機能を細分化したことで全体の機能のどこにそれが相当するのかを理解した上で細かなタスクの検証を行うのが困難、これまでの開発作業よりも難易度が上がってしまうことなどの実践的な悩みを紹介した。

タスク分解に伴う難しさを解説

またレビューのための時間を削減するために、プルリクエストのサイズを小さくして理解し易くする、開発者と同時にコミットレビューを行うなどの工夫についても説明を行った。それでも時間がかかってしまう場合は、コードにTODOコメントを付けて後で直すなどの方法をとっていることなどを解説した。

またチームメンバーのスキルが低いことからコーディングとその後のマージまでに時間がかかってしまうという問題については、メンターとしてサポートするなどの手法しかないことを説明した。

チームにインターンが加入した直後にサイクルタイムが悪化、抜けた後に改善

結果として、トランクベース開発を行うことでフィーチャーブランチの生存期間を短くすることが可能になったことをまとめとして紹介した。ここでは1日以内でプルリクエスト作成、2日以内でマージという具体的な目標値を設定したことが議論に役立ったと総括した。

トランクベース開発のまとめ

しかしながら課題としては、サイクルタイム計測はフィーチャーブランチの生存期間を表しているに過ぎず、実際にそれがユーザーに届くまでの時間が計測されていないことなどを挙げて、さらなる検討を進めることを説明してセッションを終えた。

全体として機能開発から実装までの時間を短縮するための苦労話となったが、フィーチャーブランチ短縮のためには単にやり方を変えるだけではなく構造的な要因（組織やレビュワー数）を解決する必要があることが浮き彫りになったセッションと言えるだろう。マイクロサービスの開発サイクルのペースを上げるためには、チーム構成や承認の仕組みまで視野に入れて検討する必要があることを示したことは、大きな意味があると思えるセッションとなった。