2022/4/19 - 読み終える時間: ~1 分

Accelerating your test automation with the power of containers の翻訳版です。

HCL OneTest: コンテナの力でテスト自動化を加速する

2019年9月11日

著者: Nabeel Jaitapker / Product Marketing Lead, HCL Software

チームのコラボレーションと生産性を向上させることは、企業の品質保証への道を加速させる確実な方法です。

そして今、HCL の新しい OneTest スイートバージョン10でそれが可能になりました。この最新版は、テストを高速化し、高価なテストインフラを維持する必要性を削減し、新しいフレンドリーなユーザーエクスペリエンスを使用します。

新バージョンはまた、HCL OneTest Serverを誇ります。これは、完全に統合された、安全な設計のサーバーであり、ユーザーはOneTest製品全体からテストをまとめることが可能です。

「私たちのHCL OneTest Server は、テストデータ、テスト環境、そしてテストの実行を、テスターやテスターではない人々にとって使いやすい1つのダッシュボードにまとめます」と、HCL Product Manager for Functional and Performance Test Automation の Chris Haggan は述べています。

また、OneTest バージョン10では、以下のような新機能が追加されています。

• 新しいデータセット技術
• OneTestポートフォリオ全体におけるGITのネイティブな統合
• パフォーマンステスターのためのJMeterの統合

HCL OneTestについて

HCL OneTestは、DevOpsアプローチをサポートするソフトウェアテストツールを提供しています。APIテスト、機能テスト、UIテスト、パフォーマンステスト、サービス仮想化など、DevOpsアプローチをサポートするソフトウェアテストツールを提供します。

テストの自動化と実行をより早く、より頻繁に行うことで、エラーの早期発見、つまり修正コストの低減に貢献します。また、HCLは、DevOpsソフトウェアの使用と展開の方法を変える新しい消費モデルの下でバンドルされたサービスを提供します。

この新しいサービスは、重要なDevOps製品の導入と成長のための計画を簡素化するのに役立ちます。

2022/4/15 - 読み終える時間: ~1 分

DevOps from the human perspective の翻訳版です。

人間の視点から見た DevOps

2020年8月13日

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

DevOpsを実践する上で何が優れているかを考えるとき、あなたはおそらく技術的な才能、自動化のノウハウ、そして機能的なスキルについて考えるでしょう。しかし、共感、時間管理、コミュニケーションなどのヒューマンスキルは、最近注目されています。これらのスキルは「ソフト」スキルとして考えられることが多いですが、「ハード」スキルに劣らず価値があります。特に、リモートワーク環境で同僚と関わる際に、より繊細さが要求されるようになりました。

DevOps.comは最近、チームビルディングと仕事の燃え尽き症候群の回避を取り上げた電子書籍 DevOps: Mastering the Human Element を出版しました。この電子書籍は、パンデミックが発生する前に企画されたものですが、分散型チームの管理で直面する新たな課題を抱える現在、特に適切な内容となっています。この 2020 Upskilling: Enterprise DevOps Skills Report という電子書籍は、DevOps Instituteの2020 Upskillingからの洞察に基づき、持続可能なDevOps作業環境の構築と適切な文化の発展に関する専門家のアドバイスを提供します。

「DevOpsの人間化」というトピックは、最近のDevOps.comのパネルウェビナーで詳しく取り上げられました。HCL Software DevOpsプロダクトマネージャーのSteve Booneは、このディスカッションに参加し、リモートワークへの突然のピボットによってもたらされる独自の課題についての見識を提供しました。

「課題の1つは、多くのマネージャーやチームメンバーが、皆が何に取り組んでいるかを知っているつもりでも、実際にはよくわからないことです。「すると突然、グループとしてもっとコミュニケーションをとり、仕事の中身をよく見えるようにして、責任の所在を明確にし、指図したり、物事がうまくいっていると思い込んだりしないようにしなければならないことがわかります。誰がいつ、どこで、何をしているかを把握できるように、作業を可視化しなければならないのです」。

主なポイント

• 58%の企業が適切なDevOpsスキルを持つ人材を見つけるのに苦労しており、48%の企業がそのような人材を見つけたとしても維持するのに苦労しています。
• 組織は、進行中の作業をより効果的に管理し、チームの認識負荷を軽減する必要があります。
• 在宅勤務が一般的になりつつある中、チームはオフィスでのコミュニケーションを再現し、コラボレーションを維持するための革新的な方法を見つける必要があります。
• このような前向きな企業文化を確立し、チームの燃え尽き症候群を防ぐには、変革を推進する努力を真に支持する経営陣の存在が不可欠なのです。

「作業の見える化」は、個々の貢献者を助け、責任のなすりあいを避けるためのものですが、このレベルの透明性は、助け舟というよりも、監視役として機能するのではないかと心配する開発者もいます。しかしBoone氏は、それはまったく目標ではなく、価値の流れ管理は、悪いパフォーマンスよりも良いパフォーマンスを見出すことにあると言います。

「バリューストリームマネジメント」は、物事がうまくいっているところに目を向ける機会です。批判するのではなく、耳を傾けることです」とブーン氏は言う。「うまくいっているチームを見つけたら、それを評価し、報酬を与え、ベストプラクティスを構築し、サポートが必要なチームと共有することができるのです」。

そして何より、Boone氏は、チームマネジメントにおける共感と人間的なつながりの必要性を強調しました。

「私たちは皆、お互いにもっと共感し合うことができるはずです。小さな子供の声が聞こえるかもしれないが、それは "新しい常識"であり、人々の状況を理解しなければならない。さらに重要なことは、他の組織の仕組みを理解することです。ソフトウェアを世に送り出すには、ドキュメンテーション、マーケティング、セールス、サポートなど、さまざまな組織が必要です。ビジネス全体の仕組みや、各チームがどのように貢献しているかについての知識を広げる手助けをすることで、物事を前向きにとらえることができるのです」と Boone 氏は述べています。

DevOps.comの電子書籍のダウンロードとパネルウェビナー（録画）の視聴は、こちらをご覧ください。

2022/4/13 - 読み終える時間: 10 分

HCL Accelerate value stream management with Jira の翻訳版です。

HCL Accelerate バリューストリームマネジメントと Jira の連携

2020年7月28日

著者: Daniel Trowbridge / Technical Lead

このチュートリアルでは、Jiraとの統合を作成し、HCL Accelerate のバリューストリームまたはVSM（バリューストリームマネジメント）ビュー内で「点」（作業単位）を移動する方法を紹介します。課題追跡カードは、多くの場合、開発バリューストリームの作業が始まる場所です。さらなるチュートリアルでは、HCL Accelerateがバリューストリーム全体にわたって多くの異なるツールからデータを結合する方法を紹介します。

1. Jira のセットアップ

1.1 Jiraインスタンス

このチュートリアルでは、API トークンを使用してアクセスおよび認証できる Jira インスタンスが必要です。

この目的ですぐに利用できる Jira インスタンスがない場合、1 つのオプションとして https://www.atlassian.com のクラウド Jira インスタンスを使用することができます。Jira クラウドを使用したことがない場合は、無料トライアルにサインアップすることができます。

1.2 かんばんテンプレート(オプション)

新しい Jira クラウドインスタンスをセットアップする場合、すべてのセットアップの質問に対して「スキップ」をクリックすることができます。カンバンクラシックテンプレートは、このチュートリアルには適していますが、必須ではありません (次のセクションを参照)。

1.3 Jiraプロジェクトの作成

新しいプロジェクトを作成する場合、プロジェクトのキーがHCL Accelerateの統合で使用されることに注意してください。

1.4 Jiraボード

このチュートリアルでは、Jira ボードに以下の 5 つのカラムとステータス名があることを確認します。

• バックログ
• 開発対象
• 進行中
• レビュー中
• マージ

ボードを直接編集するか、ワークフローエディタ（設定>課題>ワークフロー）を使用し、このワークフローをボード（プロジェクト設定）に適用することができます。

1.5 カードの作成

このチュートリアルでは、少なくとも1枚のカードが必要です。カードを作成し、「バックログ」に追加してください。

2. Jiraとの統合を作成する

1. HCL Accelerate のプラグインページ（Settings>Integrations>Plugins）に移動し、Jira プラグインの「Add Integration」をクリックします。Jira Integration の追加」フォームに記入するよう促されます。

2. 統合名を入力します。チュートリアルで使用する名前は、「JKE Jira 1」です。

3. Jira のベース URL を指定します。これは Jira のインスタンスに依存します。クラウド Jira の場合は、「https://.atlassian.net」という形式になります。

4. Jira のユーザー名を入力します。これは、Jira のログインに使用される電子メール アドレスである必要があります。

5. 認証（API TokenまたはoAuth）を提供する。このチュートリアルでは、クラウド Jira の API Token を使用します。API Token は https://id.atlassian.com/manage/api-tokens で作成することができます。トークンを作成し、HCL Accelerate の「パスワード」として提供します（この場合、通常のアカウントログインパスワードは機能しません）。

6. 上記の通り、このチュートリアルではAPI Tokenを使用するため、oAuthの4つのフィールドは空欄にします。

7. 最後のフィールドは、統合のためのJiraプロジェクトを指定します。完全な名前ではなく、Jira プロジェクトの「キー」を使用します。プロジェクトを作成するときにこのキーを編集できたことを思い出してください。

8. 追加」をクリックします。統合が作成され、統合ページに表示されるはずです。統合のドロップダウンをクリックすると、詳細を見ることができます。統合のステータスと実行ログも表示されます。

注：統合のアップグレードが可能な場合（名前の横に青い点が表示される）、今すぐアップグレードすることをお勧めします。縦に3つ並んだドットの「ケバブ」メニューをクリックし、「アップグレード」を選択します。

3. バリューストリームにJira統合を追加する

3.1 新規バリューストリームの作成

1. バリューストリームページに移動し、"作成 "をクリックします。

2. バリューストリームに名前を付け、そのチームを選択します。ワークブックでは、「JKE App1」という名前と「Default Team」を使用します。バリューストリームの説明は任意です。

3.2 vsm.json ファイルを作成する

HCL Accelerateに統合が追加されたので、特定のバリューストリームに追加することも可能です。HCL Accelerateのバリューストリームは、バリューストリームマップ（VSM）jsonファイルをダウンロードしてアップロードすることで、高度な設定が可能です。VSMの設定例を以下に示します。このjsonをコピーして.jsonファイルに保存し、このファイルをアップロードしてバリューストリームを構成してください。

この json コンテンツは Jira 統合名を参照するため、アップロードする前に統合名を「JKE Jira 1」とし、「オンライン」にする必要があります（さもなければ json を適宜編集してください）。

{ 
  "tenantId": "5ade13625558f2c6688d15ce", 
  "integrations": [{ 
    "name": "JKE Jira 1"
  }], 
  "phases": [{ 
      "name": "Planning", 
      "stages": [{ 
          "name": "Backlog", 
          "query": "issue.status=Backlog"
        }, 
    { 
          "name": "Selected For Development", 
          "query": "issue.status='Selected for Development' AND pr.status!=open"
        } 
      ] 
    }, 
    { 
      "name": "Development", 
      "stages": [{ 
          "name": "In Progress", 
          "query": "pr.status=open AND issue.status!='In Review'"
        }, 
        { 
          "name": "In Review", 
          "query": "issue.status='In Review' AND pr.status!=closed"
        }, 
        { 
          "name": "Merged", 
          "query": "pr.status=closed AND build.status!=success"
        }, 
        { 
          "name": "Build", 
          "query": "build.status=success AND deployment.env!=DEV"
        } 
      ] 
    }, 
    { 
      "name": "Deployment", 
      "stages": [{ 
          "name": "DEV", 
          "query": "deployment.env=DEV AND deployment.env!=QA"
        }, 
        { 
          "name": "QA", 
          "query": "deployment.env=QA AND deployment.env!=PROD"
        }, 
        { 
          "name": "PROD", 
          "query": "deployment.env=PROD"
        } 
      ] 
    } 
  ] 
}

VSM JSONの説明

統合の配列

統合は、統合名に基づいて含まれます。このチュートリアルでは、「JKE Jira 1」という名前を使用していますが、統合の名前が異なる場合は、変更する必要があります。

"integrations":[

{

"name":"JKE Jira 1"

}

]

フェーズとステージ

バリューストリームは、フェーズとステージで構成されています。この json ファイルは、このチュートリアルのためのフェーズとステージの定義を提供します。ステージの重要な部分は、ワークアイテム（ドット）がステージに含まれるべきかどうかを論理的に定義するステージクエリです。以前、Jira のステータスを定義したことを思い出してください。例えば、Jiraステータスの「Backlog」をHCL Accelerateステージにマッピングすることができます。この設定を変更することで、異なるJiraステータスの値を異なるステージに使用することができます。

"phases":[

{

"name": "Planning",

"stages": [

{

"name": "Backlog",

"query": "issue.status=Backlog"

},    ...

4. vsm.json ファイルのアップロード

新しいバリューストリームを作成した場合、アップロードボタンが直接利用できます。

vsm.jsonファイルをアップロードした後、ツールおよびユーティリティのドロップダウン・オプション「バリューストリームマップの置き換え」を使って、後から追加アップロードでバリューストリームを修正することが可能です。

5. ドットの確認

HCL Accelerateがデータを同期するのを待ちます。Backlog に配置された Jira 課題は、バリューストリームの Backlog に表示されるようになります。

6. Jiraによるステージ変更

HCL Accelerate で Jira 統合を設定し、vsm.json ファイルを使用して統合とステージクエリを値の流れに追加すると、Jira カードが値の流れ内にドットとして表示されるようになります。課題のステータスは Jira で更新でき、ワークアイテム（ドット）は HCL Accelerate でステージを変更します。

1. Jira カードを「Backlog」から「Selected for Development」に移動します。

2. HCL Accelerate の同期に時間をかけます（通常最大1分程度）。ワークアイテムは次のステージ「Selected For Development」に移動しているはずです。

3. ドットをクリックすると、Jiraカードへのリンクやワークアイテムの履歴など、詳細が表示されます。

おさらい - 企画から開発へ、JiraからGitHubへ -

このセクションでは、バリューストリームの計画フェーズに焦点を当てました。今回は、課題追跡システムとしてJiraを使用しました。Jira ボードと課題を作成し、Jira との統合を設定し、その統合を価値の流れに追加し、価値の流れが計画段階を通してどのように Jira のステータス変更を追跡しているかを観察しました。理論的には、価値の流れのすべての段階でJiraを使用することができますが、実際にはJiraのカードには限界があります。しかし、実際にはJiraカードには限界があります。GitHubやJenkinsのような他のシステムと直接統合し、作業項目の道のりをリアルタイムで完全に自動化し、正確に可視化することができるのです。次の開発段階では、GitHub との統合を追加し、Jira と GitHub がどのように連動するかを確認する予定です。

2022/3/29 - 読み終える時間: 2 分

HCL Launch Java 8 EoS and other considerations の翻訳版です。

HCL Launch Java 8 のサポート終了とその他の検討事項

2022年3月28日

著者: Senthil Nathan / HCL Launch Product Manager

今回は、2つのホットなトピックについて解説を加えたいと思います。一つはJavaのバージョンの互換性とサポート、もう一つはHCL Launchがセキュリティフィクスパックのどのリリースストリームにあるかです。

Javaバージョンの互換性

HCL Launch 7.2.0.0の発表の中で、Java 8が2022年6月にサポート終了となることを発表しました。この変更は、異なる HCL Launch 7.x バージョンをご利用のお客様にとって異なる影響を及ぼします。ここでは、この変更がお客様に与える影響と、2022年6月以降にお客様が行うべきことを説明します。

キーポイント

HCL Launch（当時はHCL UrbanCode Deployとして知られていた）バージョンは7.0.0～7.0.1.x の場合

• Java のサポートはベストエフォートで行われます。
• Java 11、17は未対応です。

重要：完全にサポートされている Java 11 を使用できるようにするには、HC Launch 7.0.2.xより大きいバージョン（できれば7.0.5.x）への移行を計画することが推奨されます。

HCL Launch 7.0.2.x - 7.2.2.x の場合

• Java 8 をお使いの場合、Java のサポート問題はベストエフォートで処理されます。
• Java 11 は完全にサポートされています。
• Java 17はサポート対象外です。

HCL Launch 7.2.3（2022年6月リリース予定）以降の場合

• Java 8 はサポート対象外
• Java 11 は完全にサポートされています。
• Java 17 は完全にサポートされる予定です。

HCL Launch は、セキュリティで保護されたプロパティの暗号化に java keystore を使用します。そのため、異なるベンダーのJREにアップグレードする場合、このキーストアを復号化できなくなります。7.2.1.0から、製品には鍵ストアを変換する機能があります。 しかし、7.2.1.0より前のバージョンを使用している場合、HCL Launchドキュメントにキーストアの変換方法について記載されています。「新しいJREは、現在のJREと同じベンダーのものである必要があります。JREのベンダーを変更したい場合は、サポートに連絡して、KeystoreConverterツールを入手してください。" ( なお、IBM Java 8 から IBM Semeru Java 11 へのアップグレードであっても、それは別ベンダーの移行に相当します)。

この場合、HCL Softwareのサポートページを使用して新しいサポートケースを開くだけで、このツールにアクセスする方法とそのドキュメントに関する情報が戻ってきます。

セキュリティ Fixpacks

HCL Launch は、サポートされるすべてのリリースのセキュリティ Fix Packを提供します。お客様は、Fix Pack がリリースされ次第、セキュリティ脆弱性のパッチを確実に適用できるよう、対応するFix Pack のストリームに移行することが推奨されます。

• 7.0.* の場合、7.0.5.x セキュリティ Fix Pack ストリームにアップデートしてください。
• 7.1.* の場合は 7.1.2.x セキュリティ Fix Pack のストリームにアップデートしてください。
• 7.2.* をお使いの場合、これは現在のストリームですので、最新バージョンのストリームにはすべてのセキュリティパッチが含まれています。

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

HCL Compass Webhooks in Action の翻訳版です。

HCL Compass Webhooks の活用法

はじめに

この記事では、HCL CompassのWebhooksについて説明します。Webhookとは、何かがトリガーされたときにアプリから送信される自動化されたデータに他なりません。この場合、HCL Compass は Webhook データを送信するアプリで、これは Payload とも呼ばれます。Webhook は Compass アプリケーションを購読し、特定の条件が満たされるまで待機し、ペイロードを送信します。ペイロードは通常、レコードデータを含む JSON で、HTTP POST リクエストとして送信され、サードパーティーアプリケーションまたはカスタムスクリプトでキャッチして、有用な処理を行えます。これはRESTAPIとは異なり、アプリケーションからCompassにリクエストを送信し、特定の情報を得たり、特定のアクションを実行したりできます。Compass Webhook レコードで定義された条件に基づいて、Compass から一定間隔でデータが送信されるのを待ちます。

このデモを行うために、まずHCL CompassインスタンスでWebhookを有効にするつもりです。これを行うために必要な手順を説明します。すべての設定が完了したら、シンプルな Python Flask アプリケーションを使用して、Compass Webhooks からの POST リクエストをリスンし、それを表示することで、その動作を証明します。

CompassでWebhooksを有効にする

HCL compassでWebhooksを有効にする方法について順を追って説明します。これらの手順のほとんどはWindowsに特有のものですが、UNIX環境でも同じように変換できます。

• Webhooksを使用するためには、HCL CompassのRESTAPIサーバーコンポーネントをインストールする必要があります。

Start -> Programs -> IBM Installation Manager -> View Installed Packages で確認できます。

ページが開いたら、以下のように表示され、RESTAPIサーバーがインストールされていることを確認します。

インストールされていない場合は、Installation Managerからインストールする必要がありますが、次のステップに進みます。

• 次のステップは、Webhooks 1.0 パッケージをスキーマリポジトリにインストールすることです。Compass Designerを起動し、スタート->プログラム->HCL Compass-> Compass Designerをクリックします。

• スキーマリポジトリに認証情報を使って接続し、スキーマ -> バージョン -> パッケージ - > パッケージを適用 をクリックします。

• Webhooks パッケージ 1.0 を選択し、適用します。

• パッケージで有効にするレコードの種類を選択します。

• パッケージが適用されたら、スキーマをチェックインし、データベースをアップグレードします。

Webhookの設定を作成する

Webhooks パッケージを使用すると、レコードに対して特定のアクションが実行されたり、レコードの状態が変化するなど、特定の条件が満たされたときに、他のシステムが Compass レコードに関する JSON ペイロードを受信できるようになります。

パッケージが正常に適用されたら、Webhooks を稼働させるために必要なレコードを作成する時間です。

Administratorアカウントでcqwebにログインし、WebhookMasterというタイプのレコードを追加します。WebhookConfig レコードの作成を許可するグループを追加します (これは必須ではありません)。このグループのユーザーは WebhookConfig を作成できます。また、コールバックURLを指定する必要がありますが、これはCompass Rest APIのURL以外の何物でもありません。私たちはそれをマシン上にローカルに置いているので、localhostという名前になっています。基本的に、Compassはサードパーティーのアプリケーションにデータを送信し、メッセージが配信されているかどうかを確認するために待機しています。そのため、コールバックURLにはその応答が期待されます。

次のステップは、WebhookConfigレコードの作成です。

ここでは、Webhookを起動するための有効なレコードの条件や、サードパーティーアプリケーションへのURLなど、Webhookのパラメータを定義する場所です。以下のスクリーンショットのように、DefectはWebhookを有効にする必要があるレコードタイプなので、compassdefectという名前を入力しました。ここでは任意の名前を付けられます。次のフィールドは URL で、サードパーティーアプリケーションが Compass Webhooks からの POST リクエストをリッスンするための URL です。 この例では、compassdefect ルートをリッスンするシンプルな Python Flask アプリケーションです。アプリケーションはCompassと同じシステムで動作しているので、127.0.0.1がループバックアドレスです。あなたの場合、これは別のIPまたはホスト名かもしれません。オプションで SECRET フィールドがありますが、これは Webhook データを保護するために使用されます。本番環境では有効にしておくことを強くお勧めします。あなたが提供する秘密は、HMAC-SHA1 ハッシュ関数を使用してペイロードをハッシュ化し、ペイロードと一緒に署名ヘッダーを介して送信されるために使用されます。アプリケーションでは、ハッシュ関数に秘密を渡し、ヘッダでCompassから提供されたものと一致するかどうかを確認する必要があります。

また、DescriptionフィールドにWebhookのDescriptionを指定できます。追跡が必要なレコードタイプを指定します。この場合、これは「欠陥」です。Webhookの種類をCommitかNotificationから選択します。Commit はコントロールに記載されたアクションが成功した場合のみペイロードを送信し、Notification はステータスに関係なくペイロードを送信することになっているという違いがあります。この場合、Commit が選択されています。

コントロール]タブでは、この場合、選択されているアクションは[投稿]、状態は[投稿]です。つまり、Defectレコードを投稿すると、FlaskサーバーにWebhookペイロードがトリガーされることになります。また、Controlsタブに関連した不具合もあり、その対処方法は以下のドキュメントに記載されています。

https://help.hcltechsw.com/compass/2.0.3/com.hcl.compass.doc/webhelp/oxy_ex-1/com.ibm.rational.clearquest.oslc_cmrest_api.doc/topics/t_create_webhook.html

PostmanなどのAPIクライアントを使用して、REST APIサーバーのhooksetupエンドポイントにHTTP POSTリクエストを作成します。このために、まずRESTAPIサーバを起動する必要があります。 Compassのインストールディレクトリに移動し、コマンドラインで以下のパスに移動し、start.batを実行します。

RESTサーバを起動すると、Server is NOT configured for Webhooksのような行が表示されるはずです。

サーバーが立ち上がったら、APIクライアントから、以下のエンドポイントを指定してHTTP POST Requestを実行します。

Method : POST

URL : https://localhost:8190/ccmweb/rest/hooksetup

Body : {

“username”: “admin”,

“password”: “”,

“repo”: “Gitintegration”,

“db”: “GITIN”

}

この場合、GITintegrationがスキーマ・リポジトリ、GITINがユーザー・データベースで、adminはパスワードのないユーザーです。

この場合、RESTサーバは同じマシン上で動作しているため、localhostという名前になっています。Compassで必要なアクションを実行できるシステムユーザーを作成することで、Webhooksパッケージで使用するためのサーバーを有効にします。

RESTAPIサーバーを再起動します。

今度はWebhooksがEnableになったことが確認できます。

Webhooksの実行

ここからは、すべて自動で行われるはずです。Compassは、新しいレコードが送信された瞬間にWebhookのペイロードのトリガーをかけます。このペイロードが正常に送信され、Flaskアプリケーションで読み込めるかどうかを確認します。この作業を行うには、RESTAPIサーバが稼働している必要があり、Flaskアプリケーションも同様に稼働していることを忘れないでください。

• Compassで新しい不具合を作成します。

• RESTAPI サーバが起動していない場合は起動し、Webhooks が動作していることを確認します。

そして、Flask Applicationでも同じようにデータを受信していることが確認できます。

Webhooksのトラブルシューティングはどのように行うのですか？

Compassでクエリを作成し、Webhooksを追跡できます。クエリのベースとなるのは、WebhookDataというレコードタイプにする必要があります。このクエリを実行すると、配信待ちのWebhookがあるかどうか、何回アプリケーションに配信しようとしたか、エラーがあるかどうかを確認できます。

配信するものがない場合、レコードは表示されません。

以下は失敗の例です。今回はFlaskサーバーが起動していないため、レスポンスコードが500、リトライが1となっています。

FLASKアプリケーションのサンプルコードです。

まとめ

注：これはあくまでデモンストレーション用のサンプルコードであり、本番で使用するものではないことに注意してください。

上記からわかるように、このアプリケーションはコンソールにデータを出力する以外には何もしていません。DBに格納したり、ウェブページに表示するために他の目的に使用するなど、他の多くのことを行うことができました。しかし、現実の世界では、サードパーティーアプリケーションとHCL Compassの統合をセットアップすることで、可能性は無限に広がります。Webhooksを使い始め、HCL Compassのデータと連携する可能性を探るきっかけになれば幸いです。

参考文献

https://help.hcltechsw.com/compass/2.0.3/com.hcl.compass.doc/webhelp/oxy_ex-1/com.ibm.rational.clearquest.oslc_cmrest_api.doc/topics/c_webhooks.html

2022/3/9 - 読み終える時間: ~1 分

SRE Tooling and Processes at HCL DevOps (excerpt) の翻訳版です。

HCL DevOps における SRE ツールとプロセス (抜粋)

2022年3月4日

著者: Alexandru Mreana / Manager

SRE の標準が成熟し、市場に採用されたことで、多くの組織の目には SRE が新しい DevOps 2.0 として映っています。

SRE は、Google が最初に策定し普及させた、試行錯誤を重ねた DevOps の実践から発展したものですが、実際には、ほとんどの企業が、自社のビジネスニーズに合わせてカスタマイズした異なる SRE 哲学と原則を持っているでしょう。

ここでは、DevOps ツールを活用する最良の方法、DevOps プログラムを次のレベルに引き上げるために組織が使用しているプロセスと理念、そして HCL の DevOps サービスを最大限に活用する方法について見ていきましょう。

DevOpsは、開発チームと運用チームの間に協力的な文化を構築するために使用される一連のプラクティスであり、生産性を向上させるとともに、ビジネスの市場投入までの時間とコストを削減します。

ここでは、いくつかのSRE標準と、各企業がその標準からどのような利益を得ることができるかを見てみましょう。

1. 組織のサイロ化を防ぐ

開発チームと運用チームのコラボレーションが必要なプロセスを使用するか、両チームが物理的または仮想的に同じ部屋に座ることで、製品がエンドユーザーまでの各フェーズを通過する経路の共有オーナーシップが生まれます。開発、セキュリティ、マーケティング、その他関連するチーム間のコラボレーションとディスカッションは、計画した機能や変更が現実の世界で機能することを保証するための入門書となるのです。

2.失敗を当たり前のこととして受け止める

SLA、SLO、SLIは、パフォーマンスを測定する際に必ず必要なものであり、ビジネスの成功に不可欠なものです。それでも、エラーは発生します。その際、しっかりとしたロールバックプランを用意しておけば、バグのトラブルシューティングに時間を取られることはありません。失敗を正常なものとして受け入れることで、コラボレーションが高まり、チームはエラーに対するより良い準備に集中できます。

3. 漸進的な変更の実施

大きな変更を小さなリリースに分割することで、エンジニアリングチームとオペレーションチームの両方の仕事が容易になります。運用チームにとっては冗長な作業が減り、開発者にとっては調査時間が減ることで、失敗のコストを削減できます。

4. ツールや自動化の活用

自動化は、長期的な価値を創造するための鍵であり、協力チームのアウトプットから自動化が必要なものを特定することから始めることになります。経験則では、自動化の構築にかかる時間がタスクの実行そのものよりもかなり小さい限り、繰り返しのあるタスクには自動化を使用する必要があります。

しかし、労力のレベルは低くてもよく、推奨されており、ほとんどの企業は10～20％の間のどこかに目標を設定しています。HCL Accelerateは、最も頻繁に発生する困難な点を概観し、最初に改善すべき最も重要なステップを特定するために、非常に役立ちます。

5. すべてを測定する

データが多すぎると本当の問題から目をそらし、少なすぎるとプロセスの停滞を誘発します。しかし、ロギング、測定、アラートの違いを見ておく必要があります。ケースや業界によってバランスは異なるだろうし、SLA、SLO、SLIのレベルは、開発、運用、営業などのチームのメイントピックになるはずだ。HCL Accelerate、HCL One Test、HCL AppScanの統合により、製品サイクルのユーザビリティとセキュリティの観点で明確なビジョンが見えてきます。

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

Use a Secondary Request Generator to Effectively Simulate Application Behaviour regarding Static Resources の翻訳版です。

HCL OneTest: セカンダリリクエストジェネレータを用いた静的リソースに関するアプリケーションの動作の効果的なシミュレート

2022年3月1日

著者: Arun Kutty / Lead Software Engineer - L3 support, HCL OneTest Products

概要

ウェブページを提供する際、ブラウザーのクライアントは通常、提供されるコンテンツに基づく一連の静的リソースをアプリケーションからダウンロードする。例えば、eコマースサイトで商品のページに移動すると、その商品の画像が複数表示される。静的リソースの数がページによって異なる場合、ページナビゲーションを指示するテストデータがパラメータ化されると、二次リクエストの正確な数を定義することが困難になる可能性があります。HCL OneTest Performance のセカンダリー・リクエスト・ジェネレーター機能を使用して、これをどのように簡略化できるかを見てみましょう。

二次要求の数が異なる場合

あるショッピングサイトを閲覧しているところを想像してください。ホームページから、特定の商品カテゴリー、例えば、書籍に移動します。このセクションで、興味のあるタイトル、例えば「Test Automation」を検索すると、それにマッチした書籍のリストが表示されます。リストアップされた書籍の中から、気になるものをクリックします。すると、その書籍の専用ページが表示されます。このページには、画像、コンテンツサンプル、購入者のレビュー、FAQなど、あなたの興味を引くような詳細な情報が掲載されており、あなたの意思決定を助けることを意図しています。

今度は別の帽子をかぶってみてください。このショッピングサイトの下にあるウェブアプリケーションに携わるパフォーマンスエンジニアの帽子です。品質保証チームがこのアプリケーションをロードテストする場合、すべての仮想ユーザーが同じカテゴリー「本」をナビゲートし、同じ検索条件を設定するスクリプトがあったとして、あなたはそれを受け入れられるでしょうか？「テストオートメーション "を選択し、同じ検索結果を選択するようなスクリプトがあったとして、受け入れられるでしょうか？広範な負荷テストを達成するためには、ブラウジングパターンに適度な多様性が必要です。したがって、テストスクリプトをさまざまなデータで駆動し、アプリケーションのすべての部分を網羅的にテストすることが必要です。ありがたいことに、パフォーマンステスターはこのステップの重要性をよく理解しており、HCL OneTest Performanceのような製品は、このタスクを簡単にします。(余談ですが、HCL OneTestのポートフォリオには豊富なデータ作成能力もあります)。

二次資産に対する要求の中には、テストデータが変化しても変わらないものがある一方、そうでないものもあります。ショッピングサイトの例で説明しましょう。本のタイトルをテストデータに置き換えても、スタイルシートやスクリプトに関する二次的なリクエストの量に変化はありませんし、おそらくレビューを取得するリクエストにも変化はないでしょう。他の二次リクエストの場合はそうではないかもしれません。ダウンロードが必要な商品画像のリクエストは、選択した書籍によって異なるかもしれません。確かに、相関処理によって、リクエストデータをサーバーが以前に提供したコンテンツに関連付けることは、テストスクリプトの不可欠な部分です。しかし、再生時にリクエストの総数そのものを変化させるには、単純な相関関係だけでは不十分で、何らかの反復ロジックが必要になる。このような状況では、レスポンスの解析やループの制御にループやカスタムコードを使いたくなるのが自然だろう。幸いなことに、HCL OneTest Performanceをテストに使用すれば、この問題は優れた解決策になります。

HCL OneTest Performance のセカンダリ・リクエスト・ジェネレータによる救済

HCL OneTest Performanceは、プルダウンする必要がある必要な数の資産に割り当てられたセカンダリー・リクエストを設定する作業を容易にする、すぐに使えるソリューションを提供します。このソリューションには、3つの個別ステップがあります。最初のステップは、セカンダリーリクエストを駆動するためのすべての参照を含むレスポンスを特定し、そこに配列参照を作成することです。そのような二次リクエストでは、リクエストの置換可能な部分は通常、URI自体にあることに注意すること。さらに、この部分は一般的に画像ファイルの名前です (myBook-image1.JPG のようなもの)。URI断片を置換するための参照値を見つけるには、断片の正確な値でテスト検索（Ctrl + H）を実行します。検索結果から、サーバーがこの値を返した場所を特定します。多くの場合、これはHTMLコンテンツを含むレスポンスで、IMGまたはAタグのHREFプロパティに含まれていることが一般的です。配列参照を作成する際には、通常の参照を作成するのとは少し異なることに注意してください。

配列の参照が作成された後、第2の部分である置換が始まります。通常、単純な置換であれば、リクエストの中から動的な部分を選んで置換すればよいでしょう。しかし、この場合、あなたが目指しているのは単純な置換ではありません。リクエストの数自体が動的である必要があり、配列の参照が指すセカンダリアセットの数によって駆動されることを思い出してください。したがって、何か別のことをする必要があります。それでは、詳しく見ていきましょう。

記録されたテストスクリプトの中で、表示中のアイテムに関連すると思われるリクエストのセットを特定することから、プロセスを開始します。ショッピングサイトの例では、本の画像をサーバーからクライアントにプルダウンするリクエストのセットになります。セット内の1つの要求を別にし、残りの要求を無効化または削除して、要求を取り除きます。無効化されていないリクエストを右クリックし、コンテキストメニューから「セカンダリHTTPリクエストジェネレータの作成」を選択します。これでリクエストは特別なものに変換されます。それが "HTTP セカンダリリクエストジェネレータ" です。

さて、いよいよ最終段階です。リクエストの URI (まれに他のフィールド) を、先ほど作成した配列の参照に置き換えることで、やろうとしたことが完成します。すべてを結びつけるには、HTTPセカンダリリクエストジェネレーターの詳細な設定を行う必要があります。(各プロパティに関する追加情報、およびプロセスをガイドするスクリーンショットについては、HCL OneTest Performance 製品のナレッジセンターを参照してください: https://help.hcltechsw.com/onetest/hclonetestperformance/10.2.2/com.ibm.rational.test.lt.http.doc/topics/t_create_sec_req.html?hl=secondary%2Crequest%2Cgenerator)

まとめ

HCL OneTest Performanceを使ったパフォーマンステストは、精度が命です。HTTPセカンダリリクエストジェネレータは、重要な機能の1つですが、あまり活用されておらず、負荷テストにおいてセカンダリリクエストによる再生の動作を正確にするものです。このブログ記事では、HTTPセカンダリリクエストジェネレータがどのような場合に便利で、どのように使用するのかを学びました。

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

HCL OneTest - Working to Make Maintenance Easier の翻訳

HCL OneTest - メンテナンスを容易にするための取り組み

2022年1月21日

著者: Peter Taylor / SENIOR SOFTWARE ARCHITECT

概要

HCL OneTestは、企業がソフトウェアの品質を向上させ、デリバリーライフサイクルの早い段階で問題を発見することを可能にする製品群を提供します。この製品群は、UI、API、サービスの仮想化、パフォーマンスなど、さまざまな側面のテストを可能にします。では、どのようにすれば効果的にテストを行い、メンテナンスが必要な多くのテストをチームに負担をかけずにアジャイルな状態を維持できるのでしょうか？ここでは、統一された次世代アプローチによってテストのメンテナンスを容易にするために、私たちがどのように取り組んでいるかをご紹介します。

シンプル

統一的なアプローチは、各アスペクトごとに製品を用意するよりも、単一の製品にした方が誰もが暮らしやすくなる、というコンセプトから始まります。そこで、既存の製品でお客様が評価している機能を、ひとつの一貫したフレームワークにまとめた新製品を作る予定です。これにより、ユーザーはUI、API、パフォーマンスのテストや、サービスの仮想化を1つの製品で簡単に実行できるようになります。

シンプルであることに重点を置いているため、どうしても複雑になりがちな製品をただ寄せ集めただけでは理解できない。つまり、複雑になりすぎて理解しにくくなるような製品同士をくっつけることはできないということです。足りない部分は既存の製品で補うことができますし、今後もサポートは継続します。

価値観

テストが壊れたら、いつ直すの？今すぐか絶対か？この質問を評価するためには、「テストの数」ではない品質の指標が必要です。そうでなければ、テストを削除することで品質が低下してしまいます。

そうでなければ、テストを削除することは品質を低下させることになります。目標は常に、高品質のソフトウェアを生産に移すことです。このゴールは、生産時の失敗を減らす場合にのみ遅らせるべきです。もしテストが、失敗を減らすことなく目標を遅らせるのであれば、それはおそらく維持する価値がない。

テストの価値を判断するために、その製品はテストに関するいくつかの指標を提供する必要があります。実行時間は簡単なもので、テスト対象のシステムにおけるコードカバレッジはより複雑なものです。

耐久性

テストはコードの後に書かれることが多いのですが、テスト駆動開発ではこれを改めようとします。コード優先の理由は、その方が簡単に始められるからだ。結局のところ、テスト対象システムが利用できないため、テストは失敗する。しかし、サービス仮想化の統合により、オフラインでテストを実行し、テスト対象のシステムが利用可能になる前に、テストがどのように動作するかを実証できます。最初に書かれたテストは、実装よりも振る舞いを検証するため、より長く使え、メンテナンスの必要性も低くなります。

レジリエンス

メンテナンスがすぐに必要なのではなく、スケジュール化できるようなストラテジーを組み込めます。

• UI テストは通常、Web ページ上のコントロールと連動しています。しかし、コントロールを見つけるために複数のストラテジーを定義した場合、その位置が変わっても、例えばラベルを使用してそれらのオブジェクトを見つけられます。
• パフォーマンステストは、クライアントの実装をシミュレートすることで、エンドユーザーがテスト対象システムをどのように操作するかをスケールで再現します。そのため、クライアントが変更されると、パフォーマンステストは中断されます。パフォーマンステストで使用されるクライアント実装の詳細がUIテストに組み込まれている場合、クライアント実装の詳細の検証は継続的に行われることになる。

即時性

ユーザーがタスクを切り替える前に、変更の意味を理解できるように、できるだけ早くユーザーにフィードバックすることに重点を置いています。

バルク

既存のテストをコピーして少し手を加えるだけで、新しいテストを作ってしまうというミスを犯しがちです。これをやったことがない人はいないでしょう。しかし、今日のクイックウィンは、明日のメンテナンスの頭痛の種です。これは、以下の方法で最小限に抑えられます。

• 再利用可能なステップ群。すでに動作している部分から新しいテストを構築できます。
• 再利用可能なメッセージ。スキーマが変更された時に、多くのテストを変更するのではなく、いくつかのメッセージを変更できます。
• データドリブン。時には、別のテストがスプレッドシートの別の行になることもあるからです。

結論

HCL OneTest 製品群の進化を続ける中で、皆様からのフィードバック、アイデア、ペインポイントなどを https://onetest-ideas.hcltechsw.com/ideas でお待ちしています。