運用フローについて

前準備

• ローカルでの動作確認用の環境を構築しておく

JIRAのチケットSAR-000の対応をする人

1. 最新のdevelopブランチからトピックブランチSAR-000-setsumeiを作成します
2. SAR-000-setsumeiでチケットの内容に応じた対応をします
3. ローカルでの動作確認を行います
4. 問題がなければ、developブランチに向けて、PRを作成します。PRはテンプレに従ってください。
5. PR作成後も作業を続ける場合、PRのタイトルの頭に[WIP]をつけることで「まだ作業中です」という意思表示ができます。

• WIP = work in progress
• 作業中にdevelopブランチが進むことが考えられます。
• したがってトピックブランチでの作業時は、常にdevelopの最新でrebaseしておくことをお勧めします。
  • 未コミットの変更がない状態にしたトピックブランチにて、下記コマンドでrebaseできます。
  • git rebase develop && git push -f origin SAR-000-setsumei
• コンフリクトへの対応は基本的にトピックブランチ作成者側で解消しておきましょう。

1. (developブランチの最新でrebaseした上で、)コードレビューに回せるPRが作成できたら、PRのタイトルから[WIP]を外します。
2. PRへのリンクをJIRAのチケットSAR-000のコメントに貼ります。
3. PRを誰かにアサインし、slckやJIRAでPRお願いしますと声をかけましょう。

ローカルで動作確認する人

1. 対応するPRを決めたら担当を自分に変更します。
2. ローカルの環境をステージング(最新のdevelop)と同等の環境に整えます。
3. マージ後の環境をローカルで作成します

• (最新のdevelopにて)git merge --no-ff --no-commit origin/SAR-000-setsumei

1. 動作確認を行います。問題なければ git merge --abortでローカルを元に戻しておきましょう。
2. PRのMerge pull requestボタンを押します。その勢いで Delete branch ボタンを押します（もし失敗してても戻せる）
3. しばらくすると、ステージング環境に反映されます。そこで再度動作確認を行います。
4. 問題がなければ、developブランチからmasterブランチへのPRを作成します。(PRのタイトルは「本番環境リリース:[SAR-000]」)
5. 問題がなければ、PRのMerge pull requestボタンを押します。
6. しばらくすると、本番環境に反映されます。そこで再度動作確認を行います。
7. チケットの担当者にマージしたことを伝え、作業完了となります。

ステージング環境で動作確認する人

• ローカルで動作確認する人とほとんど同じです
• 2. でステージング環境/opt/workspace/pyconjp-stg-2016がdevelopの最新と同じであることを確認します
  • pyconjpユーザーで/opt/workspace/deploy-scripts/update.sh staging 2016と叩いてもOK
• 3. でマージ後の環境をステージング環境で作成します
  • (最新のdevelopにて)git merge --no-ff --no-commit origin/SAR-000-setsumei
  • 動作確認を行い、問題なければ git merge --abortでローカルを元に戻しておきましょう。
• 5.以降はローカルで動作確認する人と同じです。