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イベントが利用できるため、単純な通知受信や複数製品間の複雑な統合など、機能拡張が容易に行えます。

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

Making and recommending baselines in HCL VersionVault Express の翻訳版です。

HCL VersionVault Express でのベースラインの作成と推奨

2021年11月12日

著者: Margaret Marynowski / HCL Software

この記事では、HCL VersionVault Expressを使用して、Unified Change Managementのベースラインを作成し、推奨する方法を説明します。これらの操作を行うには、VersionVault ExpressのBuilderロールが必要です。(VersionVault Express のロールの詳細については、HCL VersionVault Express におけるプロジェクト・チーム・メンバーの役割 を参照してください)。

UCM ベースラインの基本

ベースラインは、プロジェクト内の各ディレクトリやファイルのバージョンを指定し、任意の時点でのプロジェク トのスナップショットを表します。通常、ビルダーは、ビルドやテストが成功した後など、コードベースが良好な状態にあることがわかっているときにベースラインを作成する責任があります。ベースラインには、プロジェクト内のすべてのディレクトリとファイルを明示的にマークするフルベースラインと、前回のベースライン作成後に変更されたディレクトリやファイルのバージョンのみをマークするインクリメンタルベースラインの2種類が用意されています。インクリメンタル ベースラインを作成する方が速い場合もありますが、開発者はフル ベースラインからアクティビティのチェンジセットを確認する方がパフォーマンスが高い場合もあります。

ベースラインの作成

ストリームにベースラインを作成するには、ビルダーとしてそのストリームのページに行き、「新規ベースライン」ボタンをクリックします。新しいベースラインの名前を入力する必要があり、オプションで説明を入力することもできます。その後、「Incremental」または「Full」を選択し、「Create」をクリックします。

ベースラインの推奨

ベースラインを作成したら、それを推奨することができます。ストリームの推奨ベースラインは、既存の子ストリームのリベース処理のデフォルト選択となり、新しい子ストリームの基礎ベースラインにもなります。基本ベースラインは、ストリームのプロジェクトの現在の既知の状態を表します。新しい子ストリームは、その親ストリームの推奨ベースラインを基礎とします。ストリームをリベースすると、そのベースラインはリベースの際に使用されたベースラインに設定されます。(詳細は、「VVコンセプトの紹介ブログ」を参照してください。)

ベースラインを推奨するには、ビルダーとしてストリームのページにアクセスし、推奨したいベースライン名の左にある下向き矢印（↓*）をクリックします。

まとめ

VersionVault Expressのmake baselineおよびrecommend baseline操作により、開発者はプロジェクトの共通のスナップショットを作業の出発点として使用することができます。詳しくは、ブログサイトをご覧ください。

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

An overview of activities の翻訳版です。

アクティビティの概要

2021年11月12日

著者: Edward dunlop / Edward is a software engineer at HCL Software who played a key role in developing the HCL Compass and HCL VersionVault Express UI’s.

l

HCL VersionVault Express の最新リリースでは、UCM（Unified Change Management）プロジェクトの開始がこれまで以上に簡単になりました。UCMプロジェクトの開発ライフサイクルにおいて、開発者はストーリーの実装や不具合の修正などのタスクを完了させる必要があります。アクティビティは、タスクが完了するまでの進捗状況を追跡します。タスクのためのアクティビティを作成し、そのアクティビティをストリームに設定するだけで、ストリームに加えられた変更はすべてそのアクティビティによって追跡されます。

バージョンコントロール下のファイルに変更を加える前に、アクティビティを設定する必要があります。アクティビティは、各ストリームのページの右上にある「新規アクティビティ」ボタンで作成できます。アクティビティが作成されると、ボタンの横にあるドロップダウンを使って設定できます。折りたたまれたドロップダウンには、現在のアクティビティのタイトルが常に表示されるので、開発者はどのアクティビティを変更しているのかを常に把握できます。

アクティビティを設定した後、開発者はストリーム内のファイルやフォルダの変更を開始できます。開発者が別のタスクに焦点を移したい場合は、何をしていても簡単に新しいアクティビティを作成または設定できます。バージョンコントロールにチェックインされたすべての変更は、設定されたアクティビティによって追跡され、そのアクティビティのチェンジセットに表示されます。

ストリームのページでアクティビティタブに切り替えると、開発者は各アクティビティの下で行われたすべての変更を確認できます。アクティビティの[Review]ボタンをクリックすると、そのアクティビティが設定されている間に変更されたすべてのファイルやフォルダが表示されます。リスト内の項目を展開すると、その項目の現在の状態と、アクティビティが作成されたときの状態（チェンジセットプリデレクタとも呼ばれる）が比較されます。開発者がコードを配信する際には、各アクティビティで変更された内容を正確に確認し、どのアクティビティを配信するかを選択できます。

開発者がある要素の特定のバージョンを確認したい場合は、アクティビティ リストのアクティビティをクリックします。アクティビティが展開され、開発者はそのアクティビティのチェンジセットを見られます。チェンジセットの各エントリは、選択したアクティビティで変更されたファイルやフォルダの異なるバージョンを表します。開発者は、チェンジセット内のファイルをクリックすると、そのバージョンのファイルを見られます。また、ファイルの任意のバージョンを、その直前のバージョンやチェンジセットの前のバージョンと比較できます。これは、開発者がレビューしたいアイテムの[Compare With]ドロップダウンを使用して行えます。

アクティビティ] タブでは、設定されたアクティビティが常に他のアクティビティの上に表示されます。アクティビティの設定や削除も、ここから行うことができます。

詳細はこちらのドキュメントをご覧ください。

2021/11/10 - 読み終える時間: 3 分

Writing a generic type descriptor with HCL RTist の翻訳版です。

HCL RTistによる汎用型記述子の記述

2021年11月9日

著者: Mattias Mohlin / Senior Solutions Architect for HCL Software

型記述子は、クラス、typedef、型の別名など、モデル内のユーザー定義の型に関するメタデータを提供します。TargetRTSは、型記述子の情報を使って、その型のオブジェクトをどのように初期化、コピー、エンコードするかなどを知ります。多くの場合、モデルコンパイラは型に対して自動的に型記述子を生成しますが、場合によっては手動で型記述子を書く必要があります。型記述子に慣れていない方は、この記事を読んでから先に進むことをお勧めします。

ここでは、型がジェネリックである場合、つまり、1つまたは複数のテンプレートパラメータを持つ場合について見てみましょう。以前は，テンプレート型の具体的なインスタンスごとにtypedefやtype aliasを作成し，そのテンプレートのインスタンスに合わせて型記述子を記述する必要がありました．これは明らかに面倒で、しばしばコードの重複を招きました。RTist 11.1 2021.24からは、型と同じテンプレートパラメータを使用するジェネリックな型記述子を書くことができるようになりました。これにより、多くの時間を節約し、コードの重複を避けることができます。

例として，異なる種類の要素を持つベクトルを2つのカプセル間で送信する場合を考えてみましょう．まず最初に，std::vectorの型のエイリアスを定義し，vector型の型テンプレートパラメータを追加します．この場合、テンプレートパラメータを持つ型が必要なので、typedefは使えません。

次に、tを書きます。 target = new (target) std::vector<T>();

Copy 関数 target = new(target) std::vector<T>(*source);

Destroy 関数 target->~StdVector<T>();

今回の例では、これら3つの型記述子関数があれば十分ですが、汎用的なエンコードの実装方法を示すために、Encode関数も実装してみましょう。

const RTObject_class *elementTypeDescriptor = RTObject_class::fromType<T>();
if (!elementTypeDescriptor)
return 0; // Element type descriptor not available
int sum = 0;
bool first = true;
sum += coding->write_string(type->name());
sum += coding->write_string("{");
for (auto i = source->begin(); i != source->end(); i++) {
if (!first)
sum += coding->write_string(",");
first = false;
sum += elementTypeDescriptor->encode(&*i, coding);
}
sum += coding->write_string("}");
return sum;

この実装では、TargetRTSの新しいテンプレート関数であるRTObject_class::fromType()を使用して、ベクター要素の型の型記述子を取得します。その型記述子は、各ベクトル要素のエンコードに使用されます。

TargetRTSでは、すべての組み込みC++型に対してRTObject_class::fromType()のテンプレート特殊化を提供していますが、StdVectorを他の型でも使用したい場合には、同様の特殊化を記述する必要があります。例については、TargetRTS ファイルの RTObject_class.h を参照してください。

Decode関数は、解析を必要とするため、通常、型記述子関数の中で最も実装が難しい関数です。この関数を実装することは、このニュースレターの範囲外です。しかし、モデルコンパイラが型記述子を生成しないため、完全に空けることはできません。

デコード関数

// NOT IMPLEMENTED

return 1;

最後に、StdVector用のコードスニペットを2つ用意しておきます。

Header Preface #include <vector>

これにより、StdVector型を使用する際に、基礎となるstd::vector型が利用できるようになります。

Header Ending

template <> const char* RTName_StdVector<int>::name = "StdVector<int>";
template <> const char* RTName_StdVector<char>::name = "StdVector<char>";

これらのテンプレートの特殊化は厳密には必要ではありませんが、デバッグの際に役立ちます。デフォルトでは、型記述子の名前はモデル型の名前（この例ではStdVector）に設定され、その名前は型記述子のすべてのインスタンスで同じになります。使用するテンプレートのインスタンスに対して特殊化を行うことで，より具体的な名前を得ることができます．

なお，すべてのコンパイラが，このような特殊化をヘッダファイルに記述できるわけではありません。

それでは、StdVector型記述子をテストしてみましょう。2つのカプセルを持つサンプルモデルを作成し、1つ目のカプセルから2つ目のカプセルにintのベクターを送信し、2つ目のカプセルから1つ目のカプセルにcharsのベクターを送信します。自分でモデルを作りたくない場合は、添付のモデルを使うことができます。そのモデルを構築して実行すると、このような出力が出力されます。

Reached Cap2 State 1
Reached Cap1 State1 and sending Integer
Success: Received sendInteger event with data at Cap2.
Received: StdVector<int>{1,2,3}
Reached Cap2 State2 and sending Chars
Success: Received sendChar event with data at Cap1.
Received: StdVector<char>{'a','b','c'}
Reached Cap1 State2 and received Chars

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

Project Team Member Roles in VersionVault Express の翻訳版です。

HCL VersionVault Express におけるプロジェクト・チーム・メンバーの役割

2021年10月25日

著者: Michael Hudson / Director for the HCL Software DevOps Products

この記事では、VersionVault Express で管理されているプロジェクトにおいて、チーム・メンバーが担うことのできる様々な役割について説明します。VersionVault Express のインスタンスはいくつかのプロジェクトを管理することがあり、お客様は複数のプロジェクト・チームに所属することがあります。それらの異なるチームにおいて、あなたが果たす役割は様々です。

VersionVault Express インスタンス上の任意のプロジェクトに参加した人は、"My projects "エリアにアクセスすることができます。これは通常、ログインした際に最初に表示される画面で、ナビゲーション・バーのホーム・アイコンをクリックすることでいつでも移動することができます。

あなたが参加したプロジェクトは、「マイプロジェクト」のページにタイルとして表示されますが、プロジェクトの作成を促すボタンも表示されます。新しいプロジェクトを作成すると、そのプロジェクトの「プロジェクトオーナー」の役割が自動的に与えられます。

プロジェクトオーナー

プロジェクトオーナー」は、プロジェクト自体の管理と、プロジェクトチームのメンバーの管理を行います。プロジェクトの管理は簡単です。プロジェクトを作成し、稼働させた後に残る作業は、プロジェクトの削除とアーカイブ化だけです。

ユーザーは、プロジェクトに参加するよう招待することも、単にプロジェクトに追加することもできます。ユーザーがすでに存在する場合は、プロジェクトオーナーが名前の一部を入力して、正しいユーザーを選択するだけで追加できます。ユーザーがまだ存在しておらず、VersionVault Express インスタンスがSMTPメール・サーバーを使用するように設定されている場合は、プロジェクト・オーナーがユーザーの電子メールアドレスを入力して、プロジェクトへの招待状を送信することができます。SMTPが設定されていない場合は、プロジェクト・オーナーはVersionVault Express のシステム管理者に連絡してユーザーを作成する必要があります。

いずれの場合も、プロジェクト・オーナーは新しいプロジェクト・チーム・メンバーの役割を選択する必要があります。プロジェクトオーナーは、1つまたは複数のロールを選択し、新しいユーザーに割り当てることができます。プロジェクトオーナーは、いつでもチームメンバーのロールを更新することができるので、チームメンバーが型にはまる心配はありません。

プロジェクトオーナーは、他のチームメンバーにプロジェクトオーナーのロールを割り当てるだけで、その人を共同オーナーにすることができます。プロジェクトオーナーの中には、コーディングやビルドが好きな人とそうでない人がいます。もしあなたがプロジェクトオーナーで、他のチームメンバーができることもやりたい場合は、プロジェクトオーナーの役割に加えて、あなた自身に別の役割を割り当てるだけです。

開発者

ほとんどのプロジェクトチームメンバーは「開発者」の役割を持っています。開発者は、コードを書いて納品する責任があります。

開発者はストリームで仕事をします。1つのプロジェクトには多くのストリームが存在し、おそらくそうなるでしょう。開発者」ロールを持つチームメンバーは、「View all streams」画面に移動することで、これらのストリームを見ることができます。開発者はどのストリームでも作業でき、他のストリームの子ストリームを作成することもできます。最も重要な2つのストリームは、自分が作業しているストリーム（「開発」ストリーム）と、自分が配信するストリーム（「統合」または「機能」ストリーム）です。

開発者がストリームを開くと、最初に目にするのは自分のコードです。プロジェクトのルートにREADMEがある場合は、要素（ファイルやディレクトリ）のリストの下に表示されます。別のディレクトリに変更しても、同じルールが適用されます。開発者は、コードの追加、コードの表示、コードのダウンロード、コードの編集、変更のチェックインやローカルへの保存ができます。ストリームに "Request build" webhook が含まれている場合、開発者は必要に応じてビルドをトリガーすることができます。

VersionVault Express インスタンスのすべてのユーザーは、クライアントをダウンロードしてインストールすることができます（すべての画面の右上にリンクがあります）が、開発者のみがストリーム内でクリックするだけでクライアントを開くことができます。

開発者が何らかの作業をするときは、必ずアクティビティのコンテキストの中で行わなければなりません。アクティビティとは、ストーリー、タスク、バグ、その他の作業単位を表します。開発者は自由にアクティビティを作成し、作業中のストリームに設定したり解除したりすることができます。また、アクティビティを一覧表示したり、変更セットを見て、どの要素（ファイルやディレクトリ）が変更されたか、どのような変更が行われたかを追跡することもできます。準備ができたら、開発者は特定のアクティビティのコードを親（統合または機能）のストリームに配信することができます。

開発者にはベースラインを作成したり推奨したりする権限はありませんが、どのストリームでもベースラインを見ることができます。これは、あるストリームを特定のベースラインにリベースする（つまり、そのベースラインに含まれるコードの特定のバージョンを取得する）ことを選択する際に不可欠です。

ビルダー

ビルダーは、CI/CDパイプラインの構築と実行を担当します。これには、コードをビルドし、テストし、公開するという最終的な目標に向けて、ソース・コントロール・システムを含むすべてのシステムを接続することが含まれます。

VersionVault Express では、このために特定の "ビルダー "ロールを定義しています。つまり、これがチーム内の特定のロールなのか、あるいは開発者の一人（あるいはプロジェクト・オーナー）のための追加のロールなのかを決めることができます。

統合は、外部システムが VersionVault Express の機能を呼び出せるようにするためのREST APIや、VersionVault Expressが他のシステムの機能を呼び出せるようにするためのWebhookによって実現されます。VersionVault Express のREST APIのほとんどは、ユーザー・インターフェイスと同じ認証情報と同じ権限で保護されています。(つまり、'Project Owner'のみがプロジェクトを削除でき、'Developer'のみがファイルをチェックインできる、といった具合です）。)

アウトバウンドWebhook には、実際にはパーミッションはありません。情報を必要とするエンドポイントに情報を送信するだけです。Webhookの設定と管理はビルダーの責任です。Webhookには、プロジェクトに属するものと、プロジェクトのストリームに属するものがあります。プロジェクトのビルダー・ロールを持つチーム・メンバーは、そのプロジェクトまたはそのプロジェクト内の任意のストリームにウェブフックを作成し、管理することができます。ビルダーは、新しいWebhookの作成、既存のWebhookの設定、Webhookの配信履歴の確認、失敗したWebhookの再試行を行うことができます。

ビルダーは、VersionVault Expressにおいて、ベースラインの作成と管理というもう1つの責任を持ちます。Builderロールを持つチームメンバーは、任意のストリームにベースラインを作成し、任意のベースラインを推奨することができます。ベースラインを作成したり推奨したりする行為は、CI/CDパイプラインの下流のシステムを作動させるwebhookのトリガーとなるかもしれません。

システム管理者

VersionVault Expressにはもう一つの役割があります。プロジェクト・チームのメンバーにロールを割り当てようとしても、目にすることはありません。それは、このロールであるシステム管理者は、開発プロジェクトで働くことを想定していないからです。

システム管理者は、VersionVault Express のインスタンス自体を管理する責任があります。システム管理者は、基盤となる仮想マシン・インスタンスの設定と起動、およびVersionVault Express インスタンス自体の設定（ホスト名、ポート、SSL証明書、SSHキー、ライセンス・サーバ、タイム・ゾーン、SMTP、LDAPおよびNTPサーバの設定）を行います。

システム管理者は、仮想マシンのポート8443で動作する独自のユーザー・インターフェースとREST APIにアクセスできます。このインターフェイスのIDとパスワードは、メインのVersionVault Express APIやユーザー・インターフェイスでは使用できませんので、システム管理者が開発者（または構築者、プロジェクト・オーナー）でもある場合は、2つ目の認証情報が必要になります。

システム管理者は、基礎となる仮想マシンにSSH接続し、必要に応じて "sudo "権限を使用して、オペレーティング・システムとVersionVault Express インスタンスに対する管理タスクを実行することができます。

システム管理者は、外部のLDAPディレクトリを使用するようにVersionVault Express インスタンスを構成することができます。その場合、そのディレクトリで設定されたグループに属するすべてのユーザーは、自動的にVersionVault Express のユーザーとなりますが、プロジェクトを作成したり、プロジェクトに招待されたり、特定のプロジェクトで特定の役割を与えられたりする必要があります。

また、システム管理者は、VersionVault Express のインスタンスを独自に管理するように設定することもできます。この場合、システム管理者はユーザーを管理する責任を負います。システム管理者は、1人のユーザーを作成し、そのユーザーにプロジェクトを作成してより多くのユーザーを招待するように指示することができます。ユーザーが何らかの役割でプロジェクトに参加すると、自分のプロジェクトのオーナーになり、さらにユーザーを招待することができるようになります。一方、システム管理者は、VersionVault Express のSMTP機能を無効にして、ユーザーの追加や削除に全責任を負うことができます。おそらく、システム管理者はその両方を少しずつ行い、ユーザー管理の責任をプロジェクト・オーナーと分けていることでしょう。

まとめ

VersionVault Express のユーザーは、異なるプロジェクトで異なる役割を持つことができ、その役割を混在させることができることを学びました。ソース・コントロール・システムが持つべき他の役割は何でしょうか？コメントで教えてください。

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

User management and LDAP configuration in VersionVault Express の翻訳版です。

VersionVault Expressにおけるユーザー管理とLDAP設定

2021年11月2日

著者: Brett Markowitz / Software Developer

VersionVault Express 2.0に搭載された新しいWeb UIとREST APIにより、新しいプロジェクトの作成や、IDEを開くことなくソース・コード・ファイルのタイプミスを素早く修正するなど、多くの一般的なタスクをこれまで以上に簡単に実行することができます。

VersionVault Expressに搭載されている2つのWeb UIのうちの1つは、システム管理者がSSHキーからSMTPサーバ、SSL証明書まであらゆる設定を行うことができるアプライアンス設定UIです。

さらに重要なのは、VersionVault内でユーザーを管理することができることです。ユーザー自身が管理する場合も、既存のLDAPサーバーを利用する場合も同様です。

アプライアンスのセットアップUI（デフォルトではhttps://hostname:38443/setup）にログインすると、ユーザー管理機能が前面に表示されます。

VersionVault Expressアプライアンスは、デフォルトでは自己管理アカウントに設定されていますが、最上部のドロップダウン・メニューで簡単に「Enterprise LDAP accounts」に変更することができます。

LDAPに変更すると、既存のプロジェクトにアクセスできなくなったり、誤ったユーザーがアクセスできるようになったりする可能性があるため、可能であればプロジェクトを作成する前か、既存のプロジェクトを十分にバックアップした後に変更することをお勧めします、という警告がUIに表示されます。

続いて、ホスト名、ポート、検索ベースなど、接続するLDAPサーバーの情報を入力するフィールドがUIに表示されます。

オプションとして、グループに対してVersionVault Expressの使用を制限することができます。また、ユーザーのフルネーム、電子メールアドレス、アバター画像に対してカスタム・フィールド・マッピングを設定することで、これらの情報を既に設定されている別の名前のフィールドから引き出すことができます。

必要な設定がすべて完了したら、上部にある "Validate "ボタンで、保存や適用の前にVersionVault ExpressがLDAPサーバーと正しく通信できることを確認できます。

自己管理アカウント・オプションを使用する場合は、より詳細なユーザー管理が可能になります。

例えば、"Email "ボックスにユーザーの電子メールを入力し、右上の "Add user "をクリックすることで、VersionVault Expressに直接ユーザーを追加することができます。

SMTPサーバーが設定されている場合は、ユーザーにメールが送信され、ユーザーはそれを使って登録作業を完了することができます。

その下には、VersionVault Expressに存在するユーザーのリストが表示されます。このリストには、完全に登録されたユーザーと、招待されたものの登録プロセスが完了していないユーザーが含まれています。 その場合、そのユーザーの招待状態は「保留」となり、招待メールを再送するための丸い矢印のアイコンが表示されます。

右側には、ユーザーに対して実行可能なアクションもあります。任意のユーザに対しては、ゴミ箱のアイコンにより、そのユーザをVersionVault Expressから削除することができます。また、"Join "と表示されているユーザーに対しては、矢印付きの鍵のアイコンにより、強制的にパスワードをリセットさせることができます。ユーザーには、新しいパスワードを設定するためのリンクが記載されたメールが送信されます。

また、ユーザーリストの任意の行にカーソルを合わせると鉛筆のアイコンが表示され、クリックするとそのユーザーのメールアドレスを変更できます。

Temporarily disable SMTP "トグルは、その名の通りSMTPの機能を無効にし、VersionVault Expressが登録メールやパスワード・メールを送信しようとしないようにするもので、SMTPサーバがダウンしていたり、正常に動作していない場合に有効です。

ただし、SMTP機能が無効になっている場合は、招待状のステータスが「Pending」になっている横のボタンを押すと、コンピュータのメール・クライアントが開き、必要な内容が入力されたメールが手動で送信されます。

アプライアンスのセットアップUIには他にも多くの機能がありますので、ご興味のある方は製品ドキュメントをご覧ください。