テスト環境がないGit経験もないオフショアチームにカスタマイズGitflowを導入した話

こんにちは。未経験から体当たりPjMを始めて来月で1年経ちます、りゅうじです。

経験のない「初めてやってみた」から全力でやりきって習得するのを元々得意としているのですが、だいたいが「普通はそんな状況で対応することないよね」ってところからスタートがデフォルトになっているのが鍛えられポイントなのかな？と前向きに対応したプロジェクトは10を超えてきています。

50%でもいけると直感が出てきたら全力でやってみると習得スピードも格段にあがるのでおすすめです。もちろん発注元の理解があることが前提なので挑戦を許容してもらえることはありがたい限りです。

さて、今回の初めてやってみたシリーズは「Gitflow」をオフショアチームに導入した時の話になります。

方法としては他に正解例もたくさんあると思うのですが、正解の出し方というよりはコミュニケーションの取り方、経験が少ない中で実現できる方法をチームで考えていくきっかけの記事になるように書きました。

それでは本編になります！

Git flowの前にGitの使い方からスタート

例にたがわず常識が通じない状況で、テストコードを書かずにCI CDを実施したいという要件が降りてきました。自動化の意味少なくないか…と即決で断ることはできるのですが、まずはGit運用の状況を確認することにしました。

• Git運用をしたことがある→実際はバックアップ運用でブランチ作成の定義が決まっていなかった
• コミット文のルールがなくコード差分の確認が実物を見ないと分からなくなっていた
• 各エンジニアがタスクを順番にやっているだけの状況でチーム開発の良さが作られていなかった
• SourceTree運用していたのでCUI運用のような柔軟な対応ができない

大まかに分けてこのあたりでした。

Gitができていないとコードが酷い？

今回の問題としてGitを見るだけでは作業差分が見えてこないためコードを見に行かないと現状がわからず、何がエラーの発端となっているかも不明な状態でした。

開発チームの趣旨としてはチーム内でのバックアップ目的として運用していたということでしたが、このままでは複合チームで開発するときに各々が好き勝手な実装を行うようになり非効率極まりない状況になります。

実際にあるオフショア解雇のパターンで多いのが「コードが煩雑すぎて動けば良い感で作られているので本番運用に耐えられない」ということが多いです。ここを紐解いていくと「コードもそれなりに問題だけどドキュメントやバージョン管理がレガシーすぎてセキュリティや可用性に穴が生まれやすい状況」だということが問題だということがわかってきました。

欠けているテストコードを埋める工夫

そこでまずGitflowの様式を踏襲しながらも、そのままではテストコードも書かず運用できない問題を解決していくことにしました。

• コミット文のルールがなくコード差分の確認が実物を見ないと分からなくなっていた

まずはコミット文で分かりやすくすることからはじめました。

git commit -m “feature/add-login：add login by email send email”

まずはこのような「ブランチ名：差分の内容」を機能追加単位でコミットをうってもらうようにしました。英文で書いていることについてはブリッジSEのコスト削減目的です。エンジニアは英語までなら対応できる人が多かったりするので、対応ハードルをあげすぎないように意識しました。

各ブランチごとの指示

初期対応としてはブランチ運用までできるようになると大分楽になりました。実際にどのような指示を出したかは作ったマニュアルを参照しつつまとめとさせていただきます。

master

製品運用（本番）ブランチとして常時デプロイ可能な状態、コード改修作業（コミット）NG、エラーの起こらない状態を維持するよう努める。リリース以降で運用がスタートするブランチ。バグやエラーが起こった場合はmasterブランチからhotfix/エラー名の命名ルールとしてブランチ作成、改修完了したらdevelopブランチへpull requestを提出、レビュアーが精査、承認してdevelopへmerge、実機確認を経てdevelopブランチからmasterにレビュアーがmergeする。

production環境とstaging環境を同じリポジトリで運用する経験がなかったということで切り分けるための運用方法です。

develop

開発運用ブランチ、削除NGブランチ。develop/〇〇など派生させてはいけない。developブランチはfeatureからのmerge専用ブランチで開発環境（staging）にデプロイしてコードの不具合がないか実際の稼働をチェックする目的を持つ。

• バグやエラー回収を開発者がdevelopブランチで行ってはいけない。開発者はfeatureブランチ内で内部機能におけるバグの起こらないよう問題解決を行いdevelopブランチへpull requestを提出するだけにする。
• pull requestを受けたコードレビュアーの承認が取れたコードがdevelopに反映されるため開発コードの最新版はdevelopブランチとして、テスター（実機で見る表面上の機能チェック）はdevelopブランチのコードを参照して実機確認を行う。developブランチで内部機能に由来するエラーが起こらないようにする目的がある。

テストコードを書かない→レビュアーもいないという恐怖構造だったので、staging環境とはいえ、クライアント確認でバグを見せるのを少しでも避けるためにdevelopへのpushは禁止にしてmerge運用のみにしました。

feature

機能追加ブランチ、feature/add-login などのブランチ運用をする。

• コード開発完了でdevelopブランチにpull requestを提出する。コードレビュアーはpull requestを受けて内容を精査し、問題ないことが確認できたらdevelopブランチへmergeする。
• featureブランチから派生するブランチ本数に制限はないが派生ブランチを作る際はfeature/add-mypageなどになるようdevelopブランチに一度checkoutして新しく作る形になる。（feature/add-loginブランチから新規ブランチを切ってはいけない）そのためfeatureブランチは全てfeature/〇〇→機能名の書式になる。
• featureブランチの命名はタスク単位の粒度とする。（例：feature/add-mail-login feature/user-register-crud feature/user-follow-crud）

重複するタスクを複数メンバーが実装するということが日常的に起こっていました。featureブランチを作る時点で重複を避ける開発計画を進めるために可視化しました。

release

機能完成してテストユーザーを入れたチェックを行う目的でstaging環境を公開するブランチ、ユーザーを入れた検証を兼ねるときにreleaseブランチで公開する。

• 開発チームのみの実機検証はdevelopブランチ下で行うためreleaseブランチを運用するのはテストユーザー入る点がdevelopブランチと相違する。
• releaseブランチ下ではfix程度の修正は行って構わないが、機能修正にかかる粒度の修正をコミットしてはいけない。機能修正にかかる粒度の重大なバグやエラーが発覚した場合はreleaseブランチからhotfixブランチを作成して（release/hotfixではなくhotfix/fix-login-errorブランチなどの方式で新規で立てる）対応。
• 本プロジェクトにおけるreleaseブランチ運用が始まるのはクローズドβ版としてクライアント様の用意したユーザーを導入してテストを行うタイミングになる。

developブランチをstaging環境ブランチとして運用していた頃はバグが取れ切れない状況が続いていました。それを解消するためにreleaseブランチを作って解消しました。

hotfix

masterで起こった緊急を要するクリティカルなバグやエラーの改修ブランチ。

• 開発者がコード修正を完了したらdevelopブランチにpull requestを提出、コードレビュアーの精査、承認を経てdevelopブランチからmasterブランチへのmergeをレビュアーが行う。
• 万が一releaseブランチでクリティカルな問題が発生した場合はイレギュラーとしてhotfixブランチで処理することも許容するが通常は機能追加するfeatureブランチで内部機能の問題解決は完了させる。

クリティカルなバグもmaster、developで対応していると、時間が経ってからのフィードバックが見えづらくなり非生産的です。クリティカルなバグは再発させるわけにはいかないので予防のためにもhotfixを設置しました。