kulamochi/Releaseflow.md

## Releaseflow.md

      
    Raw
  

              Releaseflow.md
            
          
    リリースまでの流れ

1. フィーチャーブランチの作成


develop ブランチから新たに作成する機能のためのフィーチャーブランチを作成します。

git branch feature/new_feature develop
2. プログラムの開発とテスト


ローカル環境で機能を開発しテストを行います。
テストが通ったらフィーチャーブランチの履歴を一つにまとめ、リモートリポジトリに push します。

git rebase -i HEAD~3 # ３つ前までのコミットをまとめる場合
git push origin feature/new_feature
3. プルリクエストの作成とマージ（feature → develop）


feature ブランチから develop ブランチへプルリクエストを送ります。

JIRA などのチケットの単位でプルリクエストを送ります。
一度に大きなプルリクエストを送ると、レビューする人の負担になります。


プルリクエストした内容のレビューを依頼します

レビューを依頼する前には、まず自分でレビューをしてみましょう。
レビューをするときは、以下のような点に気をつけます。

仕様を満たしているか
セキュリティーは大丈夫か
速度や、負荷の面で問題は無さそうか
テストは書いてあるか


フォーマットや好みの問題レベルの指摘はいりません。


プルリクエストの内容に問題が無ければ、変更をマージします。

他にもメンバーがいる場合、自分ではマージを行わず他のメンバーにマージを依頼します。
マージを依頼されたときには、マージされるコードに問題が無いかどうかを確認した上でマージをしてください。


プルリクエストの内容を修正する場合 git push -f コマンドを使います。

git rebase -i HEAD~~ # ２つ前までのコミットをまとめる
git push -f origin feature/new_feature
4. 開発環境での動作確認


プルリクエストがマージされたら、開発環境（development）にデプロイして動作を確認します。

5. リリースブランチの作成


リリースに必要な全ての機能が develop にマージされ動作確認がとれたら、release ブランチを作成します。
既に release ブランチが存在する場合、削除して作り直すか、rebase します。

# ブランチを削除して作り直す場合
git branch -d relase
git branch release develop # release ブランチの作成

# rebase する場合
git checkout release
git rebase develop
6. ステージング環境での動作確認


リリースブランチを作成したら、ステージング環境（staging）にデプロイして動作を確認します。
ステージング環境での動作確認に問題があった際は、release ブランチに対して修正のプルリクエストを送ります。
修正後に動作確認を行い、問題が解決したことを確認したら develop ブランチに対して修正のプルリクエストを送ります。

7. プルリクエストの作成とマージ（release → master）


release ブランチから master ブランチへプルリクエストを送ります。
リリースする機能に関わった全員がプルリクエストの内容を確認します。

以下の２点を重点的に確認してください

リリース予定の機能が全て含まれていること
リリース予定に無い機能が含まれていないこと


全員が問題がないことを確認しリリース担当者がマージを行います。

チャットで問題がないことを報告してもらったり、Bitbucket の承認機能を使って確認をします。


8. デプロイ


マスターへのマージが完了したらリリースバージョンのタグを作成しデプロイします。

これらの作業はコマンドを入力するのではなく、Jenkins のジョブなどを使って自動で行えるようにします。


git tag v1.0.0
git push origin v1.0.0
9. 動作確認


本番環境へのデプロイが完了したら、動作確認を行います。

10. 不具合の修正


本番環境での動作確認で不具合が見つかったときには hotfix ブランチを作成して不具合を修正します。
修正が軽微な場合 hotfix ブランチから直接 master にプルリクエストを送ります。
修正の結果、正しく動作することが確認できたら develop ブランチに対して修正のプルリクエストを送ります。
大規模な修正になる場合、一度、切り戻しを行った上で再度この手順に沿って作業を進めます。