はじめに
事業会社で取り入れているフローなんかを見ると「細かくてすごいな〜」と思いつつ、受託でやるには現実的に厳しいと思ったり…
しかしながら、フローを疎かにし過ぎると色々なリスクが生じることも…
**「程よい」のレベル感は人それぞれ・案件によっても違うと思いますが、この投稿では間を取って多くの人が「まぁこれで事足りるよね」**って言うようなものを作りたいと思ってます。
まずは、筆者がベースとなるフローを考察するので、その後みなさんの意見を取り入れてつつブラッシュアップしていければと考えてます！
前提
リモートリポジトリの場所
- Backlog
フローが大きく変わる訳ではありませんが、一旦はBacklog想定にします。
想定されるリスク
- デグレしてしまう
- 最新ファイルの在りかが分からなくなる
よく起こるであろうこの辺りをリスクヘッジ出来るフローにしていこうと思います。
サーバ環境
- 本番環境
- ステージング環境
- 開発環境
想定されるリスクを回避するために、最低限この３つの環境がある想定にします。
CMS
導入していない想定にします。
ルール系
ブランチ
master
- 本番公開用のブランチ
- このブランチから本番環境にファイルをアップ
- 基本的には、本番環境とファイルがイコールになっていること
release
- ステージング公開用のブランチ
- このブランチからステージング環境にファイルをアップ
- 基本的には、ステージング環境とファイルがイコールになっていること
作業ブランチ（課題番号_作成者名）
- 作業を行うためのブランチ
- このブランチから開発環境にファイルをアップ
- 基本的には、1チケット1ブランチになっていること
コミット
ここがいくらでも細かく出来てしまう項目なので、難しいところです…
筆者の個人的な意見としては、コミットの粒度はある程度各自に任せつつ、
メッセージには最低限何をしたか分かるように書いてくれれば良いかな〜と思ってます。
※内容は細かいほど良い
プルリクエスト
- 詳細：何の作業をしたか分かるように記載し、更新したURLも合わせて記載すること
- 担当者：マージ承認者（レビュアー）を設定すること
- 「ファイル」タブを選択し、作業したファイルに誤りが無いかを確認すること
※マージ承認者は、予め担当者を決めておく
Gitのフロー
- masterをプル（最新の状態にする）
- masterから作業ブランチを作成
- 作業ブランチにて開発
- ※ステージング環境・本番環境には勝手にアップしないこと
- ファイルをプッシュ
- 作業が完了したものは、作業ブランチ→releaseへのプルリクエストを作成
- releaseにマージされたものをステージング環境にアップ
- 公開OKとなったものは、release→masterにプルリクエストを作成
- masterにマージされたものを本番環境にアップ
- 最終承認が取れた後、作業ブランチを削除
releaseにマージされたいくつかの作業のうち先に１つだけ公開したい場合などは、作業ブランチ→masterへのプルリクエストを作成を許容とする。
※実際はもっといい方法がないかな〜とモヤモヤしているところ…
コンフリクトが起きた場合
マージ承認者や先にマージした人と内容を確認しながら解決すること。
軽微な対応の場合
ここは決めの問題だが、「一箇所テキストを修正するだけ」といったすごく軽微な対応の場合、マージ承認者を介さず自らマージしてOKといったルールは適宜決めていく。
まとめ
とりあえずは細かくなりすぎず…かと言って疎かにならないようなフローにまとめてみましたが、まだまだ改善の余地はあるんだろうな〜と思ってます。
ぜひ、みなさんの知恵をお貸しいただけると…！