■前提 Gitとは?
Gitはソースコードの変更履歴を記録管理するためのツールです
Linuxのカーネルソースの管理のために作られ今ではほぼ全ての商用開発で利用されています
■Git管理の流れ
Gitの説明はインターネット上に多くありますがGitに触れていないとわかりにくいかもしれません
Git管理の流れの一例を示します。3章でGit管理の流れを実践します
2章ではgit cloneだけ行います
◯本番用=masterブランチ
最初の状態をmaster(main)ブランチとします
masterブランチは本番環境の反映用にすることが多いです
◯開発用=developブランチ
開発環境用にdevelopブランチをmasterブランチから枝分かれで作成します
developブランチを変更しても後述のマージをしないとmasterブランチに反映されません
本番(master)へ影響せず変更が可能ですがここまでならRPGソースを本番機と開発機で別に
管理している状態と同じです
◯機能追加・バグ修正用ブランチ=開発者用
通常developブランチを直接変更することはなく、各開発者が機能追加毎またはバグ修正毎にブランチを追加します
master → develop → feature/#機能追加番号 や fix/バグ修正番号
feature/fixブランチの変更は、
・開発者のBob=PC(ソース)
・IFSの開発者のホームディレクトリ((一時ソース)
・開発者の個人ライブラリ(PGM)
にのみ存在し開発環境のアプリライブラリ(ここではFLIB)に影響しません
→なのでGit開発には個人アカウントが必要です
◯マージリクエストとマージ
開発が終わったら開発者はマージリクエストをWebインターフェースで行います
マージリクエストはfeature/fixブランチの変更点をdevelopブランチに反映する=マージするレビュー依頼です
レビュー依頼なので担当者を割り当てます
開発者が兼ねることもできますが通常は別の人を割り当てます
レビュー担当者はマージリクエストの内容を確認(要件・仕様とコードの差分を確認)します
NGなら差戻し理由を記載し開発者に修正を依頼します
OKならWeb I/Fで[マージ]ボタンを押すとdevelopに変更点が反映=マージされます
→なおdevelopブランチに反映されると自動でコンパイルし必要なら定型テストを行い
開発環境に反映する機能がCI/CDです
◯developからmasterへのマージリクエスト
開発環境で動作確認してOKならdevelopからmasterへのマージリクエストを出します
feature/fixブランチの時と同様にレビューしOKならmasterブランチに[マージ]し本番反映します
＊マージしたが後でバグが見つかって切り戻したい時は、変更を細かい単位
(上記ブランチより細かいコミット)で管理しているので必要なところまで
gitコマンド一つで切り戻せます
＊Web I/Fにいつどのような修正をして各ブランチにマージしたかツリー状に
表示されるので変更管理が容易になります
■Gitサービス(どのGitを使うか?)
◯クライアント
Gitクライアントは開発時ならBob(VSCode)標準のGitツール(GUI)でしょう
ブランチの作成・マージなどはWeb I/F上で行うのがよいように思います
切り戻しなどの作業はgitコマンド(CLI)になるように思います
◯サーバ
大きく3つの選択肢があります
1)SaaS(GitHub, Gitlab, GitBucket他)
GitレポジトリをWeb上で管理できIssue等各種開発支援機能が利用可能なクラウド上のサービスです
[メリット]
サーバ管理が不要
[デメリット]
プライベートリポジトリの制限(無料でも使えるが制約あり)
→設定を間違えるとソースが一般公開されてしまう
クラウド上に存在するため社内で閉じた環境にできない
社内オフィスのsshブロックを解除する必要がある(SaaSなのでIP固定とは限らない)
2)IBMクラウドのGitlab
PVSと同じくIBMクラウドにGitlabサーバが用意されています
公式 : https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-gitlab&locale=ja
参考 : https://qiita.com/spssfun2017/items/1f7063c60dd13021ea99
[メリット]
サーバ管理が不要
[デメリット]
IBMクラウド利用でVPNを張っているなら社内の閉じた環境になります
3)Gitlab CE
Gitlab CE(Community Edition)はGitのWeb機能を自社サーバにインストールできるGitlabのオープンソース版です
[メリット]
社内の閉じた環境に置ける
例1) 社内のIBM iと同様のプライベートセグメントの仮想サーバに
Gitlab CEをインストールする
例2) VPNでつながったAWSのプライベートセグメントのVMに
Gitlab CEをインストールする
例3) AWSのVMにGitlab CEをインストールし固定IPを割振る
AWS側はオフィスの固定IPのみを許可し
オフィス側ルータはGitlab CEに割振った固定IPのみsshを許可する
[デメリット]
サーバ管理が必要
脆弱性のため頻繁にバージョンアップが必要
サポートが使えない(サポートが可能な有償ライセンスのEE版(Enterprise Edition)もあり)
今回は既存のGitlab CEを使いました