はじめに
今回、IBM i の若手技術者を対象に仲間づくりと最新技術情報の収集を目的に日本 IBM 様が主催する「IBM i 若手技術者コミュニティ」に参加させていただきました。
IBM i 次世代エンジニアのための技術力向上と情報交換を目的とした、若手エンジニアのためのコミュニティ
この記事では、私たちチームCの活動内容についてご紹介します。
テーマ
Git を導入し、IBM i 上でソースコード管理をしてみよう!
Git を選んだ理由
Git を導入することで、ソースのバージョン管理やマージ作業をより効率的に行えるのではないかと考えました。
特に、従来のように手作業でコピーを繰り返し、「PGM1, PGM1@, PGM1@@…」といった状態になってしまうことがありましたが、こうした問題を解決する有力な手段になると期待し、実際に Git を試してみました。
私たちグループメンバーの多くは日頃、ネイティブ環境1で開発しているため、その環境で作成したソース・ファイルを Git で管理することをテーマとしました。
また、Rational Developer for i (以下、RDi)にも Git のプラグインがあることを知り、RDi による Git 管理が可能か検討しました。
Git とは
Git とは、一言でいうとソフトウェア開発で広く利用されている「分散型バージョン管理システム」です。
分散型バージョン管理システムの特徴として中央サーバーだけに依存せず、各開発者の手元にもリポジトリ（履歴のコピー）があることです。
Git でできること
-
ソースコードのバージョン管理
ファイルの変更履歴を追跡し、過去の状態へ戻したり差分を確認できる。 -
リリースの管理
プロジェクトごとの開発差分を履歴として残し、開発者単位で管理できる。 -
編集履歴の管理
開発者が任意の単位でコミットできるため、作業内容を記録できる。
Git についての詳細は、こちらのサイトがとても分かりやすくまとまっていますので、Git を知らない方はご覧ください。
結論
IBM i 上でも、RDi を含めて Git を使うことは可能でした。
ただし課題もあり、オープンソース開発のようにスムーズに活用できるわけではなく、IBM i に取り入れるには運用面や既存ソースの見直しが必要だと感じました。
IBM i のネイティブ環境で開発する際に直面する Git 管理の課題
ソースコードの二重管理
ソース・ファイルを Git に登録するには、統合ファイル・システム環境（以下、IFS 環境）やローカルに展開する必要があります。
そのため、二重管理となり、手作業によるヒューマンエラーが発生する可能性があります。
運用方法等を工夫しないと、Git 管理が形骸化する恐れがあります。
シフト文字による Git 管理時の変換リスク
IBM i のソース・ファイルは EBCDIC ベースで、シフト文字（半角/全角切替）を意識して保存されます。
そのため、Git で管理する際にソース・ファイルを変換し、再度ソース・ファイルに戻すと、誤変換が発生する可能性があります。
以下は注意が必要な例です。
① 元のソース・ファイル
「若手技術者」と「コミュニティ」が、それぞれシフトアウト／シフトインで制御されています。
② ソース・ファイルを変換（CPYTOSTMF）
変換後は、「若手技術者」と「コミュニティ」に対するシフトアウト／シフトインの制御が消えます。
③ ソース・ファイルを元に戻す（CPYFRMSTMF）
ソース・メンバーに戻しても、元の状態は再現されません。
IBM i 開発で Git を利用する際にそのまま取り入れた場合の概要図
以下は、IBM i 上、及び RDi で Git 管理をそのまま取り入れた場合の概要図です。
IBM i 上で Git 管理をそのまま取り入れた場合
RDi で Git 管理をそのまま取り入れた場合
どちらの場合も、Git 管理のためにソース・ファイルの変換が必要です。
通常、元のファイルはリモートリポジトリで履歴とともに管理されます。
しかし、IBM i 上で開発する場合、元のソース・ファイルはネイティブ環境に存在するため、本来であれば、リモートリポジトリからpullすべき作業も、ネイティブ環境のソース・ファイルを直接コピーして使いたくなるのではないでしょうか。
IBM i 開発で Git を活用できないのか？
IBM i 上で Git を使用すること自体は、RDi を含めて可能です。
- 個人の作業履歴管理ツール（作業メモ）として
- チーム開発における各開発者の作業管理ツールとして
便利に活用できる場面は十分にあります。
以下では、IBM i 上、及び RDi を使った Git 管理の方法を簡単に紹介します。
検証環境
- PUB400
- RDi 9.8.0.3
PUB400 の登録方法
サイトの案内に従い「氏名」「メールアドレス」「IBM i のユーザープロファイル名」を登録すると、後日、登録したメールアドレス宛にログイン情報が届きます。
こちらの記事を参考にさせて頂きました。
オープン系開発者が IBM i の環境構築から始めてみた ①
IBM i 上で Git 管理する方法
PUB400 には、あらかじめ Git がインストールされています。
そのため、PUB400 で Git を使用する場合は、IFS 環境の home ディレクトリに .profile ファイル2を作成し、Git のパスを登録するところから始めることができます。
① home ディレクトリに .profile ファイルを作成し、Git のパスを登録する
which git
export PATH=/QOpenSys/pkgs/bin:$PATH
② Git 管理したいディレクトリを作成し、そのディレクトリへ移動する
mkdir [ディレクト名]
cd [ディレクト名]
③ Git の初期設定をする
- ユーザー名
- メールアドレス
git init
git config –global user.name "ユーザー名"
git config –global user.email "メールアドレス"
ソース・ファイルを IFS 環境で Git 管理する際の基本的な手順
ネイティブ環境 → IFS 環境
① ネイティブ環境で開発したソース・ファイルを IFS 環境へコピーする
CPYTOSTMF FROMMBR('/QSYS.LIB/[ライブラリ名].LIB/[ソースファイル名].FILE/[メンバー名].MBR') TOSTMF('/HOME/[ユーザー]/[任意のディレクトリ]/[出力ファイル名].[メンバータイプ]')
② コピーしたファイルを Git の管理対象に追加する
git add [出力ファイル名].[メンバータイプ]
③ 管理対象の変更を履歴として保存する
git commit -m "メッセージ"
IFS 環境 → ネイティブ環境
① 必要に応じて、作業するブランチに切り替える
git checkout [ブランチ名]
② IFS 環境からネイティブ環境へソース・ファイルをコピーする
CPYFRMSTMF FROMMBR('/HOME/[ユーザー]/[任意のディレクトリ]/[出力ファイル名].[メンバータイプ]') TOSTMF('/QSYS.LIB/[ライブラリ名].LIB/[ソースファイル名].FILE/[メンバー名].MBR') MBROPT(*REPLACE) ENDLINFMT(*LF)
ネイティブ環境と IFS 環境間でソース・ファイルをコピーする際に簡略化する方法
ユーザー定義オプションの登録
ユーザー定義オプションを登録することで、毎回コマンドを入力する手間を省くことができます。
- ネイティブ環境 → IFS 環境
CPYTOSTMF FROMMBR('/QSYS.LIB/&L.LIB/&F.FILE/&N.MBR') TOSTMF('/HOME/[ユーザー名]/&L/&F/&N.&T') STMFOPT(*REPLACE) STMFCCSID(1208) ENDLINFMT(*LF)
- IFS 環境 → ネイティブ環境
CPYFRMSTMF FROMSTMF('/HOME/[ユーザー名]/&L/&F/&N.&T') TOMBR('/QSYS.LIB/&L.LIB/&F.FILE/&N.MBR') MBROPT(*REPLACE) STMFCCSID(1208) ENDLINFMT(*LF)
IFS 環境環境には事前に、ネイティブ環境のライブラリ構造と同様のディレクトリを作成する必要があります。
RDi を使って Git 管理する方法
検証環境の概要図
導入方法
EGit 導入
RDi は Eclipce ベースのため、Eclipce のプラグインである Egit が利用できます。
以下では、インストール、及び操作手順を紹介します。
こちらの記事を参考にしました。
IBM iのコード変更管理 ～オープンソースのGitを利用して、ソースコードや変更履歴情報を共有
① 「ヘルプ」 > 「新規ソフトウェアをインストール」 を選択
以下のエラーが発生した場合は、ネットワーク環境をご確認ください。
本検証環境では、Eclipse の Marketplace へのアクセスがブロックされていました。
② 以下の URL を指定し、EGit をインストール
https://archive.eclipse.org/egit/updates-6.5
EGit の最新バージョン http://download.eclipse.org/egit/updates のインストール中にエラーが発生しました。
これは、RDi の最新バージョン ≠ Eclipse の最新バージョン、つまり RDi の最新バージョンが必ずしも Eclipse の最新バージョンをベースにしていないためです。
IBM i プロジェクトの作成
① 「ファイル」 > 「新規」 > 「IBM i プロジェクト」を選択
もしくは、「新規） > 「プロジェクト） ⇒ 「IBM i） > 「ローカル） > 「IBM i プロジェクトを選択します。
② 任意のプロジェクト名を指定し、「次へ」を選択
③ 任意の環境に接続し、「終了」を選択
接続先の5250環境
④ i プロジェクトのパースペクティブより、作成されたプロジェクトを右クリック > 「リモートオブジェクトのインポート」を選択
⑤ インポートしたいソース・ファイルを選択し、インポート
以降の説明では、GIT_TEST ライブラリ内の QRPGLESRC を対象とします。
ソース・ファイルのインポート完了後
ローカルリポジトリの作成
Git パースペクティブを開き、「Create a new local Git repository」からローカルリポジトリを作成
i プロジェクトのロケーションを「Repository directory」に指定する。
完了後
実際に RDi で編集したソースを Git でバージョン管理してみる
i プロジェクトでインポートしている GIT_TEST ライブラリ > QRPGLESRC > MYTEST を対象に編集・管理を行います。
RDi
SEU
初回コミット
① 「Git Staging」タブに移動し、「Unstaged Changes」にあるファイルを「Staged Changes」へ移動させる
ドラッグ＆ドロップで操作できます。
② 「Commit Message」にコメントを入力し、「Commit」 を選択
Commit 完了後
ファイルの修正
① ファイルに修正を加える
今回はDSPLYの出力内容を変数に変更します。
i プロジェクトでの編集の都合上、テキスト化されたソース・ファイルを修正しています。
テキスト化の際にシフト文字が削除されているため、2バイト文字の扱いには注意が必要です。
② 修正はあくまでローカルの i プロジェクト上で行うため、変更を反映させるにはプッシュ操作が必要
「リモート・アクション」 > 「コンパイル(RPGLE)」 等 でコンパイルするか、「リモートアクション」 > 「変更のプッシュ」 で反映される。
・プッシュ前
・プッシュ後
修正したファイルをコミット
修正したファイルは、初回コミットと同様の手順で再度コミットします。
2回目のコミット完了後
まとめ
本活動では、IBM i 上で Git を導入し、ソースコード管理の方法について検討しました。
その結果、ネイティブ環境でも RDi 環境でも Git 自体は利用可能であるものの、オープンソース開発のような運用フローをそのまま適用することは難しいことが分かりました。
主な課題
- ソース・ファイルを直接 Git で管理できず、IFS やローカル環境への展開が必要になり、二重管理が発生する
- IBM i のシフト文字（半角/全角制御）を意識したソース作成が必要
活用の可能性
正式な運用フローには組み込みにくい制約はあるものの、個人作業の履歴管理や差分確認等、部分的な活用では十分に有用であることが確認できました。
参考文献
- 特集 5250 環境で Git を利用する、Git 再入門 ｜ Part1 RPG Ⅲ ソースはバージョン管理をしなくてもいいのだろうか
- 特集 5250 環境で Git を利用する、Git 再入門 ｜ Part2 5250 環境（SEU）で Git を活用する
- 特集 5250 環境で Git を利用する、Git 再入門 ｜ Part3 連携方法 ── 準備編
- 特集 5250 環境で Git を利用する、Git 再入門 ｜ Part4 連携方法 ── 基本編
- 特集 5250 環境で Git を利用する、Git 再入門 ｜ Part5 連携方法 ── 応用編
- サル先生のGit入門 ～バージョン管理を使いこなそう～
- オープン系開発者が IBM i の環境構築から始めてみた ①
- IBM iのコード変更管理 ～オープンソースのGitを利用して、ソースコードや変更履歴情報を共有
- egit with RDi 9.8 | IBM i Global
著作権
当記事の著作権はIBMに帰属します。
詳細はこちらを参照ください。