数年前、カレン氏と彼のチームは、中核となるデジタル資産管理プラットフォームであるフィガロの新しいリリースを展開する速度を向上させることを目的として、ソフトウェア テストの自動化を開始しました。それが功を奏し、テスト サイクルを数日短縮することができました。

しかし、テスト チームは開発チームと論理パーティション (LPAR) を共有しており、テスト戦略が成功したことで、時間が経つにつれて重要なソフトウェア開発が遅れ始めました。カレン氏とチームは、営業時間後にテストを実行することでこの問題に対処しようとしましたが、それは理想的ではないことが判明しました。

「私たちは変更を加え、テストが一晩実行されるのを待ち、バグを発見し、それを修正し、テストが一晩実行されるのを待つ......ということを何度も何度も繰り返し、私たち自身のプロセスを遅らせるようになっていました。

Figaro は、数百万行のコード、数千のテーブル、約 25,000 のプログラム オブジェクトを含む非常に大規模なシステムです。これまで、Power サーバー上の IBM i 上で実行されてきたため、IBM Power Systems Virtual Server への移行は自然でした。しかし、Cullen 氏の選択には、サーバーとオペレーティング システムの適切な組み合わせを見つけるだけではありません。

IBM Power Systems Virtual Server と CSI のサービスとしてのテスト製品を利用することで、Cullen 氏とチームは、必要なときに必要なだけのコンピューティング能力を利用できます。「このセットアップを使用すると、必要なバージョンの Figaro と適切なデータ セットを備えた仮想サーバーをリクエストし、それに対してテストを実行してから、仮想サーバーを削除できます」と Cullen 氏は言います。

適切なバージョンの Figaro にアクセスできることが重要です。FNZ の現在のリリース スケジュールでは、四半期ごとにソフトウェアの新しいバージョンが作成され、2 週間ごとにパッチが提供されます。テストを効率的かつ費用対効果の高いものにするために、カレン氏のチームは必要に応じて正確な最新バージョンのソフトウェアを起動できる必要があります。「実行にわずか 15 分しかかからないテストを実行するために、作業環境を構築するために大量のパッチをインストールしなければならないという状況は望んでいません。すべてを事前に構築する必要があります。」と彼は言います。 。

これを達成するために、チームは、レイヤーを使用してイメージを構築する Docker スタイルのアプローチに依存しています。「スタート地点が決まっていて、その上にレイヤーを重ねていく。 私たちはストックされた IBM Power イメージを取得し、完全に動作する環境が完成するまで、徐々に多くの構成ソフトウェアを重ねていきました」と Cullen 氏は説明します。

現在、Cullen 氏のチームは、新しく公開されたアーティファクトを識別するウォッチャー プログラムを使用して、イメージ構築プロセス全体を自動化し、すべてを最新の状態に保ちました。「システムのバージョン 1.2 から 1.3 にアップグレードしたいとします。バージョン 1.3 パッチをアーティファクト リポジトリにプッシュすると、ウォッチャーはそれを確認し、仮想マシン上で以前のバージョンをスピンアップし、バージョン 1.3 パッチをインストールし、結果を保存して仮想マシンを削除します。」

このプロセスの結果、FNZ には常にテスト可能な環境が整っています。「私たちがしなければならないのは、適切なイメージを見つけてスピンアップし、テストを実行することだけです。これで完了です」と Cullen 氏は言います。

さらに、Docker ベースのアプローチでは、中間層の何かが変更された場合でも、周囲の層を再構築する必要がありません。「それは非常に効率的です」とカレンは言います。

CSIソリューションは、 Red Hat® OpenShift® 上で動作する IBM Cloud Pak® マルチクラウド管理テクノロジーも活用している（リンクはibm.comの外にあります）。具体的には、 Red Hat Ansible® (リンクは ibm.com 以外にあります) の自動化スクリプトがアプリケーションを完全にデプロイする間、FNZ のクラウド自動化管理機能が Terraform システム定義の整理、テンプレート化、パラメータ化を支援します。