Gitをモダナイゼーション戦略の一部にする
IBM i のモダナイゼーション戦略の最重要部分は、おそらく、アプリケーションを開発および保守するのに使用しているツールをモダナイズすることであるはずです。アプリケーション開発の世界の大半が、バージョン管理でのGitの使用を軸にしたツールへと移行しつつあります。IBM i 開発者が同じようにできない理由はありません。IBMは、新たなMerlin製品でこうした戦略を強固に後押ししており、変更管理ベンダーの多くは、Gitとの機能統合を図っています。
バージョン管理にGitを採用することにより、社内で他のプラットフォームでの開発向けに使用されているのと同じツールでIBM i アプリケーションを管理できるようになります。何百万もの開発者がGitを使用しているのは、Gitが、ソース コードに対する変更を追跡するための、群を抜いて強力なツールであるからです。オンラインで使用するアプリケーションの多くは、Gitで管理されています（Linuxオペレーティング システムの開発など）。Gitは、学校で学生がコンピューター サイエンス プログラムで学ぶ主要ツールであることから、Gitを使用することで、新たな開発者をリクルートしやすくなります。また、GitHub、BitBucket、GitlabなどのようなグラフィカルなシステムでGitを使用することによって、ソースに対する変更の履歴を簡単に確認できます。
変更履歴の表示は、Gitで行うことができることのほんの一例に過ぎません。また、Gitでは、プロジェクトごとに開発を分類するのが簡単なため、様々なプロジェクトに関連のある変更を、テストを行っていつ本番に移動するか簡単に選ぶことができます。Gitの強力なマージ機能により、複数の開発者が、お互いの変更を上書きしてしまうのを心配することなく、同じソースで作業することができます。準備が整ったら、Gitは、開発者が行った変更内容を自動的にマージします（数多くの異なる組織の開発者によって同時に作業が行われているオープンソース プロジェクトをGitが管理できるのは、こうした機能によるものです）。また、Gitでは、必要に応じて、アプリケーションの以前のバージョンへ簡単にロール バックすることができます。さらに、Gitはバージョン間で変更されたコードのみを保管しているため、ソース メンバー全体をアーカイブに保管するシステムに比べて、Gitのリポジトリは非常に小規模なままになります。
しかし、GitベースのDevOpsシステムは、IBM i で使用されてきた従来型の変更管理ツールとは、機能する仕組みが異なります。そのため、Gitを導入するには、IBM i 開発者は、変更管理プロセスについての従来の認識を改めることが必要になります。
初めに: Gitとは
Gitは、ソース コードのバージョン管理システムです。Gitは、コードに対する変更を追跡し、リリース パッケージで複数バージョンのソース コードをデリバリーするための極めて強力な機能を提供します。IBM i の変更管理ツールとは異なり、Gitは、コードのコンパイルや作成されたオブジェクトの管理は行いません。ソース コード管理のみです。ビルド（作成、コンパイル）機能を自動化するために他のツールと統合することはできますが、Gitはそれらの機能を提供しません。
Gitにあまり馴染みのない人は、GitHub、GitLab、およびBitBucketのようなホスティング サイトと、実際のGitツールとの違いに混乱することがよくあります。オンライン サイトは、Gitを基礎となるバージョン管理ツールとして使用しており、Gitリポジトリを格納するためのオンライン上の場所を提供します。オンライン サイトでは、Gitおよび追加機能の有用性を高める強力な機能を利用できるため、Gitはさらに導入および使用しやすくなります。オンライン リポジトリやその他のグラフィカルなツールがないGitはコマンド駆動型のシステムです。オンライン ツールを使用することで、使いやすいグラフィカルなユーザー インターフェースを通じて、Gitの豊富な機能を活用できます。
Gitのアーキテクチャー
コミットベースのシステム: Gitでは、変更はコミットによって追跡されます。開発者は、コードに変更を加えたら、それらの変更をステージすることができます（Git Addを使用）。開発者は、変更のコンパイルおよびテストの準備ができたと思った時点で、または、すぐに戻ることができるチェックポイントを作成したいと思った時点で、それらの変更を「コミット」します。これにより、そのコミットとの関連で何が変更されたのかを誰でも簡単に確認することができます。開発者が同時に複数のタスクで作業している場合には、個々のコミットに、変更されたソースのうちのどれを含めたいか選ぶことができます。ステージしたすべての変更をコミットする必要はありません。たとえば、タスク1で行なった変更のみをコミットして、タスク2で行なった変更はコミットしないようにすることもできます。1つのライブラリーで行なわれた異なるプロジェクトのコードに対する変更を分類することは、標準のIBM i ツールの使用では難しい場合があります。しかし、Gitでは簡単です。
ブランチング: Gitの最も強力な機能の1つは、リポジトリのブランチングのサポートです。ブランチングは、開発者が、別々のプロジェクトまたはバグ フィックスで、それぞれ別個に作業することを可能にします。ブランチは、後で自分の判断でマージすることができます。たとえば、開発者がフィーチャー1とフィーチャー2で同時に作業しているとします。フィーチャー2がフィーチャー1より速く進行している場合に、他のプロジェクトからの変更を含めることなく、テストして本番へ移行することができます。変更は、後でGitの強力なマージ機能を使用して、マージすることができます。
分散型リポジトリ: Gitは、分散型リポジトリ システムです。通常、開発者は、それぞれ独自のソース リポジトリのコピーで作業を行います。つまり、開発者は、変更を行うための隔離された「サンドボックス」で作業することになります。何を行っても、他の開発者のリポジトリに影響は及びません。開発者は、それぞれ隔離された環境で、変更を行い、アプリケーションをビルドし、変更をテストすることができます。
変更は、変更されたコードを1つのリポジトリから別のリポジトリへ「プッシュ」（git push）または「プル」（git pull）することによって、リポジトリ間で共有されます。
変更のプッシュおよびプル: Gitユーザーは、それぞれ独自のリポジトリのコピーを持っているため、1つのリポジトリから別のリポジトリへ変更を移動させる手段が必要となります。たとえば、2人の開発者が同じタスクで作業していて、それぞれが別個にそれぞれの変更作業を行った後に、それらの変更を共有することになったとします。これを行う方法の1つに、一方の開発者のリポジトリからもう一方の開発者のリポジトリへ、直接、変更をプルするという方法があります。
ただし、この手法は、最新のバージョンに関しては、時間の経過によって混乱の原因となることがあります。そのため、Gitでのリポジトリの作成は非常に簡単であることから、より良い手法として、作業しているタスク用の共有リポジトリを作成して、開発者が変更を共有タスク リポジトリにプッシュするという方法があります。
もちろん、そのような同じコード ベースでの同時開発では、1つの変更セットが別の変更セットを上書きしてしまう問題が生じることがあります。しかし、Gitではそうした問題は防止されます。コードにまだ含まれていない変更があるリポジトリに変更を「プッシュ」しようとすると、Gitはそのプッシュを行うのを阻止します。まずは、共有リポジトリから自分のリポジトリへそのコードを「プル」する必要があります。それを行うと、Gitは、そのコードを、開発環境にある変更されたコードのバージョンと自動的にマージしようとします。同じ場所で変更が行われていない限り、Gitは自動的にマージを実行します。ただし、両開発者が行った変更に同じコード行に対する変更がある場合は、Gitはコードにマーキングすることによって、競合を解決する機会を提供します。
Gitでは、ユーザーは、これらのプッシュおよびプル操作に関連して、自動化プロセスを設定することができます。たとえば、変更はタスク ブランチからQAブランチへのみ移動でき、本番に移動する前にQAブランチを通る必要があると決められている場合に、承認リストを設定して、変更がレビューされ、テストされてからでなければ、その先へ移動できないようにすることができます。コード スキャンや自動化されたテストのようなプロセスをプル プロセスに追加することもできます。
Gitユーザーの日常的な作業
ここまで、すべて聞き慣れないことばかりだったとしても、心配ご無用です。それは、従来IBM i で行われてきた開発の手法とはまったく 異なる ものだからです。Gitを使い始めてみれば、操作手順はすぐに習慣として身に付いてきます。そうなれば、所属されている組織にとってのメリットは、著しいものになる可能性があります。
一般に、日常的な作業として、以下を行うことになるでしょう。
- 作業するタスクを選ぶ
- どれでも使用したいと思うツール（PDM、RDi、VS Codeなど）を使用して、コードの変更作業を行う
- Git Addを使用してGitリポジトリに変更を追加する
- 追加の変更を行なう場合は、手順2と手順3を繰り返す
- 準備ができたら、Git Commitを使用してローカル リポジトリに変更をコミットする
- 準備ができたら、Git Pushを使用して共有リポジトリに変更をプッシュする
IBM i ツールを使用して、ライブラリー、ソース ファイル、およびソース メンバーと、Gitディレクトリーとの同期を処理することによって、これらの手順をさらに簡略化することができます。その場合は、通常の方法で変更を行って、それらの変更をGitディレクトリー構造に同期させる処理をそのツールに任せるだけです。
Gitのメリット
Gitへ移行した場合に得られる大きなメリットには、以下のものがあります。
- すべてのコードを1つのリポジトリで管理: Gitでは、Java、PHP、JavaScript、Python、.Net、およびその他のオープンソース コードを管理している同じリポジトリで、すべてのIBM i ネイティブ ソースを管理することができます。
- 自動オフサイト バックアップ: ホスティングGit環境（GitHub、BitBucket、GitLabなど）を使用している場合、すべてのコードおよびすべての変更履歴に対するセキュアなクラウド ホスティング バックアップを自動的に取ってもらうことができます。
- 監査の簡略化: 監査担当者は、1つの場所で、すべての環境にわたってコードに対して行われているすべての変更を確認することができます。それぞれの変更を誰が行ったか、どのような理由で変更を行ったか、誰が変更を承認したか、いつ変更が行われたかを確認することができます。適切な承認者が変更を承認したこと、自動スキャンが実行されたことを確認することができます。
- 開発者の生産性向上: Gitは並行開発を効率的に管理できるため、途中で変更が消失することのないようにしつつ、プロジェクトが同時に前進することを可能にします。
- 人材確保を促進: Gitは、世界でも群を抜いて最も人気の高いソース コード管理ツールです。それほど人気が高いということは、Gitを使える開発者は簡単に見つけることができることを意味します。Gitは、オンライン コースであれ、コーディングの短期集中トレーニングであれ、大学のコンピューター サイエンス カリキュラムであれ、最も多くのコンピューター サイエンス コースで使用されているツールです。
- 開発ツールとの統合性の高さ: Gitは非常に人気が高いため、開発に関連のあるほとんどすべてのソフトウェア ソリューションはGitに接続することができます。Visual Studio CodeやEclipseのようなIDEは、追加設定なしでGitと統合されており、Jira、Smartsheets、ServiceNow、およびSalesforceのような問題追跡ツールはGitと機能統合することができます。コード スキャナーおよびテスト ツールは、Gitとの統合性を備えています。Gitを使用することで、包括的なDevOpsツール チェーンを簡単に構築できるようになります。
私が所属するEradani社では、開発者は10年以上にわたってIBM i コードでGitを使用してきました。彼らはGitが大お気に入りであり、Gitの話が大好きです。IBM i コードでのGitの使用法についてさらに詳しくお知りになりたい方は、ぜひともご連絡いただければと存じます。 www.eradani.com を参照していただくか、または info@eradani.comまで、メールにてお問合せください。
