IBM iのビルド管理
Part 3ではGitを中心としたIBM iでのコード管理の手法を紹介した。IBM iでDevOpsを進めるうえで重要な取り組みであるが、これはあくまで入り口にすぎない。
Part１でも述べたように、DevOpsとは開発と運用の垣根をなくして連携させることで、ITシステムが今まで以上にビジネスへの貢献を高めることに狙いがある。それには開発から運用までのプロセスを整理し、自動化を推進することが求められている。
そこでPart 4では開発・運用の連携に着目し、ビルド管理に関するIBM iでの現状やその取り組み方法について解説する。ここではツールとしてJenkinsを取り上げ、具体的な利用例を挙げつつ、IBM iでのDevOpsの取り組みを紹介しよう。
IBM iのビルド管理
ビルドは一般的にはアプリケーション単位で実施され、各種テストの基本指標になると考えられている。そのためビルドの日付・時間などは重要な管理指標とされ、プロジェクトや企業システム内でトラッキングされている。
一方、IBM iではビルド管理をあまり重視してこなかった。その理由の1つに、IBM i のOSが備える機能の充実ぶりが挙げられる。たとえばOSがもつデフォルトの機能だけを利用して、ビルドされたプログラムオブジェクトから作成者、作成時間、作成システム、ソース情報、アクセス記録を、ソースコードからは編集行単位のアクセス時間を、ファイルオブジェクトからは作成時間、アクセス記録、ファイル構造情報、件数など、さまざまな情報を収集できる。
しかもそれらの情報は、CLコマンドから簡単にアクセス可能だ。ビルドも、CLベースのコンパイルコマンドを組み合わせることで容易に実行できる。繰り返す場合も、CLプログラム化することで容易に定型化できる。
また、スケジュール機能やメッセージ監視といったトリガー関連の処理もOSに組み込まれ、CLプログラムコマンドで連携できるので、わざわざそのためのツールを準備することに意識が向かなかったのも事実である。
さらにOSの監査機能やオブジェクト情報が充実しているため、あとから、いかようにも、情報を追跡できるといった安心感がある。それらが、IBM iのビルド管理に対する関心が低い理由であると考えられる。
しかしIBM iだけでなく他システムとの連携を踏まえ、システム全体のビルド管理を考慮すべき状況では、IBM i独自の機能に依存したビルド管理ではなく、オープンソースをベースとした標準的なビルド管理手法を取り入れることが今後必要となる。
そこで以下に、継続的インテグレーション（Continuous Integration：CI）ツールとしてビルド、デプロイ、テスト管理などで利用されているJenkinsを取り上げ、DevOpsにおけるこのツールの価値とIBM iでの活用方法を解説する。
Jenkinsは、Javaで作成されたオープンソースのツールである。公式サイト（https://jenkins.io/）にアクセスして、執事のアイコンを目にした人も多いだろう。Jenkinsの自動化機能はイベント（バージョン管理システムにおけるコミット、時刻に基づくスケジューリング、他のビルドの完了など）をトリガーに、さまざまな方法で起動できる。
こうした機能はプラグインで自由に拡張可能で、実に多種多様なプラグインが提供されている。ユーザーはそのなかから自社に必要なプラグインを選択し、組み合わせて利用する。公式サイトのダウンロードリストを見ると、Linuxの各種ディストリビューション、Mac OS、Windows、docker、さらにAzureなど多彩なインストールパッケージが準備されている。
残念ながらIBM i用のインストールパッケージはないが、幸いなことに、「Generic Java Package（war）」が提供されているので、JVMが稼働するマシンであれば、導入を試せる。今回はこのGeneric Java Packageを利用して、IBM iのJ9 JVM配下でJenkinsを導入してみた。
Jenkinsの導入と起動
Jenkinsの導入と起動は非常に簡単で、前述したJenkinsのサイトからGeneric Java Packageをダウンロードすればよい。ダウンロードされるファイルは、jenkins.warの1つだけである。これをIBM iのIFS上に配置し、シェルコマンドラインでjava -jar jenkins.war と入力する。あとは自動的に起動し、ユーザーのHOMEディレクトリ配下に.jenkinsディレクトリが作成され、そこにプログラムや環境データを展開し、起動する。
起動後に、http://localhost:8080にアクセスする。初回のアクセスではunlock処理の画面が表示されるが、指示に従って操作すれば、Jenkinsの管理画面へアクセス可能となる。起動状態を5250画面で確認してみると、図表1のようになる。
［図表1］ 5250画面で確認するJenkinsの起動状態
［図表2］ Jenkinsのノード管理
ブラウザでアクセスし、Jenkins管理内のノード管理を見ると、図表2の表示を確認できる。アーキテクチャ欄にはOS/400 （ppc）が表示されており、IBM i上でJenkinsが起動しているのがわかる。
ビルド定義
次に、ビルド定義を作成する。画面左側の新規ジョブの作成を選択する。ビルド定義の名前を入力し、ジョブのスタイルに「フリースタイル・プロジェクトのビルド」を選択し、OKをクリックする（図表3）。
［図表3］ Jenkinsでのビルド定義
ビルド内のビルド手順の追加ボタンをクリックして、シェルの実行を選択すると、シェルスクリプトの実行入力欄が表示されるので、図表4のようにスクリプトを入力する。
Applyボタンをクリックして定義を保管すると、ビルド実行定義が完成する。以下に、このビルド定義の内容を簡単に解説しよう。
①ビルド対象のソースファイルを出力するディレクトリを削除し、クリーンアップする。
②IBM i上のGitリポジトリーからソースファイルを
対象ディレクトリにクローンして、ソースを書き出す。
③シェルコマンドsystemにより、前行で出力されたIFS上のソースコードを用いてCRTBNDRPGを実行し、プログラムオブジェクトを作成する。
全体の流れは、図表5のようになる。
ダッシュボードの画面は、図表6のように表示されるので、ビルドを実行すると、上記のスクリプトが実行される。Jenkinsのビルド履歴を見ると、ビルドの実行履歴を確認できる（図表7）。
［図表］6 Jenkinsでのビルド実行履歴
［図表］7 Jenkinsのビルド履歴
以上、簡単ではあるが、IBM i上でJenkinsを起動し、ILE RPGのコンパイルをGitリポジトリーからのソース連携で実行できることが確認できた。当然ではあるが、これはGeneric Java Packageを利用した導入なので、IBM iの動作保証サポートが得られるわけではない点に注意してほしい。オープンソースをベースとしたツールなので、ユーザー側のリスク管理を前提にした利用が基本である。
Jenkins検証結果からの考察
次に、今回の検証で気づいた点を列挙してみよう。
ビルドのログの文字化け
ビルドログが文字化けして表示される。具体的にはコンパイルリストの中身であるが、CCSID5035のジョブログをCCSID1208のログファイルに書き込んでいることが原因と考えられる。Javaで作成されたJenkinsではコード変換が必要だが、その部分の考慮が抜けているようだ。
今回は、IBM iをマスターノードとして設定し、直接シェルコマンドを実行した。JenkinsではSlaveノードを通して、SSH経由でシェルコマンドを実行するノード構成も可能である。その形式であれば、SSH経由でコマンドを投入するのと変わらないので、SSHサーバー側でログのコードが変換されるのではないかと推測しているが、今回は時間の関係でテストまでには至っていない。
シェルコマンドsystemでの制約
systemコマンドでは、単一のコマンドを毎回異なるジョブとして投入する。そのため、ライブラリーリストの変更などは投入できるが、後続のsystemコマンドとは連携できない。そうした場合はCLプログラムを作成し、それをsystemコマンドで投入するなどの検討が必要であろう。
DDS関連のファイルは
直接コンパイル不可
OrionでDDSの構文ハイライト機能が追加されているが、Orionで開発したソースはIFS上のストリームファイルとして作成される。単純なソース編集や、Gitを使ったバージョン管理ではとくに問題にはならない。
しかしコンパイルとなると、IFS上のストリームファイルをソースとして指定できないので、CPYFRMIMPFコマンドなどでソースファイルにコピーする必要がある。
なおCLに関しては、2018年4月に発表されたTechnology Refresh 4から、SRCSTMFパラメータが追加され、IFS上のソースを直接コンパイルできるように拡張されている（https://ibm.co/2ASz
4he）。
＊
ここまで、IBM iでJenkinsを利用したビルド管理について解説した。実際には個々の環境に応じたトリガーなどを取り決め、スクリプトやスクリプトから呼び出すCLプログラムの作成が必要になる。
トリガーなどはJenkinsのプラグインなどを活用し、Gitなどのソフトウェア構成管理ツールとの連携を密にできる。ビルド自体の細かい制御（たとえばライブラリーリスト、コンパイルパラメータ指定など）は、CLなどで作り込む必要があるだろう。段階を踏んで少しずつ、JenkinsなどのCIツールを中心としたビルド管理の仕組みを構築し、IBM iでのDevOpsの範囲を広げていくことが重要である。
本特集を通じて、IBM iはGitなどの普及に着目し、ソースファイルのIFS配置など、オープンソースをベースとしたDevOpsへの親和性を高めていることが理解できただろう。IBM iでも現時点で十分にDevOpsアプローチが実現できる。ぜひこの機会に、IBM iのDevOpsに挑戦してほしい。
著者｜箕手 幸広 氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
アセット企画
コンサルティングITスペシャリスト
［i Magazine 2018 Autumn（2018年8月）掲載］
◎お知らせ
本特集の監修と執筆を務められた箕手幸広氏は9月にお亡くなりになりました。
謹んでご冥福をお祈りいたします。
････････
特集｜IBM iのDevOpsアプローチ ◎目次
IBM iの基幹システム開発にも、これからはDevOpsアプローチが求められる
････････
････････
オープンソースのGitを利用して、ソースコードや変更履歴情報を共有する
････････
IBM iでJenkinsを使う、オープンソースベースの標準的なビルド管理を実現
［i Magazine 2018 Autumn（2018年8月）掲載］
