ランサーズ Advent Calendar 2017 7日目の記事です。
はじめまして、9月にランサーズにジョインしました開発部の松岡です。
入社後すぐにグループ会社の QUANT社 で開発と、先月から初めて開発ディレクションをしています。
今回は、QUANT社における開発パートナーとの GitHub 運用フローの変更について書きたいと思います。
いきさつ
GitHub 運用フローの見直しを行う発端になったのは、開発当初から Rails の Migrate 機能を利用してリリース時に capistrano で「./bin/rake db:migrate」を実行していたが、Migrate に時間を要する変更もリリース時に実行されてテーブルがロックし障害が発生したのが発端となります。
また、マイグレーション問題の他に、開発パートナーへの依頼は、GitHub の issue とチャットでの優先順位の話し合いによって開発が進めれていたため、途中からジョインしたメンバーが開発状況のキャッチアップするのが難しい状況があるなどの理由から GitHub 運用の見直しを行いました。
真っ先に解決したかった問題
初期の GitHub 運用フロー
- merge
- 開発パートナー、ランサーズ開発ともに好きなときにマージが可能
- release
- ランサーズ開発が適宜リリース
解決したい問題
- merge が自由
- migration が自動
merge が自由
開発パートナーによるマージが自由だったため、障害が発生した際の master を配る場合に、どこまで本番での動作検証が行われたかが瞬時に分からない状況が発生し復旧対応に時間がかかっている。
Migration が自動で行われる
サービス規模の小さい初期開発時のリリース作業を軽減するために capistrano でのリリース時に自動マイグレーションがされるようになっており、現状は、テーブルサイズが大きくなっている。
開発パートナーは、本番運用されているテーブルサイズを把握していないため、大きなテーブルを ALTER する Migration が書かれていたためテーブルロックが発生し障害発生の原因となった 。
解決方法
この２つの問題は GitHub のフロー自体は変更せずに、開発パートナーとランサーズ開発のロール分けとデプロイ設定の変更によって対応しました。
merge が自由の対応
開発パートナーが作成した PR は、開発パートナー側でレビューを行い、レビューが通った PR にはラベルに レビュー済みマージ待ち を付けることで issue が完了。PR のマージとリリースはランサーズ開発によって レビュー済みマージ待ち のラベルがついている PR について行うようにロールを分けを明確にしました。
ランサーズ開発が作成した PR に関しては、初期の通りいつでもマージ/リリースが可能としています。
Migration が自動で行われるの対応
本番環境での capistrano による自動 Migration を使わないようにしました。代わりに、Migration が含まれてる PR の場合はラベルに 本番作業あり(Migration 等) を設定し、マージの前にサーバの負荷状況や Migration の内容を見てランサーズ開発によってテーブル定義の変更を行うようにしました。
次に解決したくなった問題
先の解決で、開発フロー起因の障害はなくなりましたが、開発パートナー・ランサーズ開発共に低コストで GitHub での運用ができるように GitHub フローを変更します。 (2017/12/07 の段階では移行最中なので、うまく運用が回らなかった場合は後日技術ブログで追記します)
解決したい問題
- 開発状況の管理が二重管理なのでなくしたい
- リリースのタイミングをよりコントロールしたい
開発状況の管理が二重管理なのでなくしたい
開発パートナーへ依頼する内容は、GitHub の issue とチャット上での優先順位の話し合いによって開発が進めれており、進捗はスプレッドシートで管理されているので管理が面倒となっている。
リリースのタイミングをよりコントロールしたい
現状のGitHub 運用フローだと、ランサーズ開発によるマージのタイミングによってはコンフリクトが発生し、都度、開発パートナーにコンフリクト解消を依頼が発生している。
解決のための GitHub 運用フロー
解決方法詳細
2つの問題を解決するために、開発パートナーの Organization にあるリポジトリを GitHubの標準の機能でランサーズのリポジトリに移譲し、GitHub の運用フローを変更します。
開発状況の管理が二重管理なのでなくす対応
ランサーズでは現在 zenhub を標準のタスク管理として利用しているため、ランサーズの Organization に移すことで zenhub が利用が可能となります。そのため、ランサーズ開発としては zenhub だけで issue の進捗の管理を行えるようになります。
リリースのタイミングをよりコントロールしたい対応
不定期だったリリースに定常リリース日を設けることによって GitHub 運用フローの変更を行います。
開発パートナー・ランサーズ開発共通
- 毎週水曜日に定常リリース
- リリースする内容はランサーズ Organization の master ブランチ
開発パートナー
- ランサーズ開発によって、weekly release ブランチ が作成され、同時に master に PR が作成されている。PR には対応したい issue のリストと優先度が書かれている
- PR の向き先は weekly release ブランチ
- weekly release ブランチ から作れた PR は週一度の水曜日の定常リリース時に取り込まれる。コンフリクトした場合は、ランサーズ開発によって解消される
- 緊急度の高い issue は master に向けて PR を作成し、ランサーズ開発によってマージ/リリースされる
ランサーズ開発
- PR の向き先は master ブランチ
- PR のマージは週一度の水曜日の定常リリース時に取り込まれる
- 緊急度の高い PR はいつマージしてリリースをしてもよい
今回の運用フローの変更で、問題になる点としては、1週間では終わらない issue と、１週間で終わると当初思っていたが１週間で終わらなかった issue の取扱があると思います。
前者は、その issue 専用の relese ブランチを作成し、weekly release ブランチと同様の運用で行う。後者は、開発パートナーによって、翌週の relese ブランチの方に再度 PR を作成してもらう方針です。
ボツの GitHub 運用フロー変更案
GitHub 運用フロー
ボツになった理由
最初に、GitHub 運用フローの変更を考えたときに OSS のリポジトリ運用フローのように考えましたが、詳細を詰めるといくつか問題があることに気づきました。まず最初にみて思うのが、マージのポイントが多い所です。開発パートナーにはできる限り開発に集中してほしいためよりシンプルなフローにしたくなりました。
次に、誰がパートナーの Organization に weekly release ブランチを作成/マージをするのかです。せっかく Organization を分けたにランサーズ開発の方で開発パートナーのブランチを操作するのは運用の方針としてはよくない感がありました。
さいごに
開発の段階や組織によって、適している GitHub 運用フローが様々ありますが、今回は、QUANT社の開発パートナーと共同で開発を行い、開発初期の大規模機能拡張のフェーズから安定運用が必要なフェーズに移ってきている中での GitHub 運用フローの変更について書かせていただきました。
こちらの記事で、開発初期フェーズの GitHub 運用から移行を考えている方の参考になれば幸いです。