Skip to content

Instantly share code, notes, and snippets.

@fujimaki-k
Last active March 12, 2024 03:03
Show Gist options
  • Save fujimaki-k/21196aa7cdad40a6e6e5b323c73fa714 to your computer and use it in GitHub Desktop.
Save fujimaki-k/21196aa7cdad40a6e6e5b323c73fa714 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 ブランチに対して修正のプルリクエストを送ります。
  • 大規模な修正になる場合、一度、切り戻しを行った上で再度この手順に沿って作業を進めます。
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment