Skip to content

Instantly share code, notes, and snippets.

@peco8
Forked from fujimaki-k/Releaseflow.md
Created June 21, 2020 14:28
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save peco8/2089ca7f77186458507d7842d1fa9b56 to your computer and use it in GitHub Desktop.
Save peco8/2089ca7f77186458507d7842d1fa9b56 to your computer and use it in GitHub Desktop.
リリースまでの流れ

リリースまでの流れ

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

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

2. プログラムの開発とテスト

  • ローカル環境で機能を開発しテストを行います。
  • テストが通ったらフィーチャーブランチの履歴を一つにまとめ、リモートリポジトリに push します。
git rebase -i HEAD~3 # 3つ前までのコミットをまとめる場合
git push origin feature/new_feature

3. プルリクエストの作成とマージ(feature → develop)

  • feature ブランチから develop ブランチへプルリクエストを送ります。
    • JIRA などのチケットの単位でプルリクエストを送ります。    - 一度に大きなプルリクエストを送ると、レビューする人の負担になります。
  • プルリクエストした内容のレビューを依頼します    - レビューを依頼する前には、まず自分でレビューをしてみましょう。    - レビューをするときは、以下のような点に気をつけます。        - 仕様を満たしているか         - セキュリティーは大丈夫か - 速度や、負荷の面で問題は無さそうか        - テストは書いてあるか    - フォーマットや好みの問題レベルの指摘はいりません。
  • プルリクエストの内容に問題が無ければ、変更をマージします。    - 他にもメンバーがいる場合、自分ではマージを行わず他のメンバーにマージを依頼します。
    • マージを依頼されたときには、マージされるコードに問題が無いかどうかを確認した上でマージをしてください。
  • プルリクエストの内容を修正する場合 git push -f コマンドを使います。
git rebase -i HEAD~~ # 2つ前までのコミットをまとめる
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 ブランチへプルリクエストを送ります。
  • リリースする機能に関わった全員がプルリクエストの内容を確認します。    - 以下の2点を重点的に確認してください 1. リリース予定の機能が全て含まれていること 2. リリース予定に無い機能が含まれていないこと
  • 全員が問題がないことを確認しリリース担当者がマージを行います。
    • チャットで問題がないことを報告してもらったり、Bitbucket の承認機能を使って確認をします。

8. デプロイ

  • マスターへのマージが完了したらリリースバージョンのタグを作成しデプロイします。
    • これらの作業はコマンドを入力するのではなく、Jenkins のジョブなどを使って自動で行えるようにします。
git tag v1.0.0
git push origin v1.0.0

9. 動作確認

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

10. 不具合の修正

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

peco8 commented Oct 18, 2020

正直コレは少し面倒臭すぎるだろ、さすがに

@peco8
Copy link
Author

peco8 commented Oct 19, 2020

というかこれは A successful git branchというやつだな、前の会社で使っていた。
うーん、微妙。正直面倒くさい。

@peco8
Copy link
Author

peco8 commented Oct 19, 2020

@peco8
Copy link
Author

peco8 commented Oct 19, 2020

feature branch > run test
develop branch > build and create PR for lab 環境
master branch > build and create PR for pro 環境

@peco8
Copy link
Author

peco8 commented Oct 19, 2020

@peco8
Copy link
Author

peco8 commented Nov 2, 2020

デメリット
feature毎にリリースまで面倒をみる必要がある。
developにマージしたからといってそのうち自動的に反映されるわけではないため、featureブランチの存在が忘れられると永遠にリリースされないということになってしまう。
とはいえタスク管理ツールのチケットとfeatureブランチを対応させておけばあまり困ることはないと思う。
Tipsとしては、featureブランチからdevelopへのPullRequestを出す時に、同時にmasterへのPullRequestを作っておくと忘れにくい。
feature間でコンフリクトする可能性が高まる。
長期間masterに反映されずに開発されるfeatureがあると、他のfeatureをdevelopへマージする際にコンフリクトする可能性が高くなる。
developマージ時にコンフリクトする場合は、原因になったfeatureブランチとの調整が必要になる。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment