🌈

SVN開発にGitプルリクエスト導入した話し

2020/11/01に公開

Git

SVN

Backlog

idea

こんにちは。なみさん＠がんばらないです。

私は数年前から自社パッケージ製品の製品開発に関わっていて、今年から製品開発のリーダーを行うようになりました。色々新しいことに取り組んだんですが、その中でも成果が大きかったGitプルリクエスト運用についてここにまとめたいと思います。

本記事は次の構成となっています。

SVNを使った開発の問題と課題
課題を解決するGitプルリクエスト運用
Gitプルリクエスト運用のメリット
SVNだけでも十分じゃない？
SVNとGitを両立する運用のコツ
Gitの課題

SVNを使った開発の問題と課題

自社パッケージ製品のSVNリポジトリはtrunk、branches、tagsの一般的なSVNディレクトリ運用をしています。
製品は定期的にバージョンを切るために、trunkからbranchesのディレクトリにブランチを作ります。そこから更に導入個社向け等にバージョン別ブランチからブランチが作られたりしていきます。
私達製品開発チームは基本的にtrunkに対して機能追加や障害対応を行なっています。

SVNリポジトリの例
自社パッケージ製品のSVNリポジトリ

SVNにおいてtrunkは開発中の最新バージョンを意味するブランチです。製品開発のチームでは、チームメンバーが障害対応や機能追加をtrunkにコミットしていました。例えば、trunkのコミットログは次のようになっています。

Revision	Auther	Date	Message
1234	member2	2020/5/15 15:00	#2140 機能Bの開発中コミットビルドエラー対応
1233	member1	2020/5/15 10:00	#2133 機能Aのレビュー対応結果
1232	member1	2020/5/10 16:00	#2133 機能Aのテスト完了
1231	member3	2020/5/8 10:00	#2110 障害Bのコミットミスの対応
1230	member2	2020/5/1 14:00	#2140 機能Bの開発中コミット

これによって、次のような問題が発生します。

全員がtrunkに対してコミットするため一人のビルドエラーが全員を巻き込む
1つの機能開発が複数回コミットで完成するため、開発を続ける限り安定版を作ることが難しい
開発中コミットが頻繁に入るため、どこまでレビュー・テストしたか分からなくなる

SVNはGitと違ってサーバー上のリポジトリのみなので、コミットによって他のメンバーにも影響が発生します。コミット漏れや、ビルドエラーとなるコミットが行われると、チーム全員がその影響を受けることになります。

コミットミスでエラーとなる図

また、複数機能や障害対応のコミットが入り乱れるため、「いつになれば安定版となるのか」「いったいどこまでレビューしたのか」などの管理が大変です。
実際問題、レビュー依頼されたけど忙しくてレビューできずに、バージョンブランチに移ってしまったみたいな事も発生していました。

ノーレビュー・ノーテストコードがバージョン別ブランチに出てしまうと、その後顧客用ブランチに出てしまい、実運用に入った段階で「実は機能が動かない」なんていう問題が発生する危険があります。

弊社では別途導入チームが水際で障害を発見してくれていましたが、導入チームの手間を思うとこの運用は良くありませんでした。

課題を解決するGitプルリクエスト運用

こういう課題（問題）を解決するため、Gitとプルリクエストを活用した 必ずレビューが必要な 製品開発プロセスを今年から導入しました。

SVNはパッケージ製品に関わる人（導入チーム、サポートチーム、営業等）全員が利用しています。また、過去の障害を解析するためにコミットログが重要だったりするので、全部Gitへ移行する事はできません。そのため、SVNのtrunkの開発のみをGit上で行う事にしました。

SVN-trunkをGit上で行う図

今まで、製品開発に携わる人はtrunkに直接コミットしていましたがコレを辞めます。
開発者はGitのmasterブランチから開発用のブランチを都度作成し、そこでレビュー完了まで開発（コミット）を行うようにします。

また、一通りの開発とテストを終えたら、プルリクエストを利用してレビュー依頼を行うようにしました。プルリクエストとはブランチを作った人が、元ブランチに取り込んで貰えるよう依頼する機能です。

プルリクエストの例

レビューアはテスト結果やコードを確認して問題なければマージを行います。
マージされたソースコードはGitのmasterに入り、そのままsvnのtrunkにコミットできるように運用しています。（正確には、色々なブランチ運用を経てGitのmasterとSVNのtrunkに入るのですが、ややこしいので今回説明は割愛）
これにより、SVNのtrunkは常にレビュー・テスト済みのコードとなり、以前より安全なコードが維持されます。

プルリクエストマージ後のSVNコミットの図

Gitプルリクエスト運用のメリット

GitリポジトリはBacklogを利用しています。Backlogはとても使いやすいUIで、誰もが抵抗感無く使えるとても良い製品だと思っています。

そんなBacklog上で行うプルリクエストが楽しいという点がメリットだと思います。楽しいと思える理由は次にあると思っています。（別製品も同じ機能があります）

Web画面上でソースの差分ファイルの一覧や変更箇所が分かる
直接レビューコメントが残せるのでレビューがとても行いやすい
Web画面上でコメントの履歴が残るので、レビューアとレビューイの議論の場になる

レビューが終わったあとは、「マージ」ボタンを押すだけでマージされるのも、手間が少なくて良いですね。プルリクエストが無かったらわざわざGit運用をするメリットは無いかもしれません。

SVNだけでも十分じゃない？

「SVNでも開発用ブランチを分けてマージする運用を取れば良いのでは？」と思われる方もいらっしゃると思います。
おっしゃる通りその運用も可能で、製品開発チーム以外の人はSVNで一時ブランチを作ってそこで開発を行なっています。

しかし、SVNはGitに比べてブランチの運用が手間です。Gitは手軽にブランチが作れますし、分散リポジトリの特徴からコミットしてもpushしなければリポジトリを汚す事がない為、開発者の心理的にも安全です。

しかし、どんなにSVN上のブランチ運用を作ったとしてもSVNで開発を続ける事自体に限界があると私は思っています。物理的に開発をSVNから切り離さない限り、ブランチ運用とレビューの手間からtrunkに直接コミットする人が出てきてしまうでしょう。

SVNとGitを両立する運用のコツ

SVNのtrunkをGitのmasterに合わせるようにGitの運用を行うのですが、SVNのコミット粒度は以前のまま合わせる必要があります。
パッケージ製品のSVNではコミットの際にredmineチケット番号を必ず書いてコミットするルールになっています。基本的に1コミットに複数のチケット番号を書いてはいけません。（きっとどの現場もそのような運用になっていると思います）

SVNのtrunk上の開発をGit上に移したとしても、SVNのtrunkコミットを行う際は1コミット1チケット番号になるように徹底します。そうしないと、障害発生の原因特定が行えなくなったり、他チームが特定の機能・障害対応だけマージするといった事ができなくなります。

これを実現するため、プルリクエストをマージしたらすぐにSVNにもプルリクエストの変更をコミットします。たとえ、連続でプルリクエストのマージを行う予定でも、一つ一つsvnのコミットを行なっていきます。

他のチームに影響を与えないようにする事が一番守らなければいけないルールです。

Gitの課題

SVNを運用している現場でGitを導入する際の課題の一部を以下にまとめます。

SVNとGitで用語も考え方も違うので初心者は混乱する
Gitの最初の関門は分散リポジトリでしょう。fetchにpullにpushと、コミット以外に覚える事が沢山あるので混乱します。とくに新卒入社で配属される人はSVNも覚えてGitも覚える必要があって大変じゃないかと思います。
プルリクエストのレビューは変更点以外も気にしないといけない
プルリクエストは変更点を分かりやすく表示してくれるため、レビューアにとってはとても助かります。しかし、レビューする際は変更点だけではなくてその前後や周辺コードにも影響が無いか確認する必要があります。レビューアは変更点だけに囚われないよう注意が必要です。
プルリクエスト上の議論は重要な知見であり共有が必要
プルリクエストではコメントで議論できる点がメリットです。そういうレビューはチームメンバー全員に共有されるべき知見である可能性が高いです。プルリクエスト上で魅力的な議論になったらチームメンバーに共有できる仕組みがあると良いです。

おわりに

SVNとGitの並行運用を行った事により、ノーレビュー・ノーテストでコードが市場に出て行くことが無くなりました。また、若い子にレビュー意識が定着しているのも肌で感じています。良い効果が出ているので、今後も改善をしながら続けていきたいと思っています。

自分はBacklogを利用していますが、Gitプルリクエスト運用はプルリクエスト機能を持ったGitリポジトリが必要になります。Githubなど社外にソースを出せない場合、社内にそういったものが無いとハードルが高かったりします。

私も今の会社に入社した時、社内ではGitが一切使われていませんでした。その後、社内にオンプレ版Backlogを構築させて貰い、チームメンバーにGitを理解してもらって今があるので、自分の周りの方々に感謝しかありません。

この記事を読んで「自分もGitプルリクエストの恩恵を受けたい！」と思ってくれた人がいたら幸いです。GitリポジトリのソリューションはOSSでも沢山あるので、是非チャレンジして貰えればと思います。