はじめに
ここではz/OSのリソースをGitで管理するパターンをいくつかとりあげてみます。
関連記事
z/OSにおけるGitの活用(1) - 概要
z/OSにおけるGitの活用(2) - Rocket Git構成
z/OSにおけるGitの活用(3) - Git活用例
Git活用例
活用例1: z/OS(USS)上でGit Clientを直接使用するケース
Use Case: UT環境での個別修正のビルド
z/OS上のリソースをz/OS上のGitクライアントを使って、外部にあるGitServer上で管理するというシナリオです。
管理対象のリソースとしては、コード開発のフェーズであればソース・コードやビルド(コンパイル/リンク)に必要なJCL/スクリプト群、ビルド結果であるJOBLOGなどが該当すると思います。開発以外にも、フェーズによってテスト環境を整備するためのJCLや運用管理に関するスクリプトなど、他の環境や他のユーザーのために共有して管理すると便利なものもあると思います。結局はどう使うかという話なので使いどころは色々あると思います。
上の図の例は、バグ修正のようなCOBOLのソースコードを個別に修正する、というイメージです。
操作の流れとしては以下のようになります。
- Gitで管理されているソースをローカル・リポジトリ(USS上)に持ってきます(clone)。各リソースはUSS上のファイルとして管理されます。
- COBOLのソースはMVSデータセット上にないと都合が悪いのでUSS上からMVSデータセット上にコピーします。必要に応じてコピー先のMVSデータセットのアロケーションなども行います。
- 編集/ビルド/単体テスト...などのプロセスを回します。
- 改修が終わったら更新されたソースをUSS上にコピーします。また、必要に応じてエビデンスとして改修後のJOBLOGなどもUSS上にコピーします。
- ローカル・リポジトリ(USS上)の更新されたファイルをGitサーバに反映します(push)
このように、USSを介してGitのサーバーとのデータのやり取りを行うことになります。このUSS⇔MVS間のやり取りについてはなるべくスクリプト化しておいてスムーズに行えるようにしておくと便利です。
USSの標準機能(シェル・コマンド)でUSS-MVS間でのファイルのコピーやJCLのサブミットなどを行うことができます。ただデフォルトで提供されている機能だけだと限定的なので、ツールなどを使うことでUSS⇔MVS間のやりとりを効率よく行うことができます。
例えば、以下のような拡張ツールを使用することでUSSからMVSの操作がやりやすくなります。
自作ツール:
REXXでMVS上の操作を行うインターフェースが提供されているので、USS上でREXXスクリプトとシェル・スクリプトで以下のようなユーティリティーを作成しています。
Lightweight Command Utility on z/OS USS
ZOAU:
ZOAU(IBM Z Open Automation Utility)という無償で使えるユーティリティーがあります。これはUSS上でMVS操作のためのシェル・コマンドやPython APIを提供しています。
DBB:
DBB(Dependency Based Build)という有償製品があります。こちらはアプリケーションのビルド支援機能を提供するツールという位置づけですが、USSからMVS操作を行うためのGroovy/Java用のAPIが提供されています。
この辺りについては以下の記事もご参照ください。
参考: z/OS技術者が学ぶべきオープンな技術～USSの活用～ - USSとMVSの関係
具体的なデモシナリオ:
以下に具体的なデモシナリオを公開しています。
ISEConf2023_MySample01
Use Case: テスト環境の整備
単純に、ユーザー作成やらデータセット作成など、汎用的に使用できそうなJCLやスクリプトをGit上に管理しておけば、複数の環境に横展開する場合や、他のメンバーに共有する場合にスムーズに管理/連携が行えると思います。
テスト環境だと複数の管理者がいろんな作業を行っていて、一時的な変更作業や緊急での追加コンポーネントの導入など実施することがあるかもしれません。そのような作業ログをGit上にアップする運用ルールにしておけば、作業ログや履歴などがGit上で共有できることになります。
個人的には仕事上ある製品の新バージョンのテストなどをすることもあるのですが、製品のインストールやセットアップ作業をする際は、JCLは大抵USS上で作成してSubmitし結果のJOBLOGもUSSファイルとして取得するようにしています。その際は、上でも挙げた以下のユーティリティーを利用しています。
Lightweight Command Utility on z/OS USS
セットアップに使用したJCLや結果のJOBLOGはUSS上にあるのでGitでそれをRemoteRepositoryにPushしてあげれば、簡単に共有/作業ログの管理ができるということになります。
このように、単純なJCL/JOBLOG共有目的であってもGitが使えるとなかなか重宝します。
簡易的な利用方法
z/OSは開発環境といえどもセキュアなネットワーク上に配置されていることも多く、外部との接続が制限されているケースもあります。前の記事ではProxy経由での構成についても記載しましたが、技術的には可能でもセキュリティー・ポリシー的には許可されない、ということもあるかもしれません。
Gitは分散型のソースコード管理という点が売りなので、Remote Repository - Local Repositoryを連携して使用するというのが基本的な使い方ではありますが、Git Serverを使わない形式、つまり、手っ取り早くLocal Repositoryのみ(Rockert Git on z/OSのみ)で利用する、ということも可能です。
イメージとしては以下のようになります。
この場合、Remote Repositoryで他のユーザーとの共有はしない想定なので、あくまで各個人の開発者/管理者が独自にバージョン管理を行う、という用途でしか使えないということになりますが、ブランチを作って別バージョンを色々試してみたり、変更を元に戻してみたり、というのを個別にローカル・リポジトリの環境だけでGitの仕組みを使って実施することも可能です。これはこれで有用ですし、Gitの使い方に慣れておくという意味でも有効なので、スモール・スタートの一つの形態としてあり得ると思います。
活用例2: PCをGit Clientとして間接的に使用するケース
Use Case: UT環境での個別修正のビルド
開発者のPCのGit Client機能を使って一旦PC上にLocal Repositoryをクローンし、PC上で編集作業を行うという方法も考えられます。
COBOL, PL/I, JCLなどの編集作業はPC上のエディターでもある程度できますが、実際にJCLを実行してみる、ソースをコンパイルしてみる、COBOLの単体テストをしてみる、といったことをしたい場合はPC上だけでは実施できないので、z/OS上に持って行って実行するということを行う必要があります。この部分は活用例1でも示したように、USSを介してMVS上の操作を行う、というようなことを行うことになります。
アプリケーション開発における個別のソース修正時のビルド(ユーザー・ビルドなどと呼ばれます)については、VS CodeのExtension、IDzから、DBBを使用した連携の仕組みが提供されており、その仕組みを利用することもできます。
具体的には、zAppBuildというDBBを利用した汎用的なビルド用フレームワークが提供されており、それを使用すると、VS CodeやIDzからビルド用のメニューを選択することで、USSへのファイル転送、必要に応じてMVSデータセットの作成、USSファイルからMVSデータセットへの転送、ビルド(コンパイル・リンク)実行、といった一連の処理を行わせることができます。結果のJOBLOGがPC上にダウンロードされるところまでやってくれるので、あとはPC上のIDEのGit Clientプラグインの機能を使ってソース管理を行えばよいということになります。
この辺りの詳細なイメージについては以下の記事もご参照ください。
VSCodeを使用したメインフレーム・アプリケーション開発 - (4)ソース管理ツール/ビルドツール連携
Eclipseを使用したメインフレーム・アプリケーション開発 - (4)ソース管理ツール/ビルドツール連携
このような構成パターンを使用する場合、DBBやzAppBuildを使用することになりますので、それを前提としてz/OS側の設定や、リポジトリー上の構成ファイルの配置などを考慮する必要があります。
zAppBuildも汎用的なフレームワークを提供してくれてはいますが、アプリケーションの作りによってはカスタマイズが必要になると思われますので、Groovy、DBBのスキルが必要になってきます。
具体的なデモシナリオ:
以下に具体的なデモシナリオを公開しています。
ISEConf2023_MySampleDBB01
活用例3: Jenkins連携
Use Case: IT環境での一括でのビルド
活用例2は、開発者がバグ修正のような一部のソースを個別に修正して単体テストを回す、といったフェーズのイメージでした。
ここでは、そのような修正が集積され、一旦それらをまとめてリリースするために次のフェーズとしてIT環境に最新のソースを持っていってまとめてビルドする、というようなフェーズでの利用を想定しています。
JenkinsのSSH経由で実行されるエージェントをz/OSのUSS上で稼働させることができます。従って、ソース類と一緒にそれらをまとめてコンパイル/リンクするためのスクリプトをJenkinsのパイプラインに仕込んでおくことで、一括のビルド処理を自動化することができます。
この一括でのビルドの処理についても、DBB + zAppBuildを利用することができます。活用例2と同様、DBB, zAppBuildの設定、カスタマイズは必要になってきますのでGroovy, DBBのスキルは同様に必要になってきます。
Jenkinsを使えばパイプラインに指定した処理の自動化が行えることになりますが、これは「Git上に管理されたパイプラインで指定した処理をUSS上で実行できる」ということでしかありません。どのようなスクリプトを使って何をどうパイプラインとして実行するか、というのは作り次第です。アプリケーションの作りや運用フローによって何が自動化(スクリプト化)できて、どういうパイプラインを作成すればよいかは環境によって異なりますので、そこはお客様環境ごとにそれぞれ設計、実装を検討していく必要があります。
Jenkinsの利用については以下の記事もご参照ください。
Jenkins - z/OS連携
具体的なデモシナリオ:
以下に具体的なデモシナリオを公開しています。(活用例3と同じリポジトリ)
ISEConf2023_MySampleDBB01
活用例4: Ansible連携
Use Case: テスト環境の整備 (Infrastructure as Code)
インフラの構成をコードとして管理する、いわゆるIaC(Infrastructure as Code)という考え方があり、その代表的なツールとしてAnsibleがあります。最近はz/OSのインフラ操作をするためのAnsible用のモジュールも提供されるようになってきており、そのモジュールを利用することでz/OSをAnsibleの管理ノードとして扱うことができるようになっています。
例えば、z/OS Core Collectionで提供されるモジュールを使用することで、テンプレートとして用意したJCLのサブミットや、MVSコマンドの実行などをAnsible Playbookから容易に実行できるようになります。
z/OSのインフラ構成情報をAnsible Playbook(Yamlファイル)として定義できれば、複数の環境に対して同様のインフラ構成作業を効率よく自動化することができます。また、PlaybookやテンプレートとなるJCLなどはGit上で管理することができますし、AWX(Ansible Tower)ではGitと連携するための機能も提供されています。
z/OS Core Collectionを使用する場合、基本的にはUSS上のPython, ZOAUが内部的に使用され、それをSSH経由で呼び出すことになります。z/OS Core Collectionを使用する場合はz/OS側で、SSH、Python、ZOAUのセットアップが必要になります(いずれも無償利用可能)。
Ansible/AWXについても、Jenkinsと同様、ツールを入れれば何かが勝手に効率化/自動化される、という類のものではなく、インフラ構成をYAMLでコード化しやすくなりますよ、というだけなので、何をどうPlaybookとして作るかは要件に応じて設計、実装を検討していく必要があります。
具体的なデモシナリオ:
以下に具体的なデモシナリオを公開しています。
ISEConf2023_MySampleAnsible01
おわりに
上に挙げたGitを利用するシナリオは、いずれもオープン系でも使われている仕組みをz/OSにどのように取り入れられるか、という話です。つまり、旧来から実施しているフローをそのまま効率化するようなものではなく、プロセスや運用方法、使い方そのもの、あるいは考え方を変えていきましょうという話です。GitやJenkinsなどを導入すれば完了というわけではなく、新しい仕組みに合わせて運用や管理方法変えていく必要があります(どう変えていくかはアプリケーションや環境に応じてそれぞれ個別に検討する必要があります)。オープン系とメインフレームの差異に関するもの、特に拡張子の考え方や文字コード変換については新たに考慮しなければならない事項が出てきますのでご注意ください。
(文字コード変換については別の記事で検証していきたいと思います。)
参考: z/OS利用時の文字コード変換
また、Gitに限った話ではありませんが、全てのケースにおいてオープン系の技術を取り入れることが"正"である訳では無いと思います。現行のフローに慣れている現場の担当者にとっては、仕組みが変わること、新たな仕組みを構築しなければならないこと、新たなスキルが必要とされること、などは大きな負担になる場合もあるでしょう。"旧来から実施している開発/運用フロー"を変えたくない、あるいは変える必要が無い、というシステムなのであれば、無理にオープン系の技術を取り入れてやり方を変えても即時に大きなメリットは出にくいかもしれません。アプリケーションの特性や運用の要件によっては新しい仕組みだと不向きなケースもあるかもしれません。
ただ、一昔前にはオープン系アプリケーションのプロジェクトでもGitによる管理に移行する際には "従来のやり方を変える" ということに難色を示すケースもよくある話だったようですが、それが現在ではGitを使用することが当たり前になっている状況を見るに、1周,2周遅れで同じことがz/OSアプリケーション開発の現場で起きているようにも思えます。
現行のやり方を前提とした目の前の開発効率を重視するのか、若手技術者の確保、育成を見据えた長期的な目線での"Newオンプレミス"への変革を目指すのか、といった目的次第でこの辺りの技術適用の仕方は変わってくると思います。
オープンソースを活用するということは追加のソフトウェアのライセンス・コスト無しで利用できるものが多いです。まずは試しに使ってみて、使いながらよりよい活用の方法を探っていき、知見を積み重ねていく、ということが広まってこの領域全体が活性化していくことを期待したいところです。