2022/1/1 - 読み終える時間: 8 分

Steps to load HCL Version Vault Express image (OVA file) into a Virtualisation tool (VirtualBox VM manager) の翻訳版です。

HCL Version Vault Express のイメージ（OVA ファイル）を仮想化ツール（VirtualBox VM manager）に読み込むための手順

2021年12月30日

著者: Avinash Srinivasamurthy / Senior Technical Specialist, HCL

トピック

1. Oracle Virtual box ソフトウェアのインストール
2. VersionVault Express OVAファイルのダウンロード
3. VVEイメージをVirtualBoxにロードしてインポート
4. VVE インスタンス用のストレージの作成、追加
5. ストレージを追加した VVE インスタンスの再起動
6. VVE サーバ URL にアクセス

1. Oracle Virtual box ソフトウェアのインストール

VVE は OVA ファイル（Open Virtual Appliance file）としてリリースされていますので、ダウンロードして VM プロビジョニングツールや Hypervisor に VM としてロードする必要があります。

このドキュメントでは、VersionVault Express OVAイメージをOracle Virtual Box VM managerでロードする方法について説明します。

2. VersionVault Express OVAファイルのダウンロード

VVE OVA ファイルは、HCL FNO サイト（https://hclsoftware.flexnetoperations.com/flexnet/operationsportal/startPage.do）からダウンロードすることができます。

3. VirtualBox に VVE イメージをロードしてインポート

3a) VirtualBox Manager を起動し、以下のスクリーンショットに従って、VVE イメージファイル (.ova ファイル) を読み込みます。

3b) 「インポート」をクリックし、OVA ファイルをブラウズしてください。

3c) ダウンロードした OVA イメージファイルを選択し、"Open"をクリックします。

3d)"Import"をクリックすると、VM イメージがロードされます。

3e) 読み込みが完了すると、VMマネージャーで「HCL VersionVault Express」VMが以下のように表示されます。

3f) VM を"Start" しようとすると、以下のような"Please add a new disk" というメッセージが表示されます。

VVEインスタンスには、明示的に接続されたストレージが必要なためです。

3g) ここでマシンを終了し、"Power off"してから、ストレージを作成して VVE インスタンスにアタッチするステップに 進みます。

4. VVE インスタンス用のストレージの作成、追加

4a) VVE インスタンスの設定アイコンをクリックします。

4b)"Storage"オプションを選択し、"Add hard disk"オプションを意味する"Controller: IDE"の隣にある"+"記号をクリックします。

4c)"ディスクイメージの作成"アイコン、次に"VHD"を選択します。

4d) VHDに割り当てる領域を選択し、"create"をクリックします。

4e) 新しい VHD が作成されたら、それをハイライトして"選択" をクリックします。

4f) これで、VVE インスタンス設定ウィンドウのストレージとして、VHD が以下のように表示されるはずです。

5. ストレージを追加したVVEインスタンスの再起動

5a) 任意のキーをクリックして、VVE サーバをスキップして起動することができます。

5b) VM に記載されている URL をメモしておくと、それが VVE サーバの URL になります。

6. VVEサーバーのURLにアクセス

6a) ブラウザで URL（VM インスタンスに表示されている）にアクセスし、VVE サーバーの設定に移動します。 https://192.168.1.79:8443/

6b) "詳細"と"ウェブページに移動"オプションをクリックすると、さらにURLにアクセスすることができます。

6c) このようにHCL VersionVault Registerのページが表示されるはずです。

6d) 任意の管理者IDとパスワードで登録できます。「登録」をクリックすると、まず管理者IDが作成されます。

6e) 登録が完了すると、VVE サーバーにアクセスできるようになり、さらに設定を続けることができます。

2021/12/16 - 読み終える時間: ~1 分

Resiliency for CI/CD Pipeline の翻訳版です。

CI/CD パイプラインのレジリエンス (復元性)

2021年12月14日

著者: Cassandra Stanek / Product Marketing Manager, HCL Accelerate & Launch

ITの黄金律はレジリエンス（回復力） です。侵入、ハッキング、予期せぬトラフィックの増加、ヒューマンエラーなど、デジタルの世界では常に起こることなので、プランBを用意する理由を挙げればきりがない。レジリエントなDevOps自動化フレームワークを構築することは、予期せぬ事態が発生した場合でも、アプリケーションデリバリプロセスを中断することなく継続できることを意味します。

HCL Launch 7.2.1 は、さまざまな方法でディザスタリカバリのためのレジリエントなフレームワークをサポートします。最も大きなものの1つは、分散型フロントエンドサーバー機能です。お客様がDevOpsを採用するにつれ、HCL Launchサーバーにログインするユーザーの数は増え続け、その追加アクティビティによって

分散型フロントエンドサーバーは、ユーザーの負荷を分散させ、すべてのユーザーがUI内でスムーズな体験をできるようにするための優れた方法です。現在の環境にこれらのサーバーを追加することで、フロントエンドの単一障害点から脱却し、耐障害性を高めることができます。

以下は、インスタンスを経由する大量のトラフィックを管理するための推奨アプローチです。エンドユーザーのHTTPトラフィックはロードバランサーを経由して、分散されたフロントエンドサーバーに渡されます。この通信は、オプションで別のバックエンドロードバランサーを介してプッシュしたり、HCL ローンチサーバーに直接配信することができます。

2021/12/2 - 読み終える時間: 2 分

What's new in HCL RTist 11.1 2021.46 の翻訳版です。

HCL RTist 11.1 2021.46 の新機能

本日、HCL RTist の別のリリースを出荷しました。11.1 2021.46. いつものように、いくつかの新機能といくつかのバグフィックスがあります。その中からいくつかをご紹介します。

イベントデータの移動

2つのカプセル間で頻繁にデータを送信する場合や、データが大きい場合は、イベントデータを移動するという新しい機能を利用できます。上の図は、2つのカプセル間で頻繁に送信される文字列をコピーではなく移動するテストアプリケーションで、アプリケーションのパフォーマンスが約35%向上したことを示しています。

型の型記述子には、新しい移動関数が含まれています。定義されていれば、オブジェクトへのrvalue参照がsend-statementで提供されている場合、データ・オブジェクトが移動されます。例えば、std::moveを使ってrvalueの参照を得ることができます。

pb.e1(mc).send(); // コピーによる送信
pb.e1(std::move(mc)).send(); // 移動による送信

受信したイベントのデータをトランジション関数内で移動させることもできます。これを可能にするには、rtdataパラメータを非constとして宣言する必要があります。これを実現するには、新しいトランジションプロパティ Const rtdata parameter のマークを外します。

そして、イベントデータを、例えばカプセル属性に移動させることができます。

m = std::move(*rtdata);

トランジションのコピー／ペースト

あるステートマシンのトランジションをコピーして、別の（または同じ）ステートマシンのステートにペーストできるようになりました。これにより、既存のステートマシンに基づいて新しいステートマシンを作成するプロセスを大幅にスピードアップすることができます。コピーしたトランジションをステートにペーストすると、最初はそのステートの自己トランジションになります。他の状態をターゲットにしたい場合は、後からステートチャート図の中でトランジションを再ルーティングすることができます。

フラグメント・ファイルの自動作成

新しい環境設定「モデリング」-「フラグメント・ファイルの自動作成」 は、新しく作成されたモデル要素をそれぞれのフラ グメント・ファイルに配置したい場合に設定できます。これは、完全に断片化されたモデルの作成を好むユーザーにとって便利です。なお、フラグメントファイルに格納されたモデル要素の名前を変更しても、フラグメントファイルの名前は自動的に変更されません。プロジェクト・エクスプローラーのコンテキスト・メニューには、フラグメント・ファイルの名前を変更するための別のコマンド Refactor - Rename file が用意されています。

コード・コンプライアンス

環境設定 「RealTime Development」-「Build/Transformations」-「C++」-「Code compliance」-「Clang-Tidy」 では、コード内に抑制コメントを生成することで、特定の sizeof 式に対する警告も処理するようになりました。生成されたコードから警告を受けないことで、Clang-Tidyを使って手書きのコードスニペットの問題点を見つけることがより現実的になります。

このリリースの新機能については、Sprint Demo YouTube Playlist のビデオをご覧ください。

2021/11/24 - 読み終える時間: ~1 分

What we mean when we talk about Day 2 DevOps の翻訳版です。

HCL が語る Day 2 DevOps とは? そして、その理由

2021年11月23日

著者: Elise Yahner / Marketing Strategy and Campaigns for HCL Software DevOps

ブログ記事、ウェビナー、eBooks、カンファレンスなどで、「Day 1 DevOpsからDay 2 DevOpsへ」という話を耳にしたことがあると思います。私たちがこの話を続けているのは、組織がDevOpsの旅で次のステップに到達するのを支援したいと心から信じているからです。Day 2 DevOpsは、単なる流行語ではなく、DevOpsの進化における次のステップです。

世界的な調査・助言会社である451 Research社（現在はS&P Global Market Intelligence社の一部）は、HCL Software社のDevOpsポートフォリオと、Day 2 DevOpsをサポートするエンド・ツー・エンドのプラットフォームを構築する当社の取り組みを評価するMarket Insight Reportを執筆しました。レポートの全文はこちらからご覧いただけますが、まず、Day 2 DevOpsとは何を意味しているのか、もう少し詳しく説明します。

451 Research社が指摘しているように、"ソフトウェア・デリバリーは、従来のウォーターフォール・アプローチからアジャイルへ、そしてDevOps（継続的なあらゆることと自動化）へと移行し、さらに次世代のAIとデータに基づくバリュー・ストリーム・マネジメント（DevOpsパイプラインの改善）、自動化されたガバナンスとビジネス・アジリティへと移行しています。" この継続的なあらゆるものと次世代のビジネスアジリティの間の橋渡しこそが、HCL Software DevOpsが組織の旅のパートナーとして優れている点です。

DevOpsの旅の最初のステージ（Day 1 DevOps）は、継続的なデリバリー・パイプラインを確立することです。この段階の組織は、「我々はいくつかのDevOpsを行っている」と言い、SDLC全体で自動化のポケットがあるかもしれませんが、パイプラインを最高の状態に最適化していません。DevOpsの次の段階（Day2）では、組織が継続的なプラクティスを企業全体に拡大し、バリューストリームを最適化することで、ガバナンスを左にシフトし、ワークフローを可視化し、複数のツール間でデータを調整します。この変革は、単にDevOpsを行うためのDevOpsではなく、市場の要求に迅速に対応し、競争で優位に立ち、社内の結束力を高めるための実行の合理化を意味します。

Day 1からDay 2に移行するには？既存のパイプラインの上に乗せる、しっかりとしたバリューストリーム管理ツールが重要です。例えば、HCL Accelerateは、バラバラになっているツールからデータを集約するように作られているので、重要な洞察を素早く得てボトルネックを検出することができます。また、テストの自動化、セキュリティスキャン、デプロイメントの自動化も方程式の一部です。ツール以外では、バリューストリーム最適化のアプローチをとり、すべてのチームを同じビジネス目標に向けて調整するための文化的な変化が必要です。

451 Research社の調査回答者の半数以上が、今日、IT組織全体でDevOpsを使用していると回答していることから、競争力を維持するためにソフトウェアをリリースする組織にとって、DevOpsの進化が必要であることは明らかです。451 Research社のMarket Insight Report では、HCL Software DevOpsがDay 2 DevOpsへの道のりをどのようにサポートするかについて、彼らの見解を確認することができます。

2021/11/18 - 読み終える時間: 2 分

Working with VersionVault Express outside the browser の翻訳版です。

ブラウザー以外での HCL VersionVault Express の操作

2021年11月17日

著者: John Kohl / Software Engineer

VersionVault Expressの主要なUIは、ブラウザベースのアプリケーションです。 単一のファイルの編集や保存、ファイルの比較や変更セットの確認、リベースやストリーム間の配信などの簡単なケースをサポートしています。 しかし、一度に複数のファイルを作業する必要がある場合はどうでしょうか？ あるいは、コードをテストするためにコンパイルする必要がありますか？ あるいは、自分の変更が他の開発者の同じ要素への変更と衝突してしまったら？ このような場合には、デスクトップ・クライアント・ツールを使用し、それらをVersionVault Expressサーバに接続することになります。

クライアント・ツールをセットアップしたら（詳しくは後述します）、コードのコピーをストリームから自分のコンピュータに取り込むには、スナップショットのダウンロードとビューの読み込みという2つの方法があります。

スナップショットのダウンロード

ストリームのスナップショットをダウンロードする方法は簡単です。ブラウザのインターフェースでストリームを表示しているときに、ダウンロード・スナップショット・アイコン（）をクリックするだけです。 これにより、ストリームの現在のバージョンを含むzipファイルが生成され、ダウンロードされます。

ストリームの読み取り専用コピーが必要な場合（変更内容をストリームに同期させる必要がなく、新しいスナップショットをダウンロードするたびにローカルコピー全体を置き換えても構わない場合）、これは現在の状態のコピーを取得するためのシンプルで迅速な方法です。 これは、ビルドやテストスイートを実行するのに適しているかもしれません。 しかし、もしあなたが変更を追跡し、プロジェクトのVOBにそれらをチェックバックする必要があるならば、VersionVault Expressクライアントによって管理されるビューが必要でしょう。

クライアントビューとサーバービュー

ビューは、VersionVault Expressプロジェクト内のストリームのコンテンツを表示するために使用されます。 各ビューは、ストリームのチェックインされたコンテンツと、バージョンコントロール下にないあなたが作成したファイルへのOSファイルシステムのアクセスを提供します。 ブラウザー・インターフェースやREST APIを介してストリームにアクセスすると、VersionVault Expressサーバー内で管理されるビューがあります。 しかし、そのビューはお客様のクライアントからは直接アクセスできません。

お客様のクライアントでのビューの作成

クライアント上で使用するビューを作成するには、VersionVault Expressクライアントをインストールする必要があります。 ブラウザのインターフェイスの右上にあるリンク（）をたどると、手順とインストール・パッケージが表示されます。 IDEとしてEclipseを使用している場合は、クライアントと一緒にインストールされるEclipseのアップデート・サイトからVersionVault Explorerプラグインを使用して拡張することができます（下記リンク先のドキュメントを参照）。

クライアントをインストールしたら、ブラウザのストリーム詳細ページ（）にある「open in VersionVault Explorer」のリンクをクリックして、クライアントのGUIを開き、同じストリームに新しいビューを作成（または既存のビューを再オープン）することができます。

VersionVault Explorerのクライアントを使用して、ストリーム上に自動ビューまたはWebビューを作成すると、サーバーで管理されているビューとは独立したビューが得られます。 クライアントのビューを作成した後は、VersionVault Explorerの "Refresh->Update from repository... "アクションや、'rcleartool update'コマンドライン・アクションによって、明示的にビューを更新した場合にのみ、他のビュー/ユーザからの変更が表示されます。 ビューを更新すると、ストリーム内の他のビューによって行われたチェックインされた変更に加えて、完了した配信やリベース操作によってストリームに追加された変更もピックアップされます。

クライアントでは、VersionVault Explorerやrcleartoolを使ってバージョンをチェックアウトし、お気に入りの編集ツールを使ってファイルに変更を加えることができます。 変更内容に満足したら、チェックインして、他のビューやストリームにアクセスする他のユーザーに見えるようにします。 ストリームビューのページで更新アイコンをクリックすると、ブラウザUIの基礎となるビューにチェックインされた変更が表示されます。 ストリーム上の他の自動ビューやウェブビューは、新しくチェックされた変更を表示するために更新が必要です。

変更内容をチームで共有する準備ができたら、配信操作を使って別のストリームにマージします。

配信とリベース

VersionVault Expressでは、ストリーム間での変更の移動にdeliverおよびrebaseオペレーションを使用します。 単純な変更であれば、ブラウザのUIで操作を行うことができます。 しかし、ブラウザUIはソース・ストリームとターゲット・ストリームに相反する変更を含むdeliverおよびrebaseのケースを扱うことができません。 2人の開発者がテキストファイルの同じセクションを変更した場合など、相反する変更がある場合は、クライアント上でビューを使用して、VersionVault Explorerやrcleartoolで配信やリベースの処理を行う必要があります。 (まだ両方のストリームにビューを持っていない場合は、操作を開始する前に作成することができます)。

VersionVault Explorerでは、Deliver->Defaultメニュー項目、またはツールバーのボタン( )から「Default Deliver」を使用してDeliverを行います。 リベースには、Rebase->Defaultメニュー項目、またはツールバーのボタン（ ）から「Default Rebase」を使用します。 VersionVault Explorerは、マージ・コンフリクトを解決するためのプロンプトを表示し、その後、操作を完了する前にビューで結果をテストすることができます（ターゲット・ストリームへの変更をチェックします）。

リベースや配信の後、ターゲット・ストリーム上の他のビューを更新することを忘れないでください。

まとめ

ここでは、VersionVaultクライアントを使用してVersionVault Expressサーバーを操作し、クライアント上で自動ビューまたはWebビューを作成し、維持する方法を学習しました。 また、VersionVault Expressプロジェクトの同じストリームにアクセスしている複数のビューで変更を可視化する方法や、クライアント上で複雑なリベースや配信操作を処理する方法についても学びました。

詳細はブログ・サイト をご覧ください。

2021/11/18 - 読み終える時間: 7 分

Webhook basics の翻訳版です。

Webhook の基礎知識

2021年11月17日

著者: Mark Zukowsky / Senior Software Architect

はじめに

VersionVault Expressは、プロジェクト内で興味深いイベントが発生した際に、通知を送信するように設定することができます。これらの通知はWebhookと呼ばれます。Webhookは単純に、HTTPでPOSTリクエストとしてエンドポイントに送られるJSONペイロードです。HTTPのPOSTリクエストに応答できるシステムであれば、Webhookのエンドポイントとなり、任意のアクションを実行できます。この記事では、webhookに関連する基本的な情報を見ていきます。webhook定義の作成と更新には、プロジェクト内でビルダーの役割を持つユーザーが必要です。ロールについては、VersionVault Expressブログの「プロジェクト・チーム・メンバーのロール」を参照してください。

プロジェクトとストリームのWebhookの比較

VersionVault Expressでは、ユーザーはプロジェクトまたはプロジェクト内の個々のストリームのいずれかのコンテキストでWebhookを作成することができます。Webhookのトリガーの実装はすべてのWebhookで同じであり、プロジェクトとストリームのWebhookの違いは、どの基本的なイベントがWebhookのトリガーを引き起こすかということです。プロジェクトWebhookの作成は、プロジェクト設定ページのWebhookページで行い、ストリームWebhookの作成は、プライマリ・ストリーム・ページのWebhookページ（ストリームごとに移動）で行います。プロジェクトとストリームのどちらのWebhookを作成する場合でも、最初のWebhookを作成することができます。

Webhook定義画面

Webhookの作成画面は、選択できるイベントを除き、プロジェクトとストリームのWebhookで同じです。

webhookの作成画面は上記の通りです。右上のアクティブ・スライダーは、Webhookがトリガーするかどうかを示しています。webhookの定義を削除せずに、webhookのトリガーを止めたい場合があります。デフォルトでは、Webhookはトリガーします。

Webhook name (Webhook名)

Webhook nameは、Webhookの識別子です。

ペイロードURL

ペイロードURLは、リクエストに応答するエンドポイントの定義です。ペイロードURLは、JSONボディを持つHTTPリクエストを受け取り、ペイロードに基づいて必要なアクションを実行します。

シークレット

シークレットは、ペイロードの内容に基づいたハッシュをWebhookのHTTPヘッダに追加します。

ストリーム Webhook 用のイベントタイプ

Webhookのペイロード

各Webhookには、Webhookのトリガーとなったイベントに役立つさまざまな情報が含まれています。ペイロードの完全な情報については、ブログページ を参照してください。

SSL検証の無効化

デフォルトでは、サーバー証明書は利用可能な認証局に対してチェックされます。このオプションを選択すると、必要に応じて検証がバイパスされます。

Webhookの起動

Webhookが起動すると、HTTPリクエストがエンドポイントに送信されます。 ヘッダーのContent-Typeはapplication/jsonを示します。リクエストのボディはペイロードのJSON表現で、ペイロードの内容が含まれています。ペイロードのサンプルを以下に示します。すべてのWebhookのペイロードに共通するフィールドが含まれています。

Webhookの作成時にシークレットが指定されていた場合は、ペイロードとシークレットのハッシュ値を含む以下のような追加ヘッダーがHTTPリクエストに追加されます。

X-VV-Signature : sha256=866c3800b398bd8c97a575268b2dea7b6adc329a3052ffec140572ed86e61b1f

この署名は、秘密を知っているエンドポイントが再現することで、ペイロードが変更されていないことを確認できます。エンドポイントの設定方法については、VersionVault のブログサイトをご参照ください。

HTTPリクエストを送信すると、sendは指定されたエンドポイントとの接続が確立するまで最大60秒、接続が確立するとエンドポイントからの応答を受信するまで最大20秒待機します。エンドポイントがリクエストに対して意味のある形で応答することが重要です。サーバーは、エンドポイントからの応答に基づいて、以下のように行動します。

• エンドポイントが有効なレスポンスを返信した場合、ヘッダー、ボディ、レスポンスコード、レスポンステキストが取得され、Webhookの配信レコードとして保存されます。この配信記録を取得することで、Webhook配信のステータスを確認できます。

• エンドポイントから返信がない場合や、400シリーズのHTTPコードで返信された場合は、Webhookが再試行されます。この場合、配信記録は失敗の状態で更新され、60秒後に新しいリクエストが再送されます。この再試行サイクルは3回（合計3分）繰り返されます。すべての再試行でWebhookの送信に失敗し、受理されたステータスを受信した場合、このインスタンスのWebhookのトリガーについては、それ以上の再試行は行われません。失敗した試行のステータス情報は、webhookの情報画面から取得できます。

• 決して受信しないエンドポイントが設定されている場合：Webhookのペイロードは4回送信されます。

Webhookの配信記録

各Webhookは、配信試行のステータスの記録を保持します。VersionVault ExpressのUIでこれらの記録を確認すると、エンドポイントへの到達に問題がある場合や、エンドポイントに問題がある場合、あるいはまれに成功した場合などがあります。

まとめ

Webhookは、VersionVault ExpressまたはVersionVault Explorerデスクトップ・クライアントによって開始されたかどうかに関わらず、VersionVaultで発生したさまざまなイベントに基づいてアクションを起こすための強力な方法です。ペイロードを受信して処理するエンドポイントを適切に開発すれば、統合の可能性は無限に広がります。

2021/11/18 - 読み終える時間: ~1 分

Here’s what Secure DevOps looks like in action の翻訳版です。

Secure DevOps の実際の姿をご紹介

2021年11月18日

著者: Elise Yahner / Elise works on marketing strategy and campaigns for HCL Software DevOps.

Secure DevOps、DevSecOps、SecDevOps。これらはすべてソフトウェア開発でよく使われる用語ですが、本質的には同じことを意味しています。つまり、セキュリティは開発業務に不可欠であり、セキュリティをより左にシフトすることができれば、組織はコストと品質の面で有利になるということです。

SDLCの早い段階でセキュリティを追加するのは大変なことのように思えますが、適切なツールと戦略を導入すれば、シームレスに調整することができます。さらに、ガバナンスとリソース管理の改善によるメリットは、セキュアなDevOpsアプローチを取る努力をはるかに上回るものです。

セキュアなDevOpsパイプラインがどのようなものかを具体的に示すために、以下のデモを作成しました。このデモでは、当社の自動テスト、バリュー・ストリーム・マネジメント、継続的デリバリ、およびセキュリティ・スキャンの各ソリューションが、ビジネス・アジリティの問題を解決するためにどのように連携しているかをご覧いただけます。セキュアなDevOpsパイプラインがどのようなものかを具体的に示すために、以下のデモを作成しました。このデモでは、当社の自動テスト、バリュー・ストリーム・マネジメント、継続的デリバリ、およびセキュリティ・スキャン の各ソリューションが、ビジネス・アジリティの問題を解決するためにどのように連携しているかをご覧いただけます。

より詳細なデモをご希望ですか？ swinfo@hcljapan.co.jp までメールでお問い合わせください。

2021/11/15 - 読み終える時間: 2 分

Using web hooks to integrate HCL VersionVault Express and HCL Compass の翻訳版です。

HCL VersionVault Express と HCL Compassを統合するための Webhook (ウェブフック) の使用

2021年11月12日

著者: Brett Markowitz / Software Developer

HCL Software が DevOps 分野で提供する最新の製品 HCL VersionVault Express は、Web UI や REST API などを一新して最近発売されました。VersionVault Expressは、VersionVault の基盤をベースにしており、HCLのセキュアなバージョン・コントロールと構成管理ソフトウェアに関するすべての情報を提供するとともに、簡単に立ち上げることができます。

HCL Compass 2.0 は昨年、同様に外観と機能を一新して発売され、その新しいREST APIとWebhook 機能により、VersionVault Express の完璧なコンパニオンとなっています。

その好例が、オープンソースのサンプル統合です。Node-Redで構築され、VersionVault ExpressとCompassを接続する2つのWebhookレシーバーを素早く作成することができました。

この統合に必要なCompass用Webhooksパッケージのインストール方法については、[]をご覧ください。

CompassでFeature、Task、Storyが作成されてユーザーに割り当てられると、VersionVault Expressのそのユーザーのストリームに対応するアクティビティが作成されるというシンプルな統合です。

そして、そのアクティビティがプロジェクトの統合ストリームに配信されると、Compassのレコードが更新され、追加、変更、削除されたファイルのリストがノートとして表示されます。

統合を含むフローを表示するには、GitHubリポジトリから「flowers.json」ファイルを取得し、Node-RedのWebインターフェイスを開きます（Node-Redがデプロイされている場所であれば、例えばhttps://localhost:1880）。

画面右上のハンバーガーメニューから「インポート」→「クリップボード」を選択し、ファイルをブラウズして開きます。

Compass/VVE Integration」という名前のフローがあるはずで、ここですべてが行われます。

SF_Constantsサブフローでは、統合の設定を行います。

ここには "Set Flow Constants "ノードがあり、VersionVault ExpressとCompassのインスタンスに関連する様々なプロパティを設定することができます。これらは非常に簡単なものですが、それぞれの詳細についてはGitHubリポジトリのREADMEをご覧ください。

フローをデプロイして、定数が設定され、Webhookエンドポイントがペイロードをリッスンしていることを確認してください。

次に、2つの「HTTP in」ノードがあることに注目してください。1つは「[POST] /compass」、もう1つは「[POST] /vve」と表示されており、それぞれが表示されている製品からのWebhookペイロードを処理します。

Compassからペイロードが送られてくると、フローはいくつかのことを順に行います。

• VersionVault Expressで認証します。
• レコードが割り当てられたユーザー名と、レコードが追加されたソリューション名を取り出します。
• ソリューション名を使用して、VersionVault Express内のプロジェクトを検索します。
• プロジェクト名とユーザ名から開発ストリームを取得します。
• CompassのレコードIDを名前にして、そのストリームにアクティビティを作成します。

アクティビティを配信すると、VersionVault ExpressのWebhookレシーバーにペイロードが送信され、以下のシーケンスが開始されます。

• CompassとVersionVault Expressで認証します。
• 配信された各アクティビティについて。
  • チェンジセットを取得し、どのファイルが追加、変更、削除されたかを確認します。
  • アクティビティの名前を使って、関連するCompassレコードを修正し、ファイル情報をメモとして追加する。

重要なのは、このサンプルを意図的にシンプルにしたことです。そのために、いくつかの仮定を組み込んでいます。

• VersionVault ExpressとCompassの両方にユーザーが存在し、そのユーザー名は両方で同じであること。
• ユーザーは、1つのプロジェクト内に1つの開発ストリーム（<プロジェクト名>_<ユーザー名>という名前のフォーマット）しか持たず、アクティビティが作成されるのはそのプロジェクトであること。
• VersionVault Expressのプロジェクトは、Compassで使用されているソリューションと一致する必要があります。

VersionVault ExpressとCompassの最新リリースでは、様々なWebhookイベントが利用できるため、単純な通知受信や複数製品間の複雑な統合など、機能拡張が容易に行えます。