はじめに

こんにちは。株式会社SHIFTのITソリューション部アプリケーションサービスG 大西です。
今回、私が以前参画していたプロジェクトで活用したSVNでの2次開発以降のブランチ活用例を紹介します。
他のバージョン管理ツール（Git,TFSなど）においても共通する考え方となりますので参考になれば幸いです。

なぜ、ブランチを使うのか

無事、本番リリースが終わった。次は・・・開発が始まる。

システム開発の多くの場合は課題の積み残しであったり、新たに発生した要望対応や連携する他システムの仕様変更への対応など、初期開発で盛り込めなかった仕様への対応として２次開発を実施します。

２次開発での注意点は？

２次開発は、初期開発と異なり、本番環境で動作中のシステムが存在します。本番環境のシステムは運用を開始しており、システムを停止させると業務的な影響が発生します。
こういった状況ではありますが、実際に運用を開始したことで本番環境で思いもよらぬ形での不具合や仕様漏れの発覚、システム障害の発生等により緊急でのプログラム改修が発生する場合があります。
ですが、２次開発が始まるとプログラムソースも改修されており、本番リリース済みのソースがそのまま残っていないことが考えられます。
こうなると、当時のソースを探し出す作業が始まるのですが、下記のような事態になってたりします。

• 本番環境のものと一致しているか検証しないと分からない

• 特定の人しか管理していないので、ほかの人では対応できない

このような事態への対応として、２次開発の途中であっても本番環境のソースをすぐに取得できるように、事前に開発環境を整備しておく必要があります。

バージョン管理ツールを使っているならブランチを分けておこう

こういったときに活用するのがブランチです。
バージョン管理ツールでは、ソースの履歴を管理し、誰がいつどんな変更を行ったかを管理していますが、ブランチを行うと履歴のライン自体を分けることができます。

逆方向の操作としてはマージが存在します。 ブランチ先で変更した内容をブランチ元（あるいはブランチ元→ブランチ先）に差分を反映します。
　※自動で差分が判別できない場合は手動でどの変更を採用するかを判断する必要があるため注意

ツールの違いはあれど大抵はブランチ、マージ機能が用意されています。
実際の操作については下記をご参照ください。

svn:https://tortoisesvn.net/docs/release/TortoiseSVN_ja/tsvn-dug-branchtag.html
git:https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%81%A8%E3%81%AF
tfs:https://learn.microsoft.com/ja-jp/azure/devops/repos/tfvc/branch-folders-files?view=azure-devops

環境の整理とバージョン管理フォルダ構成

サーバー構成

プログラム開発では開発環境、テスト環境、本番環境がそれぞれ用意されていることかと思います。

開発環境については今回は開発者各々の端末で初期開発環境と２次開発環境を管理することとします。
テスト環境では初期開発時の環境を維持したまま、２次開発分の動作用の環境についても追加します。
本番環境については別システムとの連携などもあるので２次開発のリリース後も引き続き同一環境を利用していきます。（リリース時に置き換える）
なので環境の準備としては下記のようになります。

※実際はDB,AP,WEB,FTP,BATなど、サーバー環境によっては別環境の用意が難しかったりすることもあるので、サーバー別の考慮が必要となります。

フォルダ構成

今回はSVNを使用してますので、SVNの基本的なフォルダ構成をもとに下記の通り用意します。

  |--- trunk
  |--- tags
  |--- branches
  |      |--- hotfix_nnn
  |      |--- Release
  |      |--- Develop

開発フェーズに応じた使い分け

２次開発開始時(～開発・単体テストまで)

まずはReleaseブランチとDevelopブランチをtrunkから作成します。 開発中はDevelopブランチのソースを改修します。

結合テスト以降のブランチ管理

ここからはテストサーバーでの検証が発生します。
テストサーバーへの反映の度に下記の手順を実施します。

1. Developブランチの変更内容をReleaseブランチにマージ

2. Releaseブランチの変更内容をテスト（２次）に反映する

テストの結果修正が発生した場合も再度1から実施します。

２次開発リリース時のブランチ管理

いよいよ本番環境へのリリースです。

1. Releaseブランチの変更内容をtrunkブランチにマージ

2. trunkブランチの変更内容を本番環境に反映する

3. 合わせて、本番環境の動作検証用として、開発・テスト環境（２次じゃないほう）にも２次開発リリースした内容を反映しておく。

本番環境で修正が必要になったら・・・

発生しないに越したことはありませんが、環境を整備するうえでは事前に考慮が必要となります。
修正発生都度、下記の順で対応します。

1. hotfix_nnnブランチをtrunkから作成します。

2. hotfix_nnnブランチでソースを改修し、テスト環境に反映、検証します。

3. 問題なければ、hotfix_nnnブランチの変更をtrunkブランチにマージ※後、 本番環境へリリースします。
   　※trunkブランチの最新ソースのみ本番サーバーに反映するようにルール化しておくことで、改修途中のソースの反映の防止や、trunkへの最新ソースの反映漏れから発生するデグレードを防ぐ狙いがあります。

4. trunkブランチの変更をRelease、Developブランチにマージ後、hotfix_nnnブランチを削除します。
   　※役割を終えたブランチは削除しましょう。別の修正は別のブランチにて対応しましょう。

３次開発以降ではどうなるの？

２次開発開始時と同様にtrunkを本番環境の最新用、Release・Developを３次開発用としてください。
　※Release・Developブランチは開発が継続する限り、削除せず引き続き利用します。

また、各サーバー環境も２次開発用としたものを３次開発のものとして扱ってください。

こうなってくると、名称も"現行環境用"、"次期開発用"としたほうが 今後使用する際にわかりやすくなるのでいいですね。

まとめ

SVN構成をまとめると下図のイメージになります。

２次開発時の参考になれば幸いです。

参考

ブランチ戦略(git)
https://nvie.com/posts/a-successful-git-branching-model/
ブランチ戦略(TFVC)
https://learn.microsoft.com/ja-jp/azure/devops/repos/tfvc/branching-strategies-with-tfvc?view=azure-devops
Subversion の「trunk」「branches」「tags」の使い方(SVN)
https://tracpath.com/bootcamp/learning_subversion_tutorial1.html
git-flow、GitHub Flow
https://atmarkit.itmedia.co.jp/ait/articles/1708/01/news015.html

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/

PHOTO：UnsplashのChris Ried