INTARFRMを使ったWebアプリ開発のGitブランチ戦略

#GitLab
#Git
#INTARFRM

この記事を書いたチーム：frontier

想定開発規模
・画面数：50～
・製造参画人数：10人以上

INTARFRMについて
“「INTARFRM」は、設計支援機能、開発支援機能、実行機能、保守支援機能を有するソフトウェアおよびドキュメントからなります。ソフトウェアライフサイクル（要件定義、設計・開発、運用・保守）全体で首尾一貫した手法を確立しており、「INTARFRM」を活用することで、システム開発者はビジネス環境の変化に迅速かつ柔軟に対応して効率的にシステムを構築または改良することができます。「INTARFRM」は、お客様のソフトウェア資産を継続的に発展させることで、お客様のビジネス強化に貢献します。”
引用：https://www.fujitsu.com/jp/solutions/infrastructure/dynamic-infrastructure/afw/

今回ご紹介するINTARFRMを使った開発とは、「開発支援機能」を使用したWebアプリケーションの開発を指します。具体的には、まずINTARFRM外で作成した詳細設計情報をINTARFRMに入力し製造のベースとなるソースをINTARFRMで自動生成します。
このソースに手実装を追加してWebアプリケーションを構築していくのですが、本記事はコンフリクトや開発手戻りを極力防ぐためのソース管理方法の紹介です。

INTARFRM自動生成の制約
INTARFRMにはフォーム、プログラムという概念があり、下記手順で入力と自動生成を進め③→⑤→⑥の順番で開発ソースに反映していく必要がある。この手順に従わないと、１画面１担当者で製造を進めていく際に自動生成ソースを開発ソースに反映する段階でコンフリクトが発生してしまう。
　① プログラム作成
　② ①で作成したプログラムに所属する全フォームを作成（設計情報は未入力で良い）
　③ プログラム単位で自動生成
　④ フォームに設計情報を入力
　⑤ プログラム単位で自動生成
　⑥ ⑤で生成したソースに手実装を追加
これらを前提としたソース管理の仕方をご紹介していきます。

1.Gitブランチ戦略
- 1-①ブランチの分け方
- 1-②ソース履歴のでき方（1-①ブランチの分け方を守った例）
2.GitLabでの開発作業手順

1.Gitブランチ戦略

【エンジニア募集中】フルリモート可◎、売上/従業員数9年連続UP、平均残業8時間、有給取得率90％、年休124日以上 etc.　　詳細はこちらから＞

1-①ブランチの分け方

参考：mainブランチで全ての作業を並行で進めることの問題点（×印の箇所）

・機能実装 – Bをリモートに強制プッシュした場合、以前のコミットバグ修正 – Aの変更内容を元に戻す上書きをしてしまう可能性がある。
・終業時などにリモートに作業途中のソースをpushすることが事実上不可能（下記理由）なため、ローカルPCの故障や作業者の欠勤時に開発作業を引き継ぐことができない。
　- 理由1：作業者全員が終業時に作業途中コミットのプッシュを同時に行おうとすると、
　　　　　mainブランチの最新をローカルに取得してプッシュをやり直す作業が必要になる
　　　　　（作業者が15人いたら最後の人はこれを14回行う必要がある）
　- 理由2：上記を防ごうとリモートに強制プッシュした場合、別の作業者の作業中コミット
　　　　　が失われる可能性がある

1-②ソース履歴のでき方（1-①ブランチの分け方を守った例）

実際に作業するブランチも図示すると次のようになります。
またdevelopブランチにマージする際は必ず最新のdevelopブランチを作業ブランチに取り込んでからdevelopブランチにマージするようにします。

以上のように、ソースをmainブランチに反映する際の手戻りを防ぎや作業途中のリモートバックアップが可能になります。

2.GitLabでの開発作業手順

ここからは先に紹介したGitブランチ戦略を用いた開発を容易にするGitLabでの開発作業手順を紹介します。

2-①イシューの作成

1-① a～g の作業に対してイシューを作成（１作業１イシューが基本）

■イシューの作成方法
　 1.　メニューのイシューをクリック
　　

　 2.　右上の新規イシューボタンをクリック
　　

　 3.　タイトルを入力して作成イシューボタンをクリック
　　

■イシューのタイトル命名規則（推奨）
　…イシューのタイトルは後述するマージのコミットメッセージに含まれる
　※{}は可変部分
　　　・a. chore: {プログラムID} ダミー生成
　　　・b. feat/pc: {プログラムID} {共通処理名}
　　　・c. feat: {フォームID} {業務名} {機能名}
　　　・d. feat/c: {共通処理名}
　　　・e. update: {フォームID} {業務名} {機能名} {修正の概要}
　　　・f. fix/○○
　　　　　　1.fix/chore: {プログラムID} ダミー生成 {修正の概要}
　　　　　　2.fix/pc: {プログラムID} {共通処理名} {修正の概要}
　　　　　　3.fix: {フォームID} {業務名} {機能名} {修正の概要}
　　　　　　4.fix/c: {共通処理名} {修正の概要}
　　　　　　5.3と同じ
　　　・g. refactor/○○
　　　　　　1.refactor/pc: {プログラムID} {共通処理名} {修正の概要}
　　　　　　2.refactor: {フォームID} {業務名} {機能名} {修正の概要}
　　　　　　3.refactor/c: {共通処理名} {修正の概要}
　　　　　　4.3と同じ

2-②マージリクエストの作成

開発実作業完了時に作業ブランチから開発ブランチへのマージをするためのリクエストを開発作業前にあらかじめGitlab上のイシューから作成しておきます。（Draft(下書き)状態で作成されます）

マージリクエストは下記オプションで作成されるように設定することを推奨します。
（コミット履歴をきれいに保つ目的）
　・squashコミット
　　（作業ブランチの複数コミットを１つにまとめた別のコミットをマージすること）
　・squashコミットメッセージの初期値：{マージリクエストのタイトル}
　・マージコミットメッセージの初期値：
　
　・マージリクエストのタイトル　＝　Resolves “{イシューのタイトル}”
　　（イシューからマージリクエストを作成した場合のみ）
　・ターゲットブランチは開発ブランチ
　　（イシューからマージリクエストを作成した場合のみ）

■マージリクエストの作成方法（イシューから）
　 1.　マージリクエスト作成ボタンをクリック
　　※作業ブランチも同時に自動作成されます
　　

　 2.　遷移先画面で作成マージリクエストボタンをクリック
　　・Asignee、マイルストーン、ラベルはイシューから引き継がれます。
　　・（推奨）説明欄の Related to #3 を　Closes #3に変更（マージ実行時にイシューをクローズする設定。
　　　#の後ろの数字はイシュー連番）
　　・（推奨）Reviewerにレビュワー担当を設定する
　　・（推奨）マージオプション Delete ~~ をチェック（マージ実行時に作業ブランチを削除する設定をON）
　　　　

　 3.　マージリクエスト作成後の画面
　　

2-③開発実作業

・2-②のマージリクエスト作成時に作成されている作業ブランチをローカルに取得する
・上記で取得した作業ブランチにcheckout
・ソースの変更を作業ブランチにコミットしていく（マージ時にsquashコミットで
　マージするため、作業ブランチ内のコミット単位は制限なし）

　作業時推奨事項
　・毎日の作業終わりに作業ブランチにコミットしてリモートにプッシュする
　　　※コミットメッセージは「WIP: ○○」(Work In Progressの意)がおすすめ
　　　目的：作業途中の状態をリモートにバックアップ（パソコンの故障や作業者の欠勤に
　　　　　　対するリスクヘッジ目的）
　・開発ブランチ、mainブランチにマージできる人を限定
　　　目的：開発ブランチ、mainブランチの履歴を見やすくするため
　　　権限が Maintainer 以上の人のみマージ可能になる設定

2-④開発ブランチへのマージ

・実作業が完了したらリモートの作業ブランチにプッシュ（作業担当者）
・（推奨）プッシュ後にレビュワーにレビュー依頼（作業担当者）
・（推奨）レビュー実施して結果を作業担当者にフィードバック（レビュワー）
・（推奨）修正を確認したらマージリクエストの承認ボタンを押す（レビュワー）
・マージリクエストのマージボタンを押してマージを実行する（レビュワー）
　※Maintainer以上の権限者のみマージ実行が可能な設定の場合

マージリクエストの承認・マージ実行
マージリクエストの承認ボタン