目次


アジャイルな IBM i を実現する

Rational Team Concert と ARCAD Pack for Rational を使用して IBM i アプリケーションを管理する

Comments

はじめに

この記事では、ARCAD Pack for Rational が IBM Rational Team Concert と IBM Rational Developer for i の両方を拡張して、IBM i ベースのレガシー・アプリケーションを管理できるようにするとともに、アジャイル・ソフトウェア開発と DevOpes の原則を容易に導入できるようにする方法を説明します。これらのテクノロジーは、組織の敏捷性を高め、変化に迅速かつ効率的に対応できるようにします。

この記事で説明する内容は以下のとおりです。

  • 上述のツールによって開発とデプロイを容易にする方法
  • 開発ワークステーションから、変更のデプロイ先となる本番サーバーに至るまで、ビルドとデプロイのプロセスを完全に自動化する方法
  • 標準的なビルド・ストラテジーと、そのストラテジーに ARCAD が自動的に IBM i コンポーネントを組み込む仕み
  • 継続的インテグレーション・ストラテジーの一部として IBM i コンポーネントを組み込む方法

必要なツールと、これらのツールが連動する仕組み

どのジョブにも、それを行うための適切なツールがあります。IBM i による開発を DevOps ストラテジーに組み込むためには、ARCAD Pack for Rational、Rational Team Concert、Rational Developer for i が必要です。

ARCAD Pack for Rational

ARCAD Pack for Rational (APR) は、以下の製品を拡張します。

  • Rational Developer for i
  • Rational Team Concert

APR と Rational Developer for i

Rational Developer for i は、ネイティブ IBM i 言語での開発を強力にサポートする最新のツールセットです。SEU、SDA、RLU、PDM などのネイティブ・ツールは静的で進化も止まっていることから、ほとんどの組織では Rational Developer for i を導入しています。また、若手の開発者の大部分は Rational Developer for i のベースとなっている Eclipse 環境を使い慣れているため、RPG や COBOL などの言語でも快適かつ生産的に作業することができます。

ARCAD Pack for Rational は、IBM i の世界に対処できるように、Rational Developer for i を拡張します。具体的には、データベースのアップグレードや依存関係のチェックといった特定の IBM i 機能でビルド・プロセスを強化します。さらに、COBOL で作成されたレガシー・アプリケーションから Free Form ILE やオブジェクト指向のコードまで、あらゆる IBM i 言語をサポートします。

APR と IBM Rational Team Concert

Rational Team Concert は、開発チーム全体のコラボレーションとガバナンスを強化します。サーバー・セントリックな Rational Team Concert は、複数のオペレーティング・システム (Windows、Linux、IBM i、z/OS など) 上で稼働し、さまざまなクライアント (Eclipse、VisualStudio、または Web UI) で利用できることから、チームのサイロを取り払い、通常は互いに会話することも滅多にない開発者たちを 1 つにまとめることができます。さらに、継続的ビルドと構成可能なプロセスを、タスクの追跡、ソース管理、アジャイル計画に統合することで、コラボレーティブ・ライフサイクル管理のあらゆるメリットがもたらされるようにします。Rational Team Concert for Eclipse を使用する場合、Rational Developer for i をどの Eclipse プラットフォームにでもデプロイすることができます。

APR は Rational Developer for i と Rational Team Concert の両方を拡張し、すべての Rational テクノロジーを継承すると同時に、ARCAD IBM i テクノロジー (IBM i オブジェクト管理や、自動化されて最適化された、IBM i 上での分析―変更―ビルド―デプロイというサイクル) を CLM の世界にもたらします。Rational Team Concert、Rational Developer for i、ARCAD Pack for Rational の 3 つを組み合わせるとマルチプラットフォーム・ソリューションとなり、IBM i 開発者を含め、同じプロジェクトに取り組むすべての開発者たちが共同で作業できる共通の環境が生まれます。これは、既存の本番環境の監査から、本番サーバーへの変更の配信まで、すべてをカバーしたソリューションです。

継続的インテグレーションのための構成作業

IBM i のアーキテクチャーでは、1 つの変更をすると、他の数百もの要素にその影響が及ぶ可能性があります。すべての依存関係解析を手作業で行っている場合は、単純な変更でさえも時間がかかり、エラーの原因になりがちです。ILE と SQL を管理しているとしたら、変更作業は瞬く間にさらに複雑になります。ARCAD はシームレスに Rational Team Concert と Rational Developer for i に統合され、それによって Rational Team Concert 開発プロセスに IBM i コンポーネントが組み込まれるようにビルド・プロセスが拡張されます。

ビルド・エンジンとビルド定義

継続的インテグレーションの目標は、開発サイクルを自動化してスピードアップすることです。この目標を達成するには、ARCAD ビルド・エンジンを作成して Rational Team Concert にデプロイする必要があります。ビルド・エンジンを作成してデプロイするには、IBM からライセンス交付されたプログラムをリストアした後、環境に適切なパラメーターを設定してプログラムを起動します。必要な準備はそれだけです。この 2 つのステップが完了したら、作業を開始できます。ビルド・エンジンが用意された後は、APR から提供されている ARCAD-XXX ビルド・テンプレートを使用して新しいビルド定義を宣言し、作成して起動したビルド・エンジンを使用するように指定します。このチュートリアルで使用するスクリーンショットは、そのビルド定義に基づいています。

ARCAD 統合エンジン構成

「ARCAD-Integration Engine Configuration (ARCAD 統合エンジン構成)」タブで、関連する IBM i コンポーネントを自動的に組み込むようにデフォルトの Rational Team Concert SCM ビルド定義を完成させます。このビルド定義から、特定のターゲット環境のルールとデフォルト値を含む ARCAD 変更管理アプリケーションにリンクします。

APR を使用して IBM i コンポーネントをビルド・プロセスに追加する

以下の図 1 に示す例では、「STC」というアプリケーションが指定されています。アプリケーションは ARCAD 内で定義し、そこに変更を管理するためのルールとデフォルト設定を含めます。環境はアプリケーションによって定義されます。環境とはある目的 (開発、品質保証、本番などの目的) で使用するライブラリーとディレクトリーを集めたものです。アプリケーションごとに、複数の開発環境を定義することができます。以下の例では、「D」環境が選択されています。これにより、ビルド定義は ARCAD 環境に関連付けられます。バージョンとは、変更セットのことです。この例では、「Create a new version (新規バージョンを作成)」が選択されています。統合タイプによって、ソースをバージョンに含めるのか、あるいはオブジェクトだけを配信するのかが決まります。

図 1. 「ARCAD-Integration Engine Configuration (ARCAD 統合エンジン構成)」タブ
「Build Definition (ビルド定義)」の「ARCAD-Integration Engine Configuration (ARCAD 統合エンジン構成)」タブ
「Build Definition (ビルド定義)」の「ARCAD-Integration Engine Configuration (ARCAD 統合エンジン構成)」タブ

IBM i ビルドをさらに詳細に構成して、追加のステップを実行したり、ビルド結果に関する詳しいフィードバックを Rational Team Concert に提供したりすることもできます。ARCAD は、この追加情報を使用してリストを作成します。図 2 では、ARCAD の情報が含まれる 2 つの追加リストが指定されています。これらのリストに含まれる情報は、ビルド結果の中に表示されます。「ARCAD-Integration Engine Configuration (ARCAD 統合エンジン構成)」タブで、このビルドの一環としてトリガーする ARCAD プロセスを指定することができます。これらの ARCAD プロセスは、「マクロ」と呼ばれます。図 2 では、BUILD マクロが指定されています。

図 2. 追加ビルド結果
「Build Definition (ビルド定義)」の追加 ARCAD オプション
「Build Definition (ビルド定義)」の追加 ARCAD オプション

BUILD マクロの内容は次のとおりです。

  • 変更されたソースをチェックアウトする
  • ソースをコンパイルする
  • 依存関係を検出する
  • 依存関係をコンパイルする
  • ファイル内のデータを処理する
  • その他

BUILD マクロにより、Rational Team Concert での作業時に、手作業で IBM i コンポーネントをスクリプト化する必要がなくなります。APR 拡張機能を使わずに Rational Team Concert を使用してテーブルに変更を加えた場合は、テーブルだけをストリームに配信することになります。後は、開発者次第です。ビルド・プロセスにこの自動化を定義することで、テーブル、テーブルのインデックスとビュー、そしてその他の従属オブジェクトが考慮されて追加されます。コンパイルは正しい順序で行われ、データはターゲット・ファイルに保持されます。さらに、オブジェクト所有権や権限などの作成パラメーターも管理されます。Rational Team Concert を使用して IBM i コンポーネントを手作業で管理したことがあるとしたら、これらの拡張機能を使ったビルドの実行結果を高く評価するはずです。図 3 に、APR 拡張機能によって提供された追加情報を示します。

ここに示されているビルドでは、PF が変更されました。APR 拡張機能を使用していないのであれば、ストリームに配信するのはこれだけです。しかしここでは APR が使用されているため、ご覧のように 2 つのリストが追加されています。上側のリストには、コンパイルされたすべてのコンポーネントと、これらのコンポーネントが組み込まれた理由が示されています。右のほうに目を向けると、「Modified (変更)」と「Recompile (再コンパイル)」というテキストが示されていることがわかります。「Recompile (再コンパイル)」として示されている項目は、ARCAD ビルド・エンジンが従属コンポーネントとして自動的に追加したものです。2 番目のリストには、オブジェクト自体が示され、必要となる IBM i 情報が提供されています。したがって、これ以上必要な作業はありません。作業は自動的に行われました。開発者は、この作業を手で行った場合に費やす時間を他のことに賢く使うことができます。

図 3. APR を使用したビルドの結果 ― テーブルに変更が加えられた場合
テーブルに変更が加えられた場合のビルド結果
テーブルに変更が加えられた場合のビルド結果

その他の検討すべき領域

分析ツールをプロセスに追加する

ビルドでの手作業のプロセスを自動化するということは、変更を行う際の作業が正確であることを意味します。その変更をツールに行わせることも検討してください。Rational Team Concert には、例えば開発者が IBM i 上のテーブルに含まれる特定のフィールドを使用するコンポーネントのすべてを表示する手段はありません。優れた分析ツールは、IDE にコンテキストに応じたメニューを追加して、Rational Team Concert での作業中に、開発者が簡単にこの情報を表示できるようにします。ARCAD Pack for Rational には ARCAD-Observer という形で、そのような分析ツールが組み込まれています (図 4 を参照)。

図 4. ARCAD-Observer による分析の追加
ARCAD Observer の依存関係解析
ARCAD Observer の依存関係解析

依存関係、呼び出しチェーン、渡されたパラメーター、データベース・リレーションシップなどに関する情報を、開発時に IDE で入手できることが、アジャイルにする上での成功の鍵です。分析を高速で行えるようにすれば、その影響はプロジェクトのコストに直接反映されます。しかも、これらの情報があれば、エラーの修正や、アプリケーションのモダナイゼーションをできるだけでなく、新しいテクノロジーにマイグレーションすることもできます。プロジェクトで分析に割り当てる時間を短縮することができれば、その分、実際のコーディング作業に時間を費やすことができます。

変更の一環としてテストを組み込む

この記事ではこれまで主に、APR、Rational Team Concert、および Rational Developer for i が作業を迅速化し、アジリティーを高め、自動化を行う (これが最も重要です) 開発者をどのように支援できるかに重点を置いて説明を進めてきました。これらのツールがどのようにして開発を自動化し、開発を容易に行えるようにすることができるかを見てきましたが、完全にアジャイルにするには、開発環境の枠を超えて、行った変更のテストとデプロイにも自動化を適用する必要があります。

ARCAD-Verifier は、テスト担当者の知識を取り込んでおき、必要に応じてその知識を瞬時に読み出せるようにするツールです。変更がテスト環境に配信された後、ボトルネックを回避して情報システム変更の品質を保証するには、自動化されたテストが必要になります。図 5 に、ARCAD-Verifier によるテスト結果を示します。

図 5. ARCAD-Verifier によって自動化されたテスト
ビルドに対して行った ARCAD-Verifier によるテスト結果
ビルドに対して行った ARCAD-Verifier によるテスト結果

ユーザーがアプリケーションの機能をテストする間、このツールはキーストロークとユーザー操作を取り込んで、この情報をテスト・シナリオとして保管します。また、テストによって影響を受けたコンポーネントを検出し、記憶します。つまり、ソフトウェアに変更が加えられた場合、このツールは該当するシナリオを自動的に収集して 1 つのキャンペーンにバンドルし、すべてのシナリオを自動的に実行します。それが完了すると、今回実行した結果と、前に実行して成功だったときの結果との違いが強調表示されます。これは、クライアントで表示することも、レポートにすることもできます。これらの違いは、データ、ユーザー・インターフェース、またはスプールされたファイルにある場合もありますが、これで、変更に伴う実際のリグレッションを簡単に見極めて修正できるようになります。

ARCAD-Verifier テスト・ツールを Rational Team Concert および ARCAD Pack for Rational と組み合わせると、ソフトウェアの変更をテスト環境に転送し、それらの変更に対してリグレッション・テストを行うまでのプロセス全体が、最初から最後まで完全に自動化されることになります。したがって、転送からテストまでのプロセスをより頻繁かつ簡単に繰り返すことができるだけでなく、継続的に行うことさえ可能です。このプロセスの各ステップを自動化によってより迅速かつ正確に実行できるようなったら、次に必要なのは、本番環境に迅速に変更を配信することです。

変更されたコンポーネントの自動デプロイ機能

ソリューションの一部として、リリース管理機能、つまり変更されたコンポーネントの自動デプロイ機能を組み込む必要があります。正確を期すには、デリバリー・システムと変更管理システムを緊密に結合させなければなりません。また、複数のプラットフォームに一斉にデリバリーできるシステムも必要です。そのようなシステムは、あらゆる種類のサーバーで必要となるプロセスを実行できるように、ANT のようなテクノロジーとインターフェースを取るのに十分なだけオープンにする必要があります。デプロイ機能を自動化すると、コストの削減やエラーの排除につながるだけでなく、生産性を向上させ、問題が発生した場合に変更をロールバックすることも可能になります。デプロイ機能の自動化は、保険だと思ってください。

継続的インテグレーションの実現

DevOps は、「Development and Operations」を省略した言葉です。DevOps の原則は、ソフトウェア・デリバリーを迅速に行えるようにして市場の機会を掴めるようにすること、また顧客からのフィードバックを受け取るまでの時間を短縮することに置かれています。DevOps は、開発チームと運用チームの間のコラボレーションを強化するほか、手作業のプロセスを自動化し、無駄をなくすことによって、スピード、コスト、品質、リスクのバランスを取ります。さらに、顧客からのフィードバック・ループを迅速化し、顧客のエクスペリエンスをより良いものにします。では、このプロセスを継続させるには、どうすればよいでしょう?

継続的インテグレーションでは、1 日数回、すべての開発者による変更のすべてを共有リポジトリーに統合する必要があります。そうすることで、問題を早期に発見して修正することが可能になります。変更を収集した後は、そのすべての変更に対して自動ビルドを実行します。この一連のプロセスは、Rational Team Concert で、ARCAD Pack for Rational の ARCAD-Deliver コンポーネントを使用すると、実現することができます。このプロセスを実行する頻度は、実際には自由に決めることができます。組織がこのプロセスを繰り返す頻度を決める際には、多くの要因が関わってきます。

自動ビルドをスケジューリングする

図 6 に、ビルド定義のスケジューリングを示します。この図で選択されている「Schedule (スケジュール)」タブでは、ビルドを実行するタイミングを自動化することができます。ビルド・プロセスを ARCAD-Deliver で自動化するには、次の方法があります。

  • 終日にわたり、一定の間隔でビルドが実行されるようにスケジューリングする (例えば、図 6 に示されているように 15 分間隔に設定)
  • 1 日の特定の時刻にビルドが実行されるようにスケジューリングする
  • スクリプトを使用して、変更されたソースがリポジトリーのストリームに配信された時点でビルドをトリガーする
    • この場合、ソースが変更されるたびに、ビルド・プロセスが自動的にトリガーされます。
図 6. ビルド定義 ― スケジューリング
ビルドのスケジューリング画面とオプション
ビルドのスケジューリング画面とオプション

更新するストリームと、そのストリームでの変更を処理するビルド定義は関連付けられます。それぞれが 1 つのストリームに関連付けられたビルド定義は、数多く作成することができます。ストリームを更新すると、特定のビルド定義がその変更を処理します。そのビルド定義は、トリガーされる場合も、スケジューリングされている場合も、手作業で要求される場合もありますが、特定のビルド定義が変更を処理することにより、そのストリームでの変更を管理するプロセスが、一貫性のある繰り返し可能なものになります。ストリームごとに異なる方法で管理することも可能です。標準的なセットアップでは、1 つのストリームが、ARCAD で管理される特定のステージング・エリアを指します。ARCAD は、IBM i の依存関係が正しいものであることを確認し、ARCAD-Deliver プロセスの一環として、そのステージング・エリアの内容を検証します。

ビルド結果の自動デプロイ機能

ビルドは、トリガーすることも、スケジューリングすることも、手作業で実行することもできます。ビルドが実行されると、リポジトリーから変更が取得され、それらの変更が処理され、正確性と一貫性がもたらされます。また、依存関係は ARCAD によって確実に処理されます。次に必要となるのは、一連の変更と依存関係を使用して、ターゲット環境を更新することです。ターゲット環境の更新についても、ビルドの一環として自動化することができます。これは、継続的インテグレーションの最後の部分となります。ARCAD-Deliver を使用して手作業でターゲット環境を更新することもできますが、この記事で説明しているのは、完全に自動化されたデリバリーです (図 7 を参照)。

図 6 に示した「ARCAD-Deliver Engine Configuration (ARCAD-Deliver エンジン構成)」タブで、スクリプト化されたターゲット環境の更新をトリガーすることができます。この例では、ARCAD 内に定義された、特定のテスト・エリアを更新するプロセスがトリガーされます。

ARCAD-Deliver で行われる処理は以下の次のとおりです。

  • 変更の内容を検証する
  • 依存関係が考慮されていることを確認する
  • ソースにリグレッションがないことを確認する
図 7. ビルド定義 ― 自動デリバリー
ビルド定義の追加オプション
ビルド定義の追加オプション

これで、継続的インテグレーション・プロセスは完成です。変更は所定の場所に収集され、テスト・シナリオを実行するなどのテスト・プロセスは完成していて、変更をテストできる状態になっています。変更のテストについても、終日一定の間隔で実行することや、リポジトリー内でソースが変更されるたびに実行することができます。

まとめ

この記事では、ARCAD Pack for Rational で IBM Rational Team Concert および Rational Developer for i を拡張することで、IBM i の開発とデプロイに対処する方法を取り上げたので、IBM i コンポーネントのアジャイル開発手法をサポートするように、これらのツールを構成する方法を把握できたはずです。このような自動化は、プロセスの各ステップで必要になってきます。Rational Team Concert は、タスクの追跡、ソース管理、アジャイル計画に、継続的ビルドと、作業形態に応じて構成可能なプロセスを統合します。素晴らしいソフトウェアを作成するために必要なすべてのものが、シームレスに統合されるというわけです。この ARCAD ツールセットと IBM による DevOps のツールセットが、IBM i 開発を継続的インテグレーション・ストラテジーに正確かつ自動的に組み込むために必要なサポートを提供します。IBM i の世界をアジャイルにしない理由はもうありません。必要なのは始めることだけです。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps, Rational
ArticleID=1013786
ArticleTitle=アジャイルな IBM i を実現する
publish-date=08272015