目次


IBM UrbanCode Deploy を使用して継続的デリバリーを実装する

SoftLayer 上の DevOps ソリューションを探る

Comments

はじめに

DevOps とは、継続的ソフトウェア・デリバリーによって、組織が市場機会を捉え、顧客からのフィードバックにより迅速に対応し、速度、コスト、品質、リスクのバランスを取れるようにするためのエンタープライズ機能です。DevOps では、リーンおよびアジャイルの原則をソフトウェア・デリバリー・サイクル全般に適用することで、組織が他とは違う魅力あるカスタマー・エクスペリエンスを創出し、タイム・ツー・バリューを短縮し、革新を実現する能力を高められるようにします。IBM は、DevOps の実装をサポートするソフトウェア製品をいくつか提供しています。この記事では、IBM UrbanCode Deploy を使用して継続的デリバリー・ソリューションを実装する方法を、設計の側面から実装の詳細まで説明します。

この記事は、SoftLayer 上で Workload Automation as a Service プロジェクトに対して DevOps を実装するというケース・スタディーを基に作成されています。

継続的デリバリー・ソリューションの設計

継続的デリバリー・ソリューションを作成するには、設計フェーズが重要です。設計フェーズとは、機能面でのサポートとトレーニングの要件を詳細な予備設計という形にするフェーズです。

このフェーズでは以下のことを行います。

  • コンポーネントを特定する
  • 継続的デリバリーのワークフローを定義する
  • 環境を定義する

コンポーネントを特定する

ソリューション・ライフサイクルの設計フェーズで、ソリューションを構成するコンポーネント間の相互関係を表すアーキテクチャーを設計します。ソリューションを構成するコンポーネントとは、継続的デリバリー・ソリューションに含めることになるソフトウェア・コンポーネントのすべてです。

ケース・スタディーでは、WAaaS (Workload Automation as a Service) アーキテクチャーの 2 つのメイン・コンポーネント、Workload Automation MasterDynamic Workload Console を特定しました。

特定したコンポーネントごとに、それぞれのコンポーネント上で実行可能なデプロイメント、構成、運用のすべてのプロセスを設計します。

私たちの環境では、各コンポーネントに対して以下のプロセスを特定しました。

  • Workload Automation Master コンポーネントのプロセス
    • コンポーネントを更新するデプロイメント・プロセス
    • ワークロードをプライマリー・マスター・コンポーネントからバックアップ・マスター・コンポーネントに移す運用プロセス
    • ワークロードをバックアップ・コンポーネントからマスター・コンポーネントに移す運用プロセス
    • デプロイ後のヘルス・チェックを実行する運用プロセス
  • Dynamic Workload Console コンポーネントのプロセス
    • コンポーネントを更新するデプロイメント・プロセス
    • コンポーネントをクラスター構成に結合する運用プロセス
    • コンポーネントをクラスター構成から結合解除する運用プロセス
    • デプロイ後のヘルス・チェックを実行する運用プロセス

すべてのプロセスを設計します。さらに、各プロセスを構成するすべての論理ステップを指定します。

デプロイメント・プロセス

デプロイメント・プロセス設計フェーズは、まず、ネイティブ・デプロイメントにするか、アドホック・デプロイメントにするかを選択するところから始めます。

  • ネイティブ・デプロイメントでは、公式の製品インストールを使用します。この手法を選択すると、迅速かつ容易に実装することができますが、デプロイメントに時間がかかり、使用される成果物のサイズが大きいという欠点があります。ただし、通常は、継続的デリバリー・ソリューションでのコンポーネントの更新は、わずかな変更が前提となります。製品の完全なアップグレードは必要となりません。更新プロセスが複雑な場合には、この手法をお勧めします。
  • アドホック・デプロイメントでは、コンポーネントでの変更をデプロイするために必要なすべてのステップを実装します。変更をデプロイする時間は、ネイティブ・デプロイメントよりも短縮されます。デプロイメント中に使用される成果物も、ネイティブ・デプロイメントより小さくなります。また、UrbanCode Deploy で構築するプロセスでは、実行するステップを極めて柔軟に制御することができます。ただし、この手法の場合、設計と実装が複雑になります。

適切な手法を選択するには、いくつかの異なる側面の利点と欠点を評価します。次の側面について検討してください。

  • デプロイする新規プロセス・ワークフローの開発という点でのネイティブ・インストールの可用性
  • ビルドとデプロイメントに必要な時間が短縮されるようにインストールを小さく分割できるかどうか
  • インストールする成果物のサイズ。私たちのケースでは、コンポーネントのイメージをインターネット経由で SoftLayer クラウドに転送する必要がありました。

WAaaS プロジェクトでは、Workload Automation Master コンポーネント (表 1 を参照) と Dynamic Workload Console (表 2 を参照) について、それぞれの手法を分析しました。

表 1. Workload Automation Master コンポーネントについてのインストール手法の比較
Workload Automation Master コンポーネントネイティブ・インストールアドホック・デプロイメント
実装時間3 日30 日
デプロイメント時間15 分10 分
成果物のサイズ1.6 GB800 MB 以下
表 2. Dynamic Workload Console についてのインストール手法の比較
Dynamic Workload Consoleネイティブ・インストールアドホック・デプロイメント
実装時間3 日5 日
デプロイメント時間40 分10 分
成果物のサイズ1.2 GB400 MB

Workload Automation Master コンポーネントについては、インストール・プロセスに伴うステップの数と複雑さから、ネイティブ・インストールのほうが、都合が良いと考えました。一方、Dynamic Workload Console のデプロイメントには、アドホック手法を選択しました。

インストール手法を決定した後は、論理プロセスの設計を行い、各論理プロセスを構成するすべてのステップを明らかにする必要があります。

Workload Automation Master コンポーネントのネイティブ・インストールは、IBM Installation Manager で行うことにしました。このコンポーネントを更新 (デプロイ) するステップは、以下のとおりです。

  1. パッケージ (成果物) をダウンロードします。
  2. Workload Automation Master のプロセスを停止します。
  3. 応答ファイルを構成します。
  4. 構成した応答ファイルを使用して、サイレント・インストールを実行します。

アドホック手法を採用した Dynamic Workload Console を更新 (デプロイ) するステップは、以下のとおりです。

  1. パッケージをダウンロードします。
  2. Dynamic Workload Console のプロセスを停止します。
  3. WAR ファイルをデプロイします。
  4. ペイロードを解凍します。
  5. Dynamic Workload Console のプロセスを開始します。

運用プロセス

コンポーネントの新規バージョンをデプロイする前後に実行する処理を、運用プロセスを使用して定義します。WAaaS プロジェクトでは、Workload Automation Master と Dynamic Workload Console の両方に対して、いくつかの運用プロセスを特定しました。

運用プロセスの設計フェーズでは、特定したプロセスごとのステップを定義します。例えば、ワークロードをプライマリー Workload Automation Master ノードからバックアップ (セカンダリー・ノード) に移す運用プロセスには、以下の 4 つのステップが必要です。

  1. プライマリー・ノードを特定します。
  2. ワークロードをプライマリーからセカンダリーへ移します。
  3. プライマリー・ノードでのプロセスを停止します。
  4. セカンダリー・ノードでプロセスを開始します。

環境を定義する

この設計フェーズで重要となるのは、継続的デリバリー・ソリューションに含めるすべての環境を定義することです。

このフェーズでは、テスト環境と本番環境を識別してください。

WAaaS プロジェクトで識別した主要な環境は、以下の 3 つです。

  1. 品質保証 (QA) 環境
  2. ステージング環境
  3. 本番環境

それぞれの環境について、どのノードを含めるか、そしてそれぞれのノードにはどのコンポーネントをデプロイしなければならないかを明らかにします。

また、ノードごとのネットワークも明らかにしなければなりません。

WAaaS プロジェクトでは、以下の結果になりました。

  1. QA 環境のすべてのノードは、IBM ネットワークに配置します。
  2. ステージング環境のすべてのノードは、SoftLayer クラウドに配置し、ステージング用アカウントと関連付けます。
  3. 本番環境のすべてのノードは、SoftLayer クラウド・ネットワークに配置し、本番用アカウントと関連付けます。

本番環境のノードとステージング環境のノードは、どちらも SoftLayer クラウドに配置されますが、それぞれが配置されるネットワークは異なります。

継続的デリバリーのワークフローを定義する

前のセクションで設計したコンポーネントと環境を基に、それぞれの環境でコンポーネントをデプロイして構成するタイミングと方法に応じて、継続的デリバリーのワークフローを設計します。最初に、ワークフロー全体を設計し、環境間の関係を定義します。

WAaaS プロジェクトでは、ワークフロー全体の始まりとなるのは開発アクティビティーです。ビルド検証テスト (BVT) が正常に完了した後、そのビルドはビルド・リポジトリーにコピーされます。ビルド・リポジトリーで新しいビルドが利用可能になると同時に、QA 環境の更新が開始され、自動化されたテスト・ケースが実行されます。

自動化されたテスト・ケースが正常に完了すると、ビルドは QA 合格済みとして認定され、ステージング環境が自動的に更新されます。続いてステージング自動テストが正常に完了すると、ビルドは本番環境で運用可能な状態になり、同じく承認プロセスの後に本番環境が更新されます。

ワークフロー全体を定義した後は、特定の環境ごとのワークフローを定義する必要があります。具体的には、その環境でコンポーネントをデプロイする順序と、必要条件および前提条件を定義します。

例えば、WAaaS プロジェクトでの QA 環境には、以下のワークフローを定義しました。

  • すべてのコンポーネントを並行して更新する
  • 自動テストを実行する
  • QA 合格済みとしてバージョンを認定する

UrbanCode Deploy を利用した継続的デリバリーの実装

設計仕様が完成した後は、実装フェーズに入ることができます。このフェーズで必要になる作業は、環境を構成し、その環境用に特定されたコンポーネントを UrbanCode Deploy コンポーネントとして実装し、それぞれの環境を UrbanCode Deploy アプリケーション環境として実装し、そしてワークフローをアプリケーション・プロセスとして実装することです。

ソリューションを実装するために必要なステップは、以下のとおりです。

  • 物理環境のインストールおよび構成
  • コンポーネントの実装
  • アプリケーションの実装

UrbanCode Deploy オブジェクト (リソース、環境、コンポーネント、アプリケーション) ごとに、その特定のオブジェクトの読み取り、変更、使用を許可する「チーム」を指定する必要があります。

チームの中で異なる役割を定義し、役割ごとに固有のアクセス権 (読み取り、変更、削除など) を割り当てることができます。

セキュリティー設定を構成するには、「Setting (設定)」 > 「Security (セキュリティー)」の順に選択します。

物理環境のインストールおよび構成

まず始めに、環境を構築します。

WAaaS DevOps ソリューションでは、図 1 に示す環境を構築しました。

図 1. WAaaS DevOps ソリューションのアーキテクチャー
継続的デリバリー・ソリューションのアーキテクチャーを示す図
継続的デリバリー・ソリューションのアーキテクチャーを示す図

UrbanCode Deploy インストール済み環境では、vSphere サーバーにホストされる 2 つの仮想マシンを使用しています。1 つはデータベース用、もう 1 つは UrbanCode Deploy サーバー自体を対象とした仮想マシンです。

最初の実装には、単純なソリューションとして、MSSQL サーバーがインストールされた Windows マシンと、UrbanCode Deploy サーバー用の Linux RHEL 6 マシンを使用することにしました。

RHEL マシンのインストール時に、//var/usr/home/opt、および /tmp のそれぞれに個別の論理ボリュームを定義し、ファイアウォールを無効にし、ラン・レベルを 3 に設定しました。

UrbanCode Deploy マシンでも、NFS (Network File System) サーバーの共有部分をマウントして、インストール・イメージのリポジトリーとして使用します。こうすることにより、ディスク領域をより柔軟に管理できるようになります。

UrbanCode Deploy サーバーからは、複数の独立した環境を管理しなければなりませんでした。具体的には、SoftLayer ネットワークに配置されたステージング環境と本番環境、そして場合によってはさらにいくつものリモート環境を管理します。

SoftLayer ネットワークにアクセスするには VPN を使用することができますが、私たちのラボでは VPN を使用できないため、別の手法を採ることにしました。マシンの導入時にパブリック IP アドレスが割り当てられるようにしたので、このインターフェースを利用して、サーバーとリレー・マシンとの間の通信を確立することにしたのです。

SoftLayer 環境に定義された Linux RHEL 6 マシンに UrbanCode Deploy リレー・エージェントをインストールして、環境ごとに 1 台のリレー・マシンを用意しました。これらのマシンは、SoftLayer ネットワーク内でのプライベート・インターフェースと、パブリック・インターフェースを持ちます。

また、iptables を構成して、パブリック・インターフェースのあらゆるポートでの接続をドロップするようにしました。ただし、IBM パブリック・アドレスから開始される SSH 接続は例外です。SSH は、パブリック・アドレスに対して公開鍵認証のみを許容するようにセットアップされているためです。

UrbanCode Deploy サーバーは、リモート・リレー・サーバーとの SSH 接続を確立し、サーバーのポートをリレー・サーバーに転送し、リレー・ポートを 127.x.x.x インターフェース上のサーバーに転送します。

例えば、本番環境の場合には、以下のコマンドを使用します。

ssh -f -n -N -x -R 8080:localhost:8080 -R 8443:localhost:8443 -R 7918:localhost:7918 -R
1099:localhost:1099 -L 127.0.0.3:7916:localhost:7916 -L
127.0.0.3:20080:localhost:20080 -L 127.0.0.3:36829:localhost:36829 -o
StrictHostKeyChecking=yes -o ExitOnForwardFailure=yes -M -S
/tmp/ssh-${remote_user}@${production_relay}:${ssh_port} -p ${ssh_port} -l ${remote_user} $
{production_relay}

上記のコマンドは、バックグラウンド SSH プロセスを開始します。このプロセスによって、リレー・ポートがループバック・アドレス 127.0.0.3 に転送され、サーバー・ポートがリレー・サーバーに転送されます。ControlMaster オプションおよび ControlPath オプションを指定すると、接続がまだ有効であるかどうかを (OpenSSH -O オプションによって) チェックして、必要な場合には接続を再開するのが簡単になります。私たちは、接続を 5 分ごとにチェックし、必要に応じて再開する、周期ジョブをセットアップしました。このように、UrbanCode Deploy サーバーは、どのリレー・サーバーと通信する際にも別々のループバック・アドレスの同じポートを使用するため、必要となるすべてのリモート環境をサポートすることができます。この機能により、SoftLayer 内の 2 つのクラウドの一方にステージング環境を、もう一方に本番環境を作成し、これらの環境を管理することが可能になりました。

私たちは SoftLayer 環境での転送をスピードアップするために、リモート側にもリポジトリーをセットアップしました。リレー・サーバーに Apache HTTP サーバーをインストールし、インストール・イメージが含まれるディレクトリーをエクスポートしました。エージェントがこれらのイメージにアクセスするには、curl や wget などの標準的なツールを使用するため、ラボ内のネットワーク・トラフィックを最小限に抑えられます。

コンポーネントの実装

まず、設計フェーズで特定した各コンポーネントに対応する新規 UrbanCode Deploy コンポーネントを定義する必要があります。

コンポーネントを定義するには、以下の内容を実行します。

  • ソース・リポジトリーを構成する
  • コンポーネントのプロパティーを指定する
  • コンポーネント・プロセスを実装する

ソース・リポジトリーを構成する

ソース・リポジトリーの定義は、コンポーネントごとに必要です。ソース・リポジトリーには成果物の異なるバージョンが格納されるためです。WaaaS DevOps プロジェクトでは、ソース・リポジトリーとして、バージョン管理ファイル・システムを使用しています。図 2 に示すように、私たちはバージョンを自動的にインポートするように UrbanCode Deploy を構成しました。

図 2. UrbanCode Deploy でのコンポーネント定義
コンポーネント構成パネルのスクリーン・キャプチャー
コンポーネント構成パネルのスクリーン・キャプチャー

コンポーネントの新規バージョンが使用可能になるたびに、そのバージョンがファイル・システムのパス /ucd_data/DEVOPS/WAaaS_Master/<version_id> にコピーされます。これを、UrbanCode Deploy がインポートします。

「Versions (バージョン)」タブを選択すると、システムにインポートされたすべてのバージョンを画面に表示することができます (図 3 を参照)。

図 3. UrbanCode Deploy に表示されたコンポーネント・バージョンのリスト
コンポーネントの「Versions (バージョン)」タブのスクリーン・キャプチャー
コンポーネントの「Versions (バージョン)」タブのスクリーン・キャプチャー

私たちは、最新の 4 つのバージョンだけが保存されるように、「System (システム)」 > 「Settings (設定)」 > 「Artifact Cleanup (成果物のクリーンアップ)」の順に選択して表示される画面で、クリーンアップ・ポリシーを定義しました。

図 4. UrbanCode Deploy でのクリーンアップ・ポリシーの定義
成果物のクリーンアップ・ポリシーを定義する画面のスクリーン・キャプチャー
成果物のクリーンアップ・ポリシーを定義する画面のスクリーン・キャプチャー

コンポーネントのプロパティーを指定する

使用するパラメーターは、コンポーネント・レベルでデフォルト値が定義されていなければなりません。例えば、ある特定のコンポーネントのインストール・パスがプロパティーとして定義される場合、このプロパティーの値はほぼ確実に、環境やリソースごとにカスタマイズされるからです。一方、デフォルト値をコンポーネント・レベルで定義すると、役立つ場合もあります。コンポーネントの新規プロパティーを定義するには、「Component (コンポーネント)」 > 「Configuration (構成)」タブ > 「Component Properties (コンポーネント・プロパティー)」の順に選択します。

コンポーネント・プロセスを実装する

コンポーネント・プロセスは、コンポーネント上で実行される、自動化されたタスクを表現します。これらのプロセスは、そのコンポーネント上で別のタスクをデプロイ、インストール、アンインストール、更新、または実行することができます。「Component (コンポーネント)」 > 「Processes (プロセス)」の順に選択すると、新規のコンポーネント・プロセスを定義することができます。

図 5. UrbanCode Deploy でのコンポーネント・プロセスの作成
コンポーネント・プロセス定義パネルのスクリーン・キャプチャー
コンポーネント・プロセス定義パネルのスクリーン・キャプチャー

プロセスには、以下に挙げるタイプがあります。

  • デプロイメント: このタイプのプロセスは、あるコンポーネント・バージョンをターゲット・リソースにデプロイし、そのコンポーネント・バージョンが正常に実行されたら、インベントリーを更新します。
  • 構成デプロイメント: このタイプのプロセスは、構成のみをデプロイし、コンポーネント・バージョンや成果物はデプロイしません。プロセスをこのタイプに設定すると、構成 (プロパティーまたは構成テンプレートを使用) がターゲット・エージェントに適用されてから、リソース構成インベントリーが更新されます。
  • 運用: このタイプのプロセスは、コンポーネント・バージョンに応じて任意のステップを実行します。成果物や構成を追加または削除することはしません。

コンポーネント・プロセスは、複数のステップで構成されます。使用可能なステップは、「Available Plugin Steps (使用可能なプラグイン・ステップ)」リストに記載されています。UrbanCode Deploy には、いくつかのユーティリティー・ステップとプラグインが用意されています。

私たちのプロジェクトのコンポーネント・プロセスでは、さまざまなタイプのユーティリティー・ステップとプラグインを使用しています。以下に、その一例を記載します。

  • 成果物のダウンロード: 成果物を IBM UrbanCode Deploy リポジトリーからエージェントにダウンロードします。
  • シェル・スクリプト: マシンでシェル・スクリプトを実行します。
  • 解凍: ZIP ファイルを解凍します。
  • プロパティーの設定/取得: IBM UrbanCode Deploy プロパティー (リソース、コンポーネント) の値を取得します。
  • バージョンに対するステータスの追加/削除: 現在のコンポーネント・バージョンに対してステータスの追加や削除を行います。
  • トークンの置換: 特定のトークンを値のリストに置換します。これらの値はステップで直接指定するか、UrbanCode Deploy プロパティーを参照することができます。
  • コンポーネント・プロセスの実行: 別のコンポーネント・プロセスを実行します。
  • 汎用プロセスの実行: 汎用プロセスを実行します。

コンポーネント・プロセスの各ステップには、以下のものを定義することができます。

  • 前提条件

    前提条件は、ステップを実行する前に存在していなければならない条件を定義する JavaScript です。条件は、true または false に帰着しなければなりません。WAaaS プロジェクトでは、前提条件 properties.get("<properties_to_verify>") == "false" を使用して、プロパティーの値を検証してから、ステップを実行しています (<properties_to_verify> の許容値は、true または false です)。

  • 後処理スクリプト

    後処理スクリプトは、ステップの完了後に実行されます。通常、後処理スクリプトでは、期待される結果になっていることを確認します。WAaaS プロジェクトの場合は、後処理スクリプトを利用して、ステップの出力をプロパティーに設定し、その出力を他のステップでも使用できるようにしています。

    例えば、以下の後処理スクリプトを定義しています。

    properties.put("result", "default");
    if (properties.get("exitCode") != 0) {
               properties.put(new java.lang.String("Status"), new java.lang.String("Failure"));
           }
       else {
           properties.put("Status", "Success");
        scanner.register("^Output", function(lineNumber, line) {
               var temp=line.split("=");
    var out=temp[1];
              properties.put("result",out);
           });
           scanner.scan();
       }

    このスクリプトは、現行ステップの出力の一部を、result というプロパティーの値として設定します。

    メソッド scanner.register("^Output", function(lineNumber, line) を使用して、出力の中から、出力ストリングで始まる行を見つけます。続いて、スクリプトは "=" の後のストリングを識別し、そのストリングを result プロパティーとして設定します。例えば、ステップの出力が Output=value1 だとすると、result プロパティーの値は value1 となります。

プロパティー値は、ステップ間で受け渡しすることができます。あるステップで後処理スクリプトを使用して特定のプロパティーを設定した場合、${p:<stepName/PropertyName>} という構文を使用して、そのプロパティーを別のステップで使用することができます。

コンポーネント・プロセスのフロー

プロセスのフローは、コンポーネント・プロセスのすべてのステップを結合して作成しなければなりません。プロセスのフローでは、ステップを使用して先行するステップを結合したり、スイッチを使用して条件付きステップを作成したり、等々ができます。

ステップの結果 (成功、失敗、またはその両方) に応じて、異なるフローを指定することもできます。

図 6. UrbanCode Deploy でのコンポーネント・プロセスの設計
コンポーネント・プロセスの例を示す図
コンポーネント・プロセスの例を示す図

コンポーネント・プロセスのフローは複雑になる場合があるため、「コンポーネント・プロセスの実行」ステップを使用するプロセスでは、サブプロセスを作成して使用すると有用な場合があります。

図 7 に、「マスターの更新」プロセスとして実装したコンポーネント・プロセスの例を示します。

図 7. 「マスターの更新」プロセスとして実装したコンポーネント・プロセスの例
複雑なコンポーネント・プロセスの例を示す図
複雑なコンポーネント・プロセスの例を示す図

アプリケーションを定義する

継続的デリバリー・ソリューションを実装するには、コンポーネントを作成してエージェントをインストールした後、アプリケーションを作成する必要があります。

UrbanCode Deploy のアプリケーションは、一緒にデプロイしなければならないすべてのコンポーネントを 1 つにまとめます。その方法は、各コンポーネントの異なるバージョンを定義し、これらのコンポーネントが本番環境に移されるまでの過程で経由しなければならない各種の環境を定義するというものです。アプリケーションは、それぞれの環境でコンポーネントに必要となる構成ホストと構成システム (「リソース」と呼ばれます) もマッピングします。

アプリケーションでは、自動化されたデプロイメントとロールバック、そして同様のタスクも実装します。これらのタスクは、「プロセス」と呼ばれます。ただし、アプリケーション・レベルでは、プロセスが関係してくるのは、デプロイメントおよび関連タスクに必要なコンポーネントとリソースのみです。一方、コンポーネント・プロセスは、コマンドおよび関連タスクの実行に関係します。

図 8. UrbanCode Deploy でのアプリケーションの作成
アプリケーションの作成パネルのスクリーン・キャプチャー
アプリケーションの作成パネルのスクリーン・キャプチャー

UrbanCode Deploy 上で環境を定義する

作成したアプリケーションをベースに、新しい環境を作成します。

図 9. UrbanCode Deploy でのアプリケーション環境の作成
環境の作成パネルのスクリーン・キャプチャー
環境の作成パネルのスクリーン・キャプチャー

「Resources (リソース)」タブで、環境を構成するすべてのリソースを指定します。サブフォルダーを使用することで、環境の定義を構造化することができます。

環境を構成するすべてのエージェントを追加したら、エージェントごとに特定のコンポーネントを関連付けます。

図 10. UrbanCode Deploy でコンポーネントをリソースに関連付ける
環境の構成を行う画面のスクリーン・キャプチャー
環境の構成を行う画面のスクリーン・キャプチャー

承認プロセスの定義

環境に対して承認が必要な場合は、環境の「Configuration (構成)」タブで、「Require Approvals (承認が必要)」フラグにチェック・マークを入れます。プロセス免除のリストや、承認なしでもこの環境で開始できるアプリケーション・プロセスのリストを定義することもできます。

図 11. UrbanCode Deploy での承認プロセスの定義
環境の承認設定を行う画面のスクリーン・キャプチャー
環境の承認設定を行う画面のスクリーン・キャプチャー

最後に、「Approval Process (承認プロセス)」タブで、具体的な承認プロセスを定義します。

図 12. UrbanCode Deploy での承認プロセスの定義
承認プロセスの例を示す画面のスクリーン・キャプチャー
承認プロセスの例を示す画面のスクリーン・キャプチャー

環境のゲート

UrbanCode Deploy では、ゲートを設けるという方法で、アプリケーションを環境にプロモートするために満たさなければならない条件を指定することができます。ゲートが定義されるのは、環境レベルです。各環境には、単一のゲートと複数の条件、またはそのいずれかを設定することができます。ゲートは、以下のことを確実にするためのメカニズムになります。

  • ゲートで指定されたステータスになっているコンポーネント・バージョンだけが、環境にデプロイされること
  • アプリケーションに、プロモーションの品質基準についての合意が反映されること
  • 進化するアプリケーションに、監査可能なサインオフがあること

ある環境でアプリケーション・プロセスを実行するときには、プロセスに含まれる各コンポーネント・バージョンに、環境ゲートで指定されたステータスのタグを付ける必要があります。

WaaaS プロジェクトの場合には、以下の制約を定義しました。

  • ステージング環境にインストールするバージョンには、QA_OK (品質保証 OK) のタグが付けられていること
  • 本番環境にインストールするバージョンには、STAGING_OK のタグが付けられていること

「Component (コンポーネント)」タブの「Status (ステータス)」で、ステータスをバージョンに手作業で追加することができます。あるいは、「バージョンに対するステータスの追加/削除」ステップを使用したコンポーネント・プロセスによって、自動的にステータスを追加することもできます。

図 13. UrbanCode Deploy での環境ゲートの定義
環境ゲートの定義を行う画面のスクリーン・キャプチャー
環境ゲートの定義を行う画面のスクリーン・キャプチャー

高度な環境定義

動的環境を定義するには、「Manage continuous delivery in the dynamic cloud environment using UrbanCode Deploy」(developerWorks、2014年) を参照してください。

SoftLayer 上でリモート・リポジトリーを定義するには、「Managing remote repositories on a dynamic cloud network using UrbanCode Deploy」(developerWorks、2014年) を参照してください。

コンポーネントをアプリケーションに関連付ける

アプリケーションには、アプリケーション・プロセスで使用するすべてのコンポーネントを指定する必要があります。アプリケーションを選択してから「Components (コンポーネント)」タブを選択し、必要なすべてのコンポーネントを追加してください (図 14 を参照)

図 14. UrbanCode Deploy でのアプリケーションに含めるコンポーネントの定義
アプリケーションとコンポーネントとの関連付けを行う画面のスクリーン・キャプチャー
アプリケーションとコンポーネントとの関連付けを行う画面のスクリーン・キャプチャー

プロパティーの定義

コンポーネントのプロパティーについては前のセクションで紹介しましたが、環境または環境を構成するリソースに応じて、多種多様なプロパティーをプロセスで使用することができます。

例えば、コンポーネントをインストールするインストール・パスは、インストールするリソースによって異なることがあります。プロセスは汎用的でなければならず、すべての環境で使用できなければなりません。このことから、インストール・パスを変数プロパティーとして指定することができます。プロパティーは、さまざまなレベルで定義することができます。

  • コンポーネント・レベル: これが、プロパティーのデフォルト値です。環境レベルやリソース・レベルで指定されていない場合は、プロパティーはこの値で設定されます。
  • 環境レベル: コンポーネントまたは環境の「Properties (プロパティー)」タブで、プロパティーを定義することができます。どちらのタブで定義する場合も構文は同じですが、環境の「Properties (プロパティー)」タブで定義したプロパティーは、特定のコンポーネントに関連付けられることはありません。プロパティー値は、関連付けられた環境またはコンポーネント上で提供されます。コンポーネント環境で設定されたプロパティー値は、環境プロパティーで直接設定された同じ名前のプロパティー値よりも優先して使用されます。この場合、値は ${p:environment/<property_name>} で参照されます。
  • リソース・レベル: このレベルで定義されるプロパティーには、組み込みエージェントのプロパティーや、あらゆるカスタム・プロパティーが含まれます。これらのプロパティーには、それぞれに独自のタブがリソースにあり、${p:resource/<property_name>} で参照されます。

プロパティーが複数の場所で定義されている場合、その値は、「プロパティーの優先順位」に従って決定されます。以下に、プロパティーの優先順位が高いものから低いものの順に記載します。

  • プロセス
  • コンポーネント・バージョン
  • リソース
  • エージェント
  • 環境
  • コンポーネント
  • アプリケーション
  • システム

UrbanCode Deploy で継続的デリバリーのワークフローを定義する

環境を定義した後は、アプリケーション・プロセスの定義に取り掛かることができます。アプリケーション・プロセスを作成するには、コンポーネント・プロセスと同じように、プロセス・エディターを使用します。UrbanCode Deploy には、いくつかの共通プロセス・ステップが用意されています。これらの共通プロセス・ステップの他、関連付けられたコンポーネントに対して定義されているプロセスから、アプリケーション・プロセスを組み立てます。

関連付けられたコンポーネントごとに、以下のような各種のステップを定義することができます。

  • インストール
  • アンインストール
  • ロールバック
  • バージョンごとのプロセスの実行
  • 構成の適用

特定のタグが付けられたリソースだけで実行するように、各アプリケーション・プロセス・ステップを定義することができます。

図 15. 特定のタグが付けられたリソースのみが、プロセスを実行できるように制限する
プロセスの実行権限を特定のタグが付けられたリソースのみに制限する設定画面のスクリーン・キャプチャー
プロセスの実行権限を特定のタグが付けられたリソースのみに制限する設定画面のスクリーン・キャプチャー

図 16 に、WAaaS QA 環境のアプリケーション・プロセスの例を示します。

図 16. アプリケーション・プロセスの設計例
アプリケーション・プロセスの例を示す図
アプリケーション・プロセスの例を示す図

アプリケーション・プロセスを実行する

アプリケーション・プロセスは、オンデマンドで実行することも、スケジュールを指定して実行することもできます。プロセスを実行するには、「Application (アプリケーション)」 > 「Environment (環境)」タブの順に進み、図 17 に示されている実行アイコン (三角矢印) をクリックします。

図 17. UrbanCode Deploy のプロセス実行インターフェース
プロセス実行の例のスクリーン・キャプチャー
プロセス実行の例のスクリーン・キャプチャー

コンポーネントの新規バージョンが作成されるたびに、特定のアプリケーション・プロセスが環境で実行されるように定義することもできます。それには、「Component (コンポーネント)」 > 「Configuration (構成)」の順に進み、「Run process after creating a new version (新規バージョンの作成後にプロセスを実行)」にチェック・マークを付けて、該当するアプリケーション・プロセスとアプリケーション環境を選択してください。

ビジネス上のメリット

継続的デリバリーは、ソフトウェア・デリバリーを自動化して改善する、新しいソフトウェア開発手法です。その目標は、品質の面で妥協することなく迅速かつ確実に、機能強化やバグ・フィックスを顧客に繰り返し提供できるようにすることに置かれています。

継続的デリバリーがビジネスにもたらす大きなメリットには、次の 2 つがあります。

  1. 製品を市場に出すまでの時間を短縮することができます。そして、ターゲット市場から実際のフィードバックを得られます。ビジネス計画に根本的な落ち度があるとしたら、何ヶ月、あるいは何年もプロジェクトの実装に資金を注ぎ込んだ末にようやく発見するのではなく、その欠陥をできるだけ早く見つけなければなりません。継続的デリバリーにより、顧客のニーズに応じて、その要求に対する迅速な対応が可能になります。
  2. 特に、プロジェクトに長い期間をかけた末に大々的にリリースするという従来の方法に比べ、継続的デリバリーはソフトウェア・デリバリーに伴うリスクを大幅に削減するプロセスになります。したがって、より正確にコストを予測できるようになります。

まとめ

この記事では、私たちのケース・スタディーである WAaaS DevOps プロジェクトを例に、継続的デリバリー・ソリューションを作成するための簡単なガイドを提供しました。WAaaS DevOps プロジェクトでは、UrbanCode Deploy のおかげで、わずか数週間でソリューション全体を作成することができました。


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


関連トピック

  • IBM developerWorks の Developer Center で、UrbanCode Deploy について詳しく学んでください。
  • DevOps Services を利用してクラウド内でアプリを開発する」を読んで、DevOps Services (JazzHub) を利用して、クラウドでのソフトウェアの計画、追跡、開発、デプロイメントの共同作業を始めてください。
  • UrbanCode Deploy に関するその他の有用なリソースを見つけるには、UrbanCode Deploy インフォメーション・センターを参照してください。
  • さまざまな IBM 製品や IT 業界のトピックに焦点を絞った developerWorks テクニカル・イベントで時代の流れをキャッチしてください。
  • Twitter で developerWorks をフォローしてください。
  • 初心者向けの製品のインストールおよびセットアップから熟練開発者向けの高度な機能に至るまで、さまざまに揃った developerWorks デモを見てください。
  • SoftLayer トライアルで、1 ヶ月無料のクラウド・サーバーを試してください。
  • IBM UrbanCode Deploy の無料の試用版をダウンロードしてください。
  • 30 日間無料の Workload Automation を試してください。

コメント

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, DevOps
ArticleID=985186
ArticleTitle=IBM UrbanCode Deploy を使用して継続的デリバリーを実装する
publish-date=10092014