並行開発におけるブランチ運用について

本稿はJCB Advent Calendar 2024の12月17日の記事です。

こんにちは。デジタルソリューション開発部の永沢です。
担当プロジェクトでは、メジャーバージョンのアップデートが必要な規模の開発を並行して実施しています。
今回は、そのブランチ運用の方式と、発生した運用ミスの改善について記します。

前提

現状は以下のような開発を並行実施しています。

運用中バージョンの保守開発(バージョンX)
次回メジャーバージョン開発(バージョンX+1)
次々回メジャーバージョン開発(バージョンX+2)

現在のブランチ運用

ブランチ	概要
master	次回リリース予定の資材が格納されているブランチ
developV1	運用中バージョンの保守開発ブランチ
developV2	次回メジャーバージョンの開発ブランチ
developV3	次々回メジャーバージョン開発ブランチ
featureブランチ	作業用ブランチ
release-x.y	リリースブランチ (対象バージョン毎にブランチ作成)

開発の流れ

■タスク着手

develop(開発の対象ブランチ)からfeatureブランチを切り作業する
(例) マイナーバージョンアップの開発をする場合、developV1から作成
featureブランチで開発する
featureブランチからdevelop(作成元ブランチ)にマージする

■Sprintの終了

developV1 → master にマージ
developV1 → developV2 → developV3 の順にマージ

※私の担当システムではアジャイル開発をしています

運用で発生したミスと対策

<発生事象>

マージの向き先ミスにより、次回メジャーバージョンのブランチを誤って、masterブランチにマージしてしまいました。
これにより、次回メジャーバージョンは開発中の段階のため、masterに入れてしまうと検証されていないシステムがリリースされてしまうことになります。
また、利用しているソースコードのバージョン管理システムでは、revertしたコミット履歴は差分として反映されないです。
そのため、メジャーバージョンのリリースタイミングで適切な修正が反映されなくなります。

■許容されるパターン
・developV1 → master
・developV1 → developV2 → developV3 
  ※バージョン番号が高いものは、低いものを全て含んでいる状態にする

■今回の事例
・developV2 → master

<対策>

CIの中で、ターゲットブランチが正しいかチェックする仕組みを入れました。
今回発生したのは、masterブランチに向けたミスでしたが、featureブランチを開発ブランチにマージする際にも同様のことが起きうるため、その対策も同時に実施しています。
具体的な仕組みとしては、以下のようになっています。
■前提ルール

featureブランチの名称を開発コード+対象バージョンとする
(例) MAD-0001V1, MAD-0002V2

■CIでのチェック

ソースブランチとターゲットブランチを比較して問題なければJOBを成功にする
- masterブランチへのマージの場合
  - マージ元がdevelopV1であるかチェック
- 開発ブランチへのマージの場合
  - featureブランチ名のバージョン(例: MAD-0001V1)とターゲットブランチ名のバージョン(例: developV1)が合っているかチェック
- 次回移行のメジャーバージョンへのマージの場合
  - developV1 → developV2 or developV2 → developV3かチェック