LoginSignup
0

More than 3 years have passed since last update.

安全かつクイックなリリースのために、Git flowを拡張してみた

Last updated at Posted at 2020-12-14

この記事は株式会社アトラエのアドベントカレンダー15日目の記事です。
https://qiita.com/advent-calendar/2020/atrae

本日は新卒2年目の土屋が書きます。
普段は、エンゲージメント解析ツール「wevox」というSaasのプロダクトで、エンジニアをしています。

Git flowとは

複数人で一定以上の大きさのプロダクトを開発していく上での、
Githubの運用ルールのようなもの、だと理解しています。
開発手法と呼んだり、ツールの名前でもあったりと細かいことはありますが、本記事ではその辺りは触れず他記事に譲ります。
概念的には、下記の画像がわかりやすかったです。

image.png

引用: 【図解】git-flow、GitHub Flowを開発現場で使い始めるためにこれだけは覚えておこう

参考:
Gitを最大限に活用できる「Git flow」で、効率よく開発を進めよう!
Git-flowって何?

Saas事業者としての課題感

僕らのチームでもGit flowに則り、

  • 新規機能はdevelopからfeature/hogehogeブランチを切って〜
  • バグ改修はmasterからhotfix/hogehogeを切ってマージして、cherry-pickして〜

のように運用していました。

ただ、クライアントが増え、チーム自体も大きくなっていくと、
下記のようないくつかの課題感が出てきていました。

  • Saas事業者としてできる限りクイックにupdateしていきたいけど、急な変更はユーザーに混乱を招いてしまう...
  • 混乱を回避するために、実際に動く環境で事前にカスタマーサクセス(CS)に確認を取りたい
  • ただ、そうすると、CS確認期間は他の細かい改修についても、developからreleaseブランチを切ってリリース、ができなくなってしまう...(順番待ち状態)

などなどです。
これを Git flowを拡張して解決できないか?と考えました。

各ステークホルダーの気持ちを考える

クライアントの気持ち(主に運用担当者)

  • 急に機能が変わったり追加されるのは、使い方がわからなくてシンプルに困る...
  • 私が主導して導入したwevoxの機能変更だから、社内周知資料を作らなきゃ...社内用のマニュアルも変更しないと...

カスタマーサクセス(CS)の気持ち

  • リリース前にFAQやマニュアルを更新しなきゃ...
  • FAQとマニュアルを更新した上で、クライアントにはリリースの事前告知をして、ケアをしなきゃ...
  • けど、他業務も忙しいから、新機能ごとに毎回エンジニアと擦り合わせのmtgを開くとかはできない...

エンジニアの気持ち

  • せっかく頑張って作ったのに、クライアントやCSメンバーから問い合わせやクレームが来るのは嫌だ...
  • コンフリとか起きても面倒だし、何より完成した機能は一刻も早くリリースしたい!

やったこと

諸々と検討し、
これらの各ステークホルダーのお悩みを解決する施策の1アイデアとして、

「既存の PRD,STG,DEVなどとは別で、CSが早めに新機能を確認できる環境(=CS環境)を作る」

に着地しました。そうすれば、

  • 事前に告知が必要なほど大きな機能の場合は、CS環境にデプロイして早い段階でCSに共有
  • その他の小さな改修は通常通りのGit flowに沿ってクイックに本番まで持っていく

ということが可能になります。

具体的にやったこととしては、

  • インフラエンジニアと連携して"CS環境"なるDEV環境と同じレベルの環境を用意してもらう(Special Thanks To クーマさん!)
  • developからcs/hogehogeというブランチを切りpushしたら、自動でCS環境にデプロイされる仕組みを作る
  • 下記の「Git flowを拡張した運用」をプロダクトチームメンバーに周知して運用する
    • 機能開発は通常のGit flowに則り、developからfeature/hogehogeブランチを切る
    • (A)CS確認依頼が必要なほど大きい機能の場合は、developにマージせずにcs/20201215 などというブランチを切ってそこにマージする->CS環境にデプロイされる
    • (B)CS確認依頼が必要ない小さな機能の場合は、普通にdevelopにマージする->DEV環境にデプロイされる
    • (A)の時は、CS環境のURLと変更点を共有してCSに連携
    • (B)の時は、エンジニアだけでDEV環境でデバッグしてクイックに本番まで持っていく

というような感じです。上記の(A),(B)は下記のようなイメージです。

(A)CS確認依頼が必要なほど大きい機能の場合
スクリーンショット 2020-12-14 15.28.49.png

(B) CS確認依頼が必要ない小さな機能の場合
スクリーンショット 2020-12-14 15.28.58.png

要はどうGit flowを拡張したか?

変更点は下記です。

  • cs/ というブランチを作った
  • feature/ ブランチのマージ先に、developの他にcs/ ブランチが追加した(事前にCSに確認にしたい時のみこちらにマージ)
  • cs/ ブランチで確認が済んだ機能は、改めてfeature/ -> developでPRを作り、普通にリリースフローに乗せる(あくまで、Git flowに則る)

半年くらい運用してみて

銀の弾丸にはならなかったです(苦笑)

運用する上で起こった困りごとは、主に下記です。

  • CS環境にデプロイすべきか否か?の判断が属人的になり、これはcs/ ブランチを切るべき?という疑問が各所で発生する
  • cs/ ブランチで回避するほどは、developに機能が上がってこない

などなどです。

ただ、勿論メリットもありました。

  • 一旦CS環境で確認する?といった形で、CS環境が便利な仮デプロイ場所として一定の役割を果たした
  • "CSと連携するのが大事そう"という空気になったので、十分な連携が取れないまま本番まで上がってしまい、混乱を招くということが減った(気がする)

などなどです。

この辺りの運用は、
チームメンバーの人数、タイプ、組織体系、プロダクトとして何を重視して進める時か?(グロースハックか基盤強化か等)などに依存して最適化の形も凄いスピードで変わっていくので、
日々試行錯誤するしかないなあということも再確認できました。

特に、アトラエのように、特定のPdMのようなメンバーはおかず、
現場の意思決定はできる限り各人に任せ、自律分散的に働いていくチームでは、この辺りの試行錯誤を辞めないことが大事なのかなあと思ったり。

もっとこうした方がいい、などあれば是非知りたいので、ご指摘いただけると嬉しいです。

今回は以上となります。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0