MENU

RDiとGitの連携 ~ Gitの利用を開始するための準備作業| IBM iユーザーに捧げるGit入門 ❸

Gitの事前準備

RDi の開発でGitを使用する手順を解説していくが、まずは事前準備として以下を実施しておく。

今回はサンプルとして、IBM i 上で SEU/PDM を使用して開発している架空のシステム「slack 連携システム」をGit管理する手順を説明する。

ライブラリー:contoslack
ソースファイル:QCLLESRC、QCLSRC、QDDSSRC、QRPGSRC、QRPGLESRC
プッシュ先LIB:slackogawa(事前に作成しておく)

EGit のインストール

RDiでGitを操作するには、EGitプラグインを使用する。RDi導入時、もしくは導入後に IBM Installation Managerから「Eclipse Git Teamプロバイダー」をインストールしておこう。

RDi でGitパースペクティブが表示される場合は、 EGit はインストール済みである。

バージョン管理の前準備

RDiで開発する場合は、リモート・システム・エクスプローラー(以下、RSE)を使って IBM iに接続した状態で作業するケースが多いだろう。RSEはIBM iのソースファイル内のメンバーを直接操作する必要があるからだ。

しかしGitでバージョン管理するには、ソースコードをローカルのディスク内に置く必要がある(図表3)。

図表3 PC 側のフォルダ構成(c:¥contoslack)

① ソースコードをダウンロードする場所
② Git リポジトリ
③ ダウンロードしたコードをコミット

そのため、Gitでバージョン管理するのはRSE経由ではなく、以下のいずれかを選択して構成および作業する。

iプロジェクト

PC に配置したソースコードを管理し、事前に定義した接続設定を使用してIBM iのソースファイルのメンバーにコードをプッシュする。定位置形式のコード(RPG Ⅲ、ILE RPG)のバージョン管理を実施したい場合はこちらを選択する(以降は、iプロジェクトを例に解説する)。

IFSプロジェクト

PCに配置したソースコードを管理し、事前に定義した接続設定を使用してIBM iのルート・ファイル・システムにコードをプッシュする。RPG Ⅲ で開発しない場合は、こちらの選択も可能である。

それではiプロジェクトの使用を例に取って、以下に事前準備を解説していく。

iプロジェクトの事前準備

まずは、Gitでバージョン管理したいソースファイルをPC上にコピーする。ここでは、RDi でワークスペース(ワークスペース名は iMagazine)を起動し、IBM iへの接続も作成および接続済みであることを前提に進める(図表4)。

 

図表4 ワークスペースを起動

バージョン管理に不要な情報を除去 

IBM iソースファイルのレコードは、以下の3つのフィールドで構成される。

1. 順序番号(SRCSEQ)
2. 日付(SRCDAT)
3. ソースコード(SRCDTA)

1と2はSEU が使用する項目であり、Gitで管理する必要はないので、ダウンロード時に除去するように設定する(図表5)。

 

図表5 順序番号と日付を除去

ユーザー名とメールアドレスの登録

コミットするユーザーを特定するためのユーザー名とメールアドレスを登録する。ウィンドウ→設定で設定ウィンドウを開き、チーム→Git→構成と進む。エントリーの追加をクリックし、以下のキーと値を指定して登録する(図表6)。

ユーザー名:user.name
メールアドレス:user.email

 

図表6 ユーザー名とメールアドレスを登録

iプロジェクトの作成

iプロジェクトを作成し、事前に作成した接続を使用して、IBM i上でバージョン管理を開始したいソースファイルをPCにインポートする。プロジェクト名は、ソースライブラリー名と同じにしておくとわかりやすい。

ファイル→新規→その他と選択して、「ウィザードを選択」画面を表示する。ウィザード欄にIBMと入力して、その下でローカルの「IBM i プロジェクト」を選択し、「次へ」をクリックする(図表7)。

 

図表7 ウィザードを選択

 

プロジェクト名に「contoslack」、デフォルト・ロケーションの使用のチェックを外してロケーションを指定する。ロケーションは任意のディレクトリを指定可能だが、今回はわかりやすいようにC:¥contoslackと指定して、「次へ」をクリックする(図表8)。

 

図表8 プロジェクト名とロケーションを指定

 

iプロジェクト・プロパティーの接続は事前に構成した接続を選択し、関連ライブラリーはプッシュ先ライブラリーを指定して、「終了」をクリックする(図表9)。

 

図表9 iプロジェクト・プロパティ―を設定

 

iプロジェクト・パースペクティブを開くか聞いてくるので、「はい」をクリックする(図表10)。

 

図表10 iプロジェクト・プロパティ―を開く

ソースコードのインポート

作成したiプロジェクト(実態はc:¥contoslackディレクトリ)に、バージョン管理対象のソースコードをインポートする。ソースファイルはディレクトリとして、ソースコードはテキストファイルとして、それぞれインポートする。

iプロジェクト・パースペクティブの左上のiプロジェクト・ビュー内で右クリックし、リモート・ソースのインポートをクリックする(図表11)。

 

図表11 リモート・ソースのインポート

 

ライブラリーの処理にて取り込むソースファイルのライブラリーCONTOSLACKを指定する(図表12)。

図表12 ソースライブラリーを指定

 

表示されたCONTOSLACKを展開し、すべてのソースファイルを選択してOKをクリックすると、ソースコードがダウンロードされる(図表13)。

 

図表13 ソースコードをダウンロード

 

ソースコード内に連続したシフト文字がある場合は、その旨の通知が表示されるので、通常は「はい」(ブランクで置き換える)で進む(図表14図表15)。

 

図表14 ソースコード内に連続したシフト文字がある
図表15 連続したシフト文字

 

iプロジェクト・ビュー内のcontoslackを展開して、ソースコードがダウンロードされていることを確認する(図表16)。

 

図表16 ソースコードをダウンロード完了

 

Gitリポジトリの作成

次に、iプロジェクト内にバージョン管理で利用するGitのリポジトリを作成する。

iプロジェクト・ビュー内のcontoslackで右クリックし、チーム→プロジェクトの共有を選択し、リポジトリー・タイプでGitを選択して「次へ」をクリックする(図表17)。

 

図表17 プロジェクトの共有

 

すると、Gitのリポジトリをどこに作成するかの指定画面が表示される。今回は先に作成したiプロジェクトのロケーション内に作成するので、「プロジェクトの親フォルダのリポジトリーを使用するか作成します」のチェックボックスにチェックを入れる(図表18)。

 

図表18 リポジトリを作成①

 

表示されたプロジェクト(ロケーションがC:¥contoslackの行)をクリックして、左下のリポジトリの作成ボタンをクリックする(図表19)。

 

図表19 リポジトリを作成②

 

リポジトリが作成(:¥contoslackフォルダ内に.gitフォルダが作成)されたら、「終了」をクリックする(図表20図表21)。

 

図表20 リポジトリを作成③
図表21 リポジトリを作成④

ソースコードをGitリポジトリにコミット 

ここまでで、IBM i からローカルにソースコードをダウンロードし、バージョン管理するための Gitリポジトリを作成できた。しかし現在の状態は「HEADなし」、つまりワークツリーの内容のコードはバージョン管理されていない。そこで次に必要なのは、現在のコードをGitリポジトリにコミットすることである。

RDiでGit 関連の処理を行う場合は、Gitパースペクティブを使用する。まず、RDiの右上のパースペクティブを開くアイコンをクリックし、Gitを選択してOKをクリックし、Git パースペクティブを開く(図表22図表23)。

 

図表22 Gitパースペクティブを開く①
図表23 Gitパースペクティブを開く②

 

それから左側のGitリポジトリ・ビュー内のcontoslackを選択し、Git ステージング・ビュー内の未ステージの変更の全ファイルを選択し(どれか1つを選択してCtrl+A)、ステージ済みの変更欄にドラッグ&ドロップで移動する。

続いてコミット・メッセージに「最初のコミット」と入力して、右下のコミットボタンをクリックすると、選択したファイルがリポジトリにコミットされる(図表24)。

 

図表24 選択したファイルをリポジトリにコミット

 

Gitリポジトリ・ビューのリポジトリで右クリックし、表示→履歴とクリックすると、履歴ビューにコミット情報が表示される。IDには、コミットID(40桁)の先頭7文字が表示されている(ほとんどの場合、この7文字だけでコミットを一意に識別できる)(図表25)。

 

図表25 コミット情報を表示

 

リモート・リコンサイラーの設定

iプロジェクトで修正・保管したタイミングで、自動的にIBM iにプッシュするにはリモート・リコンサイラーを利用する。

プッシュする先のソースファイルを複数人で共有していると、プッシュ時に競合が発生する可能性があるので、できれば個人のライブラリーにプッシュするように設定しておきたい。

その際に重要なのは、ソースコードをSEUで修正しないこと。その場合も競合が発生する可能性が高く、またSEUでの修正は明示的にローカルにコピーしないとバージョン管理対象にならない。

まず、右上のiプロジェクト・アイコンをクリックして、iプロジェクト・パースペクティブを開く(図表26)。

 

図表26 コミット情報を表示

 

下に表示されているリモート・リコンサイラー・タブをクリックする。状況のローカル変更は、まだリモートにプッシュしていない修正があることを意味する(図表27)。

 

図表27 ローカル変更を表示

 

リソースcontoslackで右クリックし、プッシュ/プル設定→保存時にプッシュをクリックすると、iプロジェクト・プロパティーの関連ライブラリーに指定したライブラリーにソースが転送される(フォルダと同名のソースファイルがない場合は自動的に作成される)(図表28)。

 

図表28 指定ライブラリーにソースを転送

 

転送が完了すると、状況欄が空欄になる。

リモート・リコンサイラーを構成すると、IBM iに接続した状態での作業が基本となる。未接続のままでソースを更新した場合は、あとでまとめて送信する必要がある。

チームで連携して作業する場合

IBM iの基幹システムはチーム開発がほとんどであろう。その場合は、プロジェクト管理者とメンバーとで、Git の初期作業に違いがある。

まず、先ほどまでの作業(コードのダウンロード、リポジトリの作成、初期コミット)は管理者が実行する。管理者はその後、他のメンバーがアクセス可能なサーバーにリモート・リポジトリを作成し、ローカルのリポジトリの内容をプッシュする。

プロジェクトのメンバーは、サーバーにあるリポジトリをローカルにコピーする。この作業を「クローンする」という。

実際の手順は用意するサーバーの種類によって異なるので、ここでは割愛するが、これは IBM iに依存しない作業であり、インターネット上に多くの情報があるので積極的に活用してほしい。

先ほどのリポジトリをオンプレミスで構成したGitLabにプッシュした直後のイメージは、図表29のとおりである。

 

図表29 GitLabのイメージ

 

以下では、リモート・サーバーにオンプレミスのGitLabを使用し、プロジェクト・メンバーはリポジトリのクローンが完了しているところから説明を進める。


著者|
小川 誠氏

ティアンドトラスト株式会社
常務取締役

1989年、エス・イー・ラボ入社。その後、1993年にティアンドトラストに入社。システム/38 から IBM i まで、さまざまな開発プロジェクトに参加。またAS/400 、IBM i の機能拡張に伴い、他プラットフォームとの連携機能開発も手掛ける。IBM i 関連の多彩な教育コンテンツの作成や研修、セミナーなども担当。2021年6月から現職。

[i Magazine・IS magazine]

 


特集 IBM iユーザーに捧げるGit入門

❶ バージョン管理の重要性

ソースコードは常にリーダブルであるべき

❷ Gitの基礎知識

よく使用する用語の解説と基本機能

❸ RDiとGitの連携

Gitの利用を開始するための準備作業

❹ Gitの活用方法

日常の開発作業でGitを利用する

新着