CI/CD Conference 2023、DMMのエンジニアが解説するCIを加速するトランクベースの開発とは
![](https://thinkit.co.jp/sites/default/files/styles/main_image_730x/public/main_images/22175_main.jpg?itok=EtyKjSQ5)
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つの指標を挙げる。
- デプロイ速度
- 変更のリードタイム
- 変更障害率
- サービス復元時間
上述の指標の中から「変更のリードタイム」を短縮することで、全体の処理時間を改善する内容となっている。
一般的にソフトウェアの変更(機能追加や修正)についてはソースコードのメインブランチに対して複数の枝分かれ(フィーチャーブランチ)が発生し、それぞれが開発を行い、最終的にメインブランチにマージされることで並行的に開発が進むが、ここでの問題点はメインから枝分かれした時点以降で別のエンジニアが機能追加のためにブランチを実行することで、最終的なソフトウェアにおいてコンフリクトが発生してしまうことを説明。
この状況が発生してしまう要因として「フィーチャーブランチのサイズが大きい(機能追加要件が大きい)」ことと「コーディングが完了してもそれがレビューされ、マージされるまでの時間差が大きい」ことであると説明。
その上で、フィーチャーブランチを使わないでメインブランチに直接修正をコミットする手法、トランクベース開発を説明した。
ここでは本来、実装しなければいけない機能ができあがっていないのにコミットが行われてしまう可能性について言及し、それを防ぐための手法、フィーチャーフラグについて簡単な説明を行った。
ただし実際にこの手法を小林氏のチームで検証したところ、「フィーチャーブランチを使わずに開発を行うのは難しい」という判断に至ったという。その理由についてはコミットと同時にコードレビューを行うことが難しいこと、CIのチェック(単体テストなど)を実行せずにコミットして良いかを判断できないことなどを挙げた。
ここからはフィーチャーブランチを使う開発手法、特にフィーチャーブランチが存在する期間を極端に短くすることでフィーチャーの肥大化を防ぎ、プルリクエストによるレビューを可能にするShort-lived Feature Branch(短期間だけ存在するフィーチャーブランチ)による開発を紹介した。
Short-lived Feature Branchは「数日以内にマージすること」「メインブランチ以外にマージしない」「開発者以外はコミットしない」などのルールを挙げて、短期間でマージまでを終わらせるための工夫を紹介した。
これによってプルリクエストによってレビューが行えること、CIパイプラインによってマージ前のコードチェックが可能になることなどの利点を挙げた。
ここからはDMM内部での事例としてGitHubをソースコード管理として使い、Goを使ってコードを記述、実行環境はKubernetes、CIはGitHub Actions、CDはArgoCDというプラットフォームについて紹介した上で、トランクベース開発の背景を説明した。マイクロサービス化に向かって、開発チームの中から認証許可チームが最初に実証実験の場となったことを説明した。
ここで短期間でフィーチャーブランチを終了するために、開発着手から1日以内にプルリクエストを作成、レビューはプルリクエストを作成後、2日以内にマージし、フィーチャーブランチを削除するというルールが紹介された。
マージまでの時間がかかってしまうことの大きな要因であったコードレビューについては「非同期で行うこと」「24時間以内に実施すること」「自動化された単体テストやLintによる文法チェック」などが実施されたことを説明し、レビュワーそのものが少人数であるにも関わらず、短期間でのレビューとマージを目指していることを強調した。
コードの変更がどのようにマージされているのかを可視化するCode Climate Velocityについて簡単に紹介した上で、1日以内のプルリクエスト作成、2日以内にマージが守れなかった場合の振り返りのための反省シートを紹介。毎週のチームミーティングで確認を行うというプロセスを導入し、開発サイクル短縮化を継続したと説明した。
実際にこの開発手法を取ってからの成果についても簡単に紹介されており、平均サイクルタイムが全社平均は68.8時間となっているのに対し、認証許可チームは約11時間であることから、着実に成果が現れていると説明。
ただ、短期間でフィーチャーブランチを終わらせることは難しいとして、その要因について解説した。
フィーチャーブランチの肥大化については、機能要件が大きいほどレビューからマージまでの時間が長くなることを解説し、ここでは600行を超えるコード追加は原則拒否するなどのルールを紹介した。
肥大化を防ぐためにはタスクを分解し、タスク開発途中で必要な別タスクが発見されてもそのブランチでは実行しないなどのコツを説明したが、実際にコーディングを行う前に実装するタスクを洗い出すことは難しい、機能を細分化したことで全体の機能のどこにそれが相当するのかを理解した上で細かなタスクの検証を行うのが困難、これまでの開発作業よりも難易度が上がってしまうことなどの実践的な悩みを紹介した。
またレビューのための時間を削減するために、プルリクエストのサイズを小さくして理解し易くする、開発者と同時にコミットレビューを行うなどの工夫についても説明を行った。それでも時間がかかってしまう場合は、コードにTODOコメントを付けて後で直すなどの方法をとっていることなどを解説した。
またチームメンバーのスキルが低いことからコーディングとその後のマージまでに時間がかかってしまうという問題については、メンターとしてサポートするなどの手法しかないことを説明した。
結果として、トランクベース開発を行うことでフィーチャーブランチの生存期間を短くすることが可能になったことをまとめとして紹介した。ここでは1日以内でプルリクエスト作成、2日以内でマージという具体的な目標値を設定したことが議論に役立ったと総括した。
しかしながら課題としては、サイクルタイム計測はフィーチャーブランチの生存期間を表しているに過ぎず、実際にそれがユーザーに届くまでの時間が計測されていないことなどを挙げて、さらなる検討を進めることを説明してセッションを終えた。
全体として機能開発から実装までの時間を短縮するための苦労話となったが、フィーチャーブランチ短縮のためには単にやり方を変えるだけではなく構造的な要因(組織やレビュワー数)を解決する必要があることが浮き彫りになったセッションと言えるだろう。マイクロサービスの開発サイクルのペースを上げるためには、チーム構成や承認の仕組みまで視野に入れて検討する必要があることを示したことは、大きな意味があると思えるセッションとなった。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- これだけは押さえておきたいGitHub Flowの基礎
- Protected Branches機能で柔軟なワークフローを構築する
- DevOpsにおける開発者の振る舞いを理解しよう
- Visual Studio 2005の変更管理の有効性
- DevOpsのサイクルをコードで管理し、プロセスを自動化する「CI/CDパイプライン」
- DevOpsのアプリ開発にも欠かせない「Git」を活用したソースコードのバージョン管理
- RancherとCI/CD
- Oracle Cloud Hangout Cafe Season4 #3「CI/CD 最新事情」(2021年6月9日開催)
- CI/CD Conference開催、CI/CDをツールではなく原則の面から解説したセッションを紹介
- RevertとBlameを使いこなして安全性の高い開発を推進しよう