継続的配信および Micro Focus 開発ツール

継続的配信の概要」および「継続的配信のワークフロー」セクションでは、継続的配信の概念を紹介し、継続的配信がプロセスとしてどのように機能するかを概説します。本セクションでは、継続的配信のプロセスについて説明し、Micro Focus が提供する各種製品がそのプロセスにどのように適合し、そのプロセスに価値をもたらすかを示します。

以下の図は、「継続的配信のワークフロー」セクションで紹介しているプロセスを示していますが、プロセスのさまざまな段階で使用できる Micro Focus 製品が追記されています。この図では Micro Focus 製品を紹介していますが、説明されているプロセスでは Micro Focus 製品の使用は必須ではないため、プロセスの一部でサードパーティ製品をすでに使用している場合は、引き続きその製品を使用して Micro Focus 製品と統合できます。

継続的配信は事実上、継続的インテグレーション プロセスの拡張であるため、この図の最初の 5 つの手順は、「継続的インテグレーションおよび Micro Focus 開発ツール」で示した図の手順と同じです。

上図内の数字の箇条書き箇所の詳細は次のとおりです。

  1. 開発者は、Enterprise Developer を使用してコードをチェックアウトして、プライベート ワークスペースにチェックインします。次に、Enterprise Developer の単体テスト機能を使用して変更を加え、ローカルでテストします。

    この図では、ChangeMan ZMF をソース コード管理システムとして使用する方法を示していますが、その製品だけを使用することに限定されるものではありません。Enterprise Developer は SCC 準拠のソース コード管理システムと連携するため、Enterprise Developer では実質的にあらゆるソース コード管理システム (Micro Focus 製品またはサードパーティ製品であるかにかかわらず) とシームレスに作業できます。

    メインフレーム開発では、Enterprise Developer および Enterprise Sync (Micro Focus Enterprise スイートの別の製品) を併用することで、メインフレームのソース コードを分散型のソフトウェア構成管理プラットフォームに複製し、並列アプリケーション開発の効率を大幅に向上させることが可能です。

  2. 完了後、開発者はソース管理リポジトリへの変更をチェックインします。
  3. CI サーバーはソース管理リポジトリを監視し、変更を検出すると、関連するソースのビルドをトリガーします。ビルド アクションは CI サーバーによってトリガーされますが、ビルド アクション自体は Enterprise Developer によって実行されます。通常は Apache Ant または MSBuild スクリプトを使用します。
  4. ビルドが成功すると、CI サーバーは次のようなアクティビティを実行します。
    • ディプロイ可能な成果物をテストで使用できるようにする
    • 作成されたばかりのコードのバージョンにビルド ラベルを割り当てる
    • 関連するチーム メンバーに、ビルドが正常に生成されたことを通知する
    • Enterprise Test Server での単体テストおよび統合テストの実行をトリガーする

    この時点で、手順 2 でチェックインされた変更が正常にビルドされ、ビルドに使用されたソース コードにビルド ラベルが適用されています (そのため、必要に応じてビルドを再作成できます)。

    ビルドに失敗した場合、CI サーバーは手順 1 からのプロセスを再開する関連開発者に通知を送ります。開発者は、Enterprise Developer を使用してビルド エラーを解決するために必要な変更を行います。

  5. 単体テストおよび統合テストが行われた後、関連するチーム メンバーにテスト結果が通知されます。

    この時点で、手順 2 でチェックインされた変更は正常にビルドされテストが完了しています。手動の作業はほとんどあるいはまったく不要です。

  6. 単体テストおよび統合テストが正常に完了すると、CI サーバーは Micro Focus Silk を使用して、より包括的で自動化された受け入れテストの実行をトリガーします。

    メインフレームでホストされるアプリケーションの場合、この段階でのテストでは、Windows ワークステーション上で行われるテストに加えて、メインフレームでの変更のテストも含める必要があります。

  7. 受け入れテストにすべてパスした場合、リリースするかどうかが決定されます。

    受け入れテストに失敗した場合、CI サーバーは手順 1 からのプロセスを再開する関連開発者に通知を送ります。開発者は、テストの失敗を解決するために必要な変更を行います。

  8. 検証の決定をリリースする場合は、Micro Focus Deployment Automation または Micro Focus Release Control を使用して、ビルドされたパッケージを適切な環境にリリースまたはディプロイします。

    検証の決定をリリースしない場合は、関連するチーム メンバーに通知され、開発作業は通常どおり継続されます。

Jenkins を使用して上記リストの CI サーバー タスクを実行する方法については、「Enterprise Developer および Jenkins の連携」を参照してください。

次のリストでは、継続的配信のプロセスに関わる各 Micro Focus 製品を簡単に概説します。