ニアショア管理者

新しいdevelopブランチが必要となるタイミングで、ブランチ追加依頼を出す。
（アーキチームにてJenkinsへのジョブ追加およびcore等のモジュールのバージョンアップを行う。）
成果物を受け入れ後、ブランチ作成から受け入れまでにあった資源の変更を、現在作業中のdevelopブランチへマージする。
developブランチの資源の品質を確保する。（Jenkinsのジョブが落ちていないこと。コーディング規約違反がないこと。など。）
納品時には、mainブランチに対してpull Requestを出す。

ニアショア開発者

機能単位でfeatureブランチを作成し、資源をfeatureブランチへpushする。
共通コンポーネントは各機能とは異なるfeatureブランチを作成する。
機能作成前には共通コンポーネントのレビューが完了し、developブランチに適用している状態にしておく。
機能作成完了後、developブランチへpull Requestを出す。

ニアショアレビュアー

ニアショア開発者からのpull Requestによるレビュー依頼を受け、レビューする。
レビュー指摘はpull Requestのコメント機能を使用する。
成果物に問題がないことを確認後、pull Requestを承認し、developブランチへ変更を適用する。
対象機能がサンプリングレビュー対象となっている場合は、pull Requestを承認せず、サンプリングレビュー依頼を出す。

受け入れ側ソースレビュー

ニアショアレビュアーからの依頼を受け、ソースコードレビューを行う。
レビュー指摘はpull Requestのコメント機能を使用する。
成果物に問題がないことを確認後、pull Requestを承認し、developブランチへ変更を適用する。

受け入れ担当者

1. mainへのpull Requestを受け、資源の内容を確認する。
2. 指摘がある場合は、pull Requestのコメント機能を使用して指摘をだす。
3. 成果物に問題がないことを確認後、pull Requestを承認し、mainブランチへ変更を適用する。
4. mainブランチにてマージによる問題が発生しないことを確認する。
5. mainブランチにて受け入れテストを実施する。
6. 不具合が発生したら、 不具合・仕様変更が発生したときは別でチケットを起票する。
7. masterへ変更をマージする。マージ後、masterブランチのタグを切る。

アーキテクト

グループ切り替えのタイミングで、parentやcoreのバージョンを上げる。
受け入れ完了後、不要となったJenkinsタスクは削除する。

1：develop-groupA作成から受け入れまで

• parent・core・entity：0.1.0を使用する。緊急リリースがあれば、0.1.1、0.1.2とバージョンアップを行う。
• common：『0.1.0-SNAPSHOT』を指定する。
• web・batch：『0.1.0-SNAPSHOT』を指定する。

develop-groupA受け入れ完了時

• parent・core・entity：受け入れ時のバージョンをそのまま使用する。
• common：『0.1.0』を指定する。
• web・batch：『0.1.0』を指定する。

3：develop-groupB作成から受け入れまで

• parent・core・entity：0.2.0を使用する。緊急リリースがあれば、0.2.1、0.2.2とバージョンアップを行う。
• common：『0.2.0-SNAPSHOT』を指定する。
• web・batch：『0.2.0-SNAPSHOT』を指定する。

4：develop-groupB受け入れ完了時

• parent・core・entity：受け入れ時のバージョンをそのまま使用する。
• common：『0.2.0』を指定する。
• web・batch：『0.2.0』を指定する。

5：develop-groupC作成から受け入れまで

• parent・core・entity：0.3.0を使用する。緊急リリースがあれば、0.3.1、0.3.2とバージョンアップを行う。
• common：『0.3.0-SNAPSHOT』を指定する。
• web・batch：『0.3.0-SNAPSHOT』を指定する。

6：develop-groupC受け入れ完了時

• parent・core・entity：受け入れ時のバージョンをそのまま使用する。
• common：『0.3.0』を指定する。
• web・batch：『0.3.0』を指定する。