見出し画像

【DevOps】トランクベース開発導入のための環境整備について

CyberZ Developer

CyberZのiOSチームでエンジニアをしている縣です。
OPENREC.tvの開発チームでは、DevOps及びSREの実践による生産性の向上を推進しています。
今回は、開発スピード改善の一環として導入したトランクベース開発について、実際にiOSチームで導入するにあたって行なった環境整備についてご紹介いたします。

トランクベース開発とは

トランクベース開発とは​​、開発チームがバージョニングを使用して共同作業を行う際の開発手法の1つです。それぞれの開発者は作業を小さなバッチに分割し、その作業を1日に少なくとも1回（場合によっては数回）トランクにマージしていきます。従来のGitFlowやGitHubFlowにおける機能ブランチを用いた開発では、機能の開発完了までブランチでの作業が継続しますが、トランクベース開発ではそれとは対照的に、ブランチでの作業が数時間以内で完了するという特徴があります。

トランクベース開発導入前の課題

これまでOPENREC.tvのiOSチームでは機能ブランチを用いた開発を行なっていましたが、いくつかの問題を抱えていました。

  • 各機能ブランチにトランクの変更を都度取り込む手間がかかる

  • 機能ブランチでの開発完了後のマージ時に膨大な差分のレビューが困難

  • 機能ブランチでの開発が長期にわたることでコンフリクトが発生しがちになる

これらの問題を解決するため、機能ブランチによる開発からトランクベース開発へ移行する決断をしました。

トランクベース開発の実践

Googleによって提唱されている、トランクベース開発の実践方法と注意事項は以下の通りです。

実践方法
・アプリケーションのコードリポジトリに3つ以下のアクティブなブランチを用意する
・少なくとも1日に1回、トランクにブランチをマージする
・コードフリーズや統合フェーズをなくす

注意事項
・過剰なコードレビュープロセス
・非同期でのコードレビュー
・コードを commit する前に自動テストを実行しない

これらの中でも、注意事項として挙げられている「過剰なコードレビュープロセス」、「非同期でのコードレビュー」を特に意識し、取り組みを行ってきました。実際にこれらを実践し、トランクベース開発の導入時において特に意識しておきたい3点をご紹介したいと思います。

作業単位と同期的レビュー

トランクベース開発においてブランチの生存期間は短く、開発者は作業を少なくとも1日に1回トランクにマージすることが求められます。そのためには同期的なレビューを実践し、同時並行でいくつもの作業を行う必要がない状態を作り出す必要があります。同期レビューが成立していないと、一度に複数の作業をレビューしてもらう方が効率的であると考えてしまい、複数の作業をまとめて行おうとする意識が働きます。しかし、複数の作業によって差分が多くなればなるほどレビューコストは上がり、同期レビューを阻害する悪循環が生まれ、結果としてトランクベース開発が成り立たなくなります。
作業単位を小さくし、同期的レビューを実現するために、私たちのチームでは以下の取り組みを行っています。

  1. 1PRでの変更は概ね100行程度におさめる

  2. GitHubの通知などを活用し、未レビューのPRのレビュー促進を行う

  3. 他チームと連携しPRのレビュー時間の計測を行い、即時レビューの意識改革を行う

チーム内で作業単位の認識を揃えることでレビューコストも下がりますし、レビューリクエストを受けた際には作業を一旦停止して即時でレビューを行うという意識を持つことで、開発サイクルのスピードを高めることができます。

FeatureFlagsの導入

トランクベース開発では細かな作業単位で作業をどんどんトランクへマージしていくため、しばしば開発途中のものがトランクへマージされます。そのためリリース時に開発中の機能が影響を与えないような仕組みを作らなければいけません。これを実現するのがFeatureFlagsです。
FeatureFlagsはOSSを利用する方法などもありますが、私たちのチームでは、デバッグ画面にFlag操作のためのスイッチを用意し、Flagの有効化/無効化を切り替えることを可能にしています。開発中の機能はこのFlagがオフの状態でリリースされ、複数人でのデバッグ時や開発完了後にリリースを行う際にはFeatureFlagに関わらず動作する状態にしています。

ブランチ戦略の見直し

これまで機能ブランチによる開発を行っていた際はmasterとdevelopブランチの2本を運用していました。機能ブランチを切る際にはdevelopからfeatureブランチを切り、さらにそこから細かな作業ごとに再度ブランチを切る、といった運用をしており、アクティブなブランチの数が多くなるだけではなく、開発完了後にdevelopブランチにマージする際にはその差分の多さに悩まされることもしばしばありました。
トランクベース開発に移行するにあたり、developブランチを削除しmasterブランチ1本に統合しました。それに伴ってmasterからreleaseブランチを切ってリリースをする、hotfixはmasterに向けてPRを作成してreleaseブランチはmasterからhotfixをチェリーピックする、というようにブランチの運用フローの見直しを行いました。以前と比較するとマージ作業などがシンプルになり、見通しがよくなったように思います。

メリット / デメリット

トランクベース開発を導入したことで、機能ブランチを用いて開発を行っていた際の複雑さがなくなり、結果として開発スピードの向上がもたらされました。また、副次的な効果として、FeatureFlagsの導入を行ったことにより新旧UIの比較が容易になり、デバッグしやすくなったなどの効果もありました。一方で、トランクベース開発では開発途中の機能をどんどんトランクにマージしていくため、FeatureFlagsを用いて新旧の構造を共存させるための考慮を行わなければいけないため、考慮する点が増えたことも事実です。またチーム内での同期レビューやFeatureFlagsの運用ルールなどを定めておかないと、逆に開発効率を落としてしまったり、コードが煩雑化する可能性もあります。

まとめ

今回はトランクベース開発を実際に導入するにあたって行った環境整備についてご紹介しました。実際にトランクベース開発を導入し運用する中で、トランクベース開発は開発スピードを向上させるための強力な手段となり得るものですが、トランクベース開発を行うための環境整備が行われていなければ、逆効果となってしまう可能性もあると感じました。今後も開発スピードを落とさず開発を進めていけるよう、今回ご紹介した点を意識しつつより良い開発体制を作っていければと思います。

参考


この記事が気に入ったらサポートをしてみませんか？