2020/9/15 - 読み終える時間: 10 分

HCL Accelerate はバリューチェーン管理を行うソフトウェアです。ソフトウェア開発で要となる Jenkins との連携の実際を解説する記事 HCL Accelerate VSM with Jenkins – Part 1 の翻訳版です。

HCL Accelerate VSM を Jenkins と組み合わせて使用する - パート 1

2020年9月14日

著者: Daniel Trowbridge / Technical Lead

このチュートリアルでは、HCL Accelerate でビルドデータとデプロイデータをアップロードするための Jenkins パイプラインジョブを作成する方法を紹介します。これは、Jira と GitHub を使った HCL Accelerate VSM シリーズの一部ですが、単体でも一般的なリファレンスとして使用できます。

要件: Jira と GitHub を使用した HCL Accelerate VSM チュートリアルシリーズの事前完了を前提としていますが、完全に必須ではありません。

1. Jenkins インテグレーションを作成する

「HCL Accelerate を使った Jenkins インテグレーションの作成」のチュートリアルに従ってください。

2. バリューストリームに Jenkins インテグレーションを追加する

Jenkins の統合は、他の統合とは異なる方法でバリューストリームに追加されます。vms.json ファイルを編集する必要はありませんが、ビルドデータとデプロイデータのターゲットを持つために、バリューストリームのパイプライン上に「アプリ」を作成する必要があります。

2.1 「パイプライン」に移動し、「アプリの追加」をクリックします。

2.2 ドロップダウンから「Jenkins」を選択します。

2.3 アプリケーション名を入力します。ワークブックでは「JKE App1」という名前を使用します。

2.4 新しいアプリケーションがパイプライン内の行として表示されるはずです。今のところ必要なのはこれだけで、値のストリームに戻ることができます。

3. ビルド、DEV、QA用の Jenkins ジョブを作成する

3.1 新しい Jenkins Pipeline Jobを作成する

3.2 パイプラインスクリプトの設定

パイプラインを作成したら、パイプラインスクリプトのセクションに移動します。スクリプトを貼り付け、変数値を設定した後、「適用」「保存」をクリックします。

• ここにスクリプトをコピー＆ペーストします。
• 変数を正しい値に設定する
• 適用」をクリックし、「保存」をクリックします。

3.2.1 スクリプトのコピーと貼り付け

node {
// URL to Github repository https://github.com/<owner>/<repo>
def GITHUB_REPO_URL="https://github.com/User1098429748/jke-app-1"
// Get ENV ID values for DEV and QA from HCL Accelerate Value Stream "Download attributes from API" json file
def VSM_ENV_ID_DEV="09bd6385-6b46-4fd1-a0b2-56cb0f4ecaf9"
def VSM_ENV_ID_QA="cf601828-3001-433c-bedd-f4574c5cc5f0"
// VSM_APP_NAME must match your HCL Accelerate pipeline application name
def VSM_APP_NAME="JKE App1"
// Time to wait before next stage (seconds)
def SLEEP_TIME=5

// Do not change below this line.
def GIT_COMMIT

stage ('cloning the repository'){
currentBuild.displayName = "2.1.1.${BUILD_NUMBER}"
majorVersion="${BUILD_NUMBER}"
def scm = git branch: 'master', url: "${GITHUB_REPO_URL}"
GIT_COMMIT = sh(returnStdout: true, script: "git rev-parse HEAD").trim()
echo "GIT_COMMIT=${GIT_COMMIT}"
}
sh 'printenv'
stage ("Build") {
echo "Building ${VSM_APP_NAME} (Build:${currentBuild.displayName}, GIT_COMMIT:${GIT_COMMIT}, comit2:${env.GIT_COMMIT}, name:${env.GIT_COMMITTER_NAME})"
step($class: 'UploadBuild',
id: "${currentBuild.displayName}",
versionName:"${currentBuild.displayName}",
name: "${currentBuild.displayName}",
tenantId: "5ade13625558f2c6688d15ce",
requestor: 'admin',
//Must specify one of "appId", "appExtId", or "appName"
appName: "${VSM_APP_NAME}",
revision: "${GIT_COMMIT}",
status: "${currentBuild.currentResult}".toLowerCase(),
startTime: "${currentBuild.startTimeInMillis}",
endTime: "${System.currentTimeMillis()}",
debug: false,
fatal: false,
)
}
stage ("Deploy to DEV") {
sleep "${SLEEP_TIME}"
step([$class: 'UploadDeployment',
//"versionExtId" can be used in place of "id" and "versionName"
id: "${currentBuild.displayName}",
versionName: "${currentBuild.displayName}",
name: "${currentBuild.displayName}",
description: 'UploadBuild Example',
tenantId: "5ade13625558f2c6688d15ce",
initiator: "admin",
//Must specify one of "appId", "appExtId", or "appName"
appName: "${VSM_APP_NAME}",
environmentName: 'PROD',
environmentId: "${VSM_ENV_ID_DEV}",
result: "${currentBuild.currentResult}".toLowerCase(),
startTime: "${currentBuild.startTimeInMillis}",
endTime: "${System.currentTimeMillis()}",
type: "Jenkins",
debug: false,
fatal: false,
])
}
stage ("Deploy to QA") {
sleep "${SLEEP_TIME}"
step([$class: 'UploadDeployment',
//"versionExtId" can be used in place of "id" and "versionName"
id: "${currentBuild.displayName}",
versionName: "${currentBuild.displayName}",
name: "${currentBuild.displayName}",
description: 'UploadBuild Example',
tenantId: "5ade13625558f2c6688d15ce",
initiator: "admin",
//Must specify one of "appId", "appExtId", or "appName"
appName: "${VSM_APP_NAME}",
environmentName: 'PROD',
environmentId: "${VSM_ENV_ID_QA}",
result: "${currentBuild.currentResult}".toLowerCase(),
startTime: "${currentBuild.startTimeInMillis}",
endTime: "${System.currentTimeMillis()}",
type: "Jenkins",
debug: false,
fatal: false,
])
}
}

3.2.2 変数値の編集

編集するスクリプト変数

ENV IDとアプリ名の値は「APIの属性」に記載されています。

パイプライン スクリプトは、HCL Accelerate の値ストリームからいくつかの値を必要とします。これらの値を取得するには、値ストリームのツールアイコンのドロップダウンから「Download attributes for API」をクリックします。このファイルから環境IDとアプリケーション名をコピーして、スクリプト内の変数に貼り付けます。

3.3 「適用」と「保存」をクリックします。

4. ビルド、開発、QAのための Jenkins ジョブを実行する

これで、Jenkins ジョブを実行して、HCL Accelerate 値ストリームのステージの変化を観察する準備が整いました。この時点で、バリューストリームに戻ると、「マージされた」ステージにはまだドットがあるはずです。ビルド、DEVデプロイメント、QAデプロイメントの3つのステップを含む、作成した Jenkins パイプラインジョブを実行します。つまり、ジョブを実行すると、ドットが3つの遷移をするのがわかるはずです。つまり、ジョブを実行すると、ドットが3つの遷移をするのがわかるはずです。

4.1 マージド -> ビルド

4.2 ビルド -> DEV

DEV -> QA

三角形が見えますか？

HCL Accelerate はこのビルドからすべてのコミットデータを取得するので、私たちが作成した PR 以外のコミットが表示されることがあります。これらは三角形で表示されます。これは驚くべきことかもしれませんが、私たちが気づかなかったコミットがビルドに含まれているかもしれないということは、完全に理にかなっています。HCL Accelerate は、私たちのバリューストリームの真の状態を表示しています。

説明

スクリプトをコピー＆ペーストして、ジョブを実行して、効果を観察しただけなら、「OK、結果は見たけど、これはどうやって動いているんだろう？」ということになるかもしれません。もちろん、それに答えるためには Jenkins のパイプラインスクリプトを勉強しなければなりません。スクリプトの2つの最も重要な部分は、以下に説明する'UploadBuild'と'UploadDeployment'のステップです。

• UploadBuild ステップ UploadBuild クラスは、ビルドデータを HCL Accelerate にアップロードするために使用されます。revisionパラメータは、GitHub データ（この場合はGIT_COMMIT）を介してビルドを作業項目にリンクするために重要です。versionName は、デプロイメントへのフォワードをリンクするために重要です。appNameは、HCL Accelerate パイプラインのアプリケーション名に対応します。

step($class: 'UploadBuild',
id: "${currentBuild.displayName}",
versionName:"${currentBuild.displayName}",
name: "${currentBuild.displayName}",
tenantId: "5ade13625558f2c6688d15ce",
requestor: 'admin',
//Must specify one of "appId", "appExtId", or "appName"
appName: "${VSM_APP_NAME}",
revision: "${GIT_COMMIT}",
status: "${currentBuild.currentResult}".toLowerCase(),
startTime: "${currentBuild.startTimeInMillis}",
endTime: "${System.currentTimeMillis()}",
debug: false,
fatal: false,
)

• UploadDeployment ステップ UploadDeployment クラスは、配置データを HCL Accelerate にアップロードするために使用されます。versionName パラメータは、ビルドデータにリンクするために重要です。appName は HCL Accelerate パイプラインのアプリケーション名に対応し、environmentName と environmentId は配置環境を識別するために使用されます。

step([$class: 'UploadDeployment',
//"versionExtId" can be used in place of "id" and "versionName"
id: "${currentBuild.displayName}",
versionName: "${currentBuild.displayName}",
name: "${currentBuild.displayName}",
description: 'UploadBuild Example',
tenantId: "5ade13625558f2c6688d15ce",
initiator: "admin",
//Must specify one of "appId", "appExtId", or "appName"
appName: "${VSM_APP_NAME}",
environmentName: 'PROD',
environmentId: "${VSM_ENV_ID_DEV}",
result: "${currentBuild.currentResult}".toLowerCase(),
startTime: "${currentBuild.startTimeInMillis}",
endTime: "${System.currentTimeMillis()}",
type: "Jenkins",
debug: false,
fatal: false,
])

2020/9/14 - 読み終える時間: 5 分

作業とボトルネックの可視化を実現する HCL Accelerate は、AppScan と組み合わせることもでき、DevOps の可視化と効率化を実現できます。そのことについての解説記事 Integrating HCL AppScan on Cloud (ASoC) with HCL Accelerate の翻訳版です。

HCL AppScan on Cloud (ASoC) とHCL Accelerate の統合

2020年9月12日

著者: Daniel Trowbridge / Technical Lead

ポーカーをプレイしたことがある人なら、カードの組み合わせが重要なことを知っているはずです。ソフトウェアに関しては、適切な製品を組み合わせることで、勝利を手にすることができます。この記事では、HCL Accelerate チームは、HCL AppScan および AppScan on Cloud (ASoC) との統合に注目してみていきたいと思います。

HCL Accelerate は、複数のチームやワークフローにまたがる可視性とガバナンスを提供する、柔軟で強力なリリースおよびバリューストリーム管理ツールです。HCL Accelerate は、1日2回の監督者から現場の DevOps に欠かせないツールです。HCL AppScan は、HCL Accelerate と驚くほど相性が良いのですが、どちらも次世代のソフトウェア開発体験という HCL のビジョンによって推進されています。AppScanは、静的および動的なセキュリティ・スキャンを提供し、オンプレミスとクラウドで提供しています。これらのスキャンは、品質、セキュリティ、およびコンプライアンスにとって非常に重要です。HCL Accelerate は、チーム、製品、ツールチェーン全体で AppScan のデータをインジェストし、可視性とガバナンスを確保することで、作業を継続し、管理を安心して行えるようにします。

さあ、始めましょう。

このチュートリアルでは、AppScanのクラウド提供（AppScan on CloudまたはASoC）を使用します。ASoC アカウントとプロジェクトをまだお持ちでない場合は、無料トライアルを利用して今すぐ設定することができます。また、HCL Accelerate をまだお持ちでない場合は、こちらから Community Edition をダウンロードできます。プロジェクトとスキャンの例を以下に示します。

また、ASoCキーIDとキーシークレットを生成する必要があります。

スキャン結果を生成する準備ができたら、スキャナを実行し、scanIDをコピーして貼り付けます。これは、以下のHCL Accelerateセクションに示されているcurlコマンドに後で必要になります。

1. HCL AccelerateでASoCインテグレーションを作成します。

1.1 プラグインを探す

HCL Accelerate で、Settings（設定）＞Integrations（統合）＞Plugins（プラグイン）に移動し、"Plugin for ASoC"で"Add Integration（統合の追加）"をクリックします。

1.2 統合を構成する

統合の追加」フォームに必要事項を入力します。HCl Accelerate と ASoC への認証を設定します。

• 統合名：ASoC_Example_Name_1
• ユーザー・アクセス・キー。HCL Accelerateのユーザー・アクセス・キーをコピーして貼り付けます。(“Settings” > “My profile” で ASoC_Example_Name_1という名前を付けることができます)
• ASoC ベース URL: https://cloud.appscan.com
• ASoC API Key ID。クラウドAPIの認証に使用するIDです。
• ASoC API Key Secret: クラウドAPIの認証に使用される実際のキー。

1.3 統合の検査

統合が作成されたことを確認します。ドロップダウンの詳細を展開して、エンドポイントのURLを表示します。統合エンドポイントのURLにPOSTコマンドでASoCデータをHCL Accelerateに送信します。

2. ASoCスキャン結果をHCL Accelerateに送信する

ASoCスキャン結果をHCL Accelerateに送信するには、スキャンIDを含むJSONオブジェクトをターゲットのHCL Accelerate統合のpluginEndpoint URLにPOSTするだけです。

データ構造の例

{
"scanId": "<ASoC scan ID>",
}

Curl コマンドの例 curl -H “Content-Type: application/json” -k -X POST https://<accelerate server>/reporting-consumer/pluginEndpoint/<integration ID>/asocScan -d “{\”scanId\”:\”<scan ID>\”}”

3. データを見る

HCL Accelerateでダッシュボードを設定することで、データを見ることができます。インサイト」に移動し、「ダッシュボードの作成」をクリックします。

チャートの追加」をクリックし、適切なメトリクスを選択してチャートを作成します。ASoCデータのデフォルトのメトリックは、「Risk」の下の「Application Vulnerabilities」です（ASoCプラグインのバージョン1.0.16以前の場合、デフォルトのメトリックは「Quality」の下の「ASoC Tests」です）。

フィルタリング・オプション

複数のフィルターや時間の選択など、データの異なる選択で複数のチャートタイプを作成することができます。

各チャートは、以下のように詳細表を表示することもできます。

2020/9/5 - 読み終える時間: ~1 分

Day 2 DevOps : Getting more out of your software delivery pipeline の翻訳版です。

Day 2: DevOps: ソフトウェア・デリバリー・パイプラインをもっと使いこなす

2020年9月4日

著者: Nick Mathison / Value Stream Manager

多くのチームの DevOps の起源は、2つの方法のいずれかで始まった。最初のシナリオでは、製品のリードやマネージャーがカンファレンスから戻ってきて、突然「 DevOps が必要だ！」と主張し、「すべてを自動化する」というマントラを唱える。もう1つのシナリオでは、不正な開発者が手動インストールの繰り返しに飽きてしまい、自分の悩みを自動化することにした場合です。どのようなアプローチであっても、数ヶ月後には、これらの開発チームは、複数のツール、チーム、依存関係にまたがる行き当たりばったりの自動化の上で日々運用されています。さらに、ログイン認証情報、アプリケーション、実行中のプロセス、成功したか失敗したかのログを解釈する能力が必要なので、デプロイメントタスクを実行する方法を理解しているのは、チームの一部の人だけです。

これらのツールを毎日使用していない限り、単純な質問にすぐに答えることは不可能です。"本番ではどのバージョンが使われているのか？今日のCI/CDの世界では、開発者はパイプラインに目を向けて、一貫性のない自動化された世界に構造を提供し、これらの単純な質問に答えるのを助けようとしています。しかし、パイプラインを深く掘り下げていくと、その答えは全体像のほんの一部に過ぎません。

最も単純な形では、パイプラインはアプリケーション・ディストリビューションと、意図されたホストである環境の交差点です。提示されたインベントリは、新しいバージョンがビルドされ、デプロイされると、左から右へ、パイプラインを通って、環境から環境へと移動します。しかし、毎日の複数の CI ビルドのおかげで、何時間も離れて行われるビルドの違いを見分けることができなくなりました。自動デプロイに暗号化されたバージョンを乗算すると、今では無意味なバージョンがあちこちに存在しています。したがって、以下のようなより深い質問に答えるのに役立つ、より高度なパイプラインが必要になります。"本番環境ではどのような変更が行われているのか」、「変更されたバージョンはどのように本番環境にデプロイされたのか」など、より深い質問に答えるのに役立つ、より高度なパイプラインが必要です。このような知識があれば、問題のある変更が発生したときに素早くピンポイントで特定し、問題のあるバージョンをデプロイ前に停止させることができます。幸いなことに、HCL Accelerate は、パイプライン全体にわたってより深い可視性と厳格なガバナンスを提供するように構築されています。その方法をお見せしましょう

パイプラインの構築

始めるために、コードから一歩引いて、候補となるアプリケーションとその関係者を特定します。CI サーバーから始まり、最終的に顧客の手に渡るまで、ビルドされた成果物の移動を支援する個人を含めたいと考えています。これらの利害関係者には、開発、運用、テスト、パフォーマンスエンジニア、リリースマネージャ、テクニカルサポートなどが含まれます。これらのリソースを特定したら、以下の2つのパートのアジェンダで約2時間のセッションを行うために、これらのリソースを集めてください。

まず、以下の 3 つのリストを作成し、既知のすべてのパイプラインコンポーネントを特定します。

• 開発、テスト、本番、リリースの観点から、アプリケーションのデプロイをサポートするために、どのような環境がアップグレードされ、保守されているか？(注: これらの環境は、必ずしもアプリケーションをホストしているとは限りません。パフォーマンスや統合のためなど、適切なテストを行うために、セカンダリインスタンスが必要になることがよくあります。)
• これらの環境を更新するために、どのような手動または自動化されたプロセスを使用していますか？
• リリース前に、どのようなリリース要件、マイルストーン、サインオフをすべてのバージョンで取得しなければならないか？

次に、この情報を手にして、典型的なバリュー・ストリーム・マッピングの手法を使用して、アプリケーションのパイプラインのフローチャートを構築してください。ホワイトボードを使うのが最も一般的ですが、オンラインのエンティティ関係図ツールでも問題ありません。このモデルでは、環境（#1）、プロセス（#2）、および要件（#3）は、それぞれバブル、入力、および出力で表されます。すべての利害関係者が各コンポーネントの配置に満足したら、HCL Accelerateのパイプラインにきれいにトランスポーズするための明確なアクションプランを持って会議から退散することができます。

余談ですが、様々なエンティティのパターンやグループ化は、パイプラインマッピングプロセスの副作用として認識されていた可能性が高いです。例えば、順次デプロイするのではなく、複数の環境を同時にデプロイすることができます。あるいは、環境ごとに1つの自動化スクリプトを使用するのではなく、1つのスクリプトを複数の環境で再利用することができます。あるいは、リリース要件を左にシフトして、無駄なテストを防ぐことはできませんか？これらのアイデアは、CI/CDパイプラインを最適化し、技術的な負債を減らすために重要ですが、それぞれのリストが変わるたびにパイプラインは進化し続けます。いずれにしても、シンプルなパイプラインを採用することは、開発のエンパワーメントを向上させるための大きな一歩であり、パイプラインには柔軟性を期待すべきです。

提供されるパイプライン戦略は、実装を容易にするために焦点が絞られています。完了すると、チームは「すべてを自動化する」という DevOps のマントラをようやくコントロールできるようになったとマネージャーに警告することができ、自信を持って「どのバージョンが本番であるか」という質問に答えることができるようになる。しかし、それはより大きな DevOps の旅の1日目に過ぎない。どのチーム・メンバーでもパイプラインの中のより深い問題を正確かつ迅速に特定できるようになる2日目の課題を解決するために、パイプラインはどのように役立つのでしょうか？

幸いなことに、HCL Accelerate は、先に述べた挑戦的な Day 2 の質問に答える準備ができています。これまでCI/CDツールについてのみ説明してきましたが、チームは、無料のソースコントロールと課題追跡プラグインを利用することで、バージョン、計画された作業、および計画されていない作業の間で点を結びつけることができます。この関係性により、チームは「本番ではどのような変更があるのか」という質問に明確に答えることができます。さらに、当社のパイプラインのデプロイ計画は、監査とトレーサビリティを通じて、「変更バージョンはどのように本番環境にデプロイされたのか」を説明することができます。そして、より厳しい、あるいはより緩い制御が必要な場合には、当社の堅牢なゲーティングシステムを利用して、パイプラインを流れるバージョンを管理します。Day 2の課題は、HCL Accelerat eの無料の Community Edition で反復的に解決することができます。今すぐダウンロードするにはここをクリックしてください

2020/9/1 - 読み終える時間: 2 分

HCL Accelerate はさまざまなツールと連携して追跡ができるようになっています。今回は SAP との連携についての紹介です。How to map and trace changes to an SAP application using HCL Accelerate の翻訳版です。

HCL Accelerate を使用して、変更内容を SAP アプリケーションにマッピングしてトレースする方法

2020年8月31日

著者: Brian Stump / Product Specialist

HCL Software のバリューストリーム管理ツールである HCL Accelerate を使用すると、バックログから本番までのソフトウェアデリバリープロセス全体を追跡できるようになります。HCL Accelerate を使用してSAPアプリケーションのプロセスを追跡する方法については、引き続きお読みいただくか、以下のデモビデオをご覧ください。

この例では、SAP アプリケーションの UI に小さなテキストの変更を加えます。この変更は、Jira、SAP Web IDE、GitHub、Jenkins、ServiceNow を含む当社の DevOps パイプラインを通過しますが、これらはすべて HCL Accelerate との統合によってマッピングされています。

Accelerate のバリューストリームビューは、パイプラインで使用されるツールを自動マッピングすることで、Solution Manager での作成から SAP Cloud Platform でのデプロイまでの変化の流れをマッピング、可視化、解釈します。動画の自動マッピングは以下のように行われています。

まず、SAP で作業項目を作成して、タイトルの Web UI に変更を加えます。この変更は Jira と連携します。Jira で、デプロイ用に選択するワークアイテムを更新します。HCL Accelerate のバリューストリームビューでは、ドットで表される SAP ワークアイテムが "backlog" ステージから "selected for development" ステージに移動したことがわかります。

次に、SAP Web IDE で変更を加え、その変更を GitHub の開発ブランチにコミットしてマージします。このコミットには作業項目 ID が含まれており、これが、HCL Accelerate がその項目を Jira にリンクする方法です。HCL Accelerate で値のストリームに戻ると、SAP のドットが「進行中」の状態に移動していることがわかります。その後、この変更をマージするために GitHub でプルリクエストを作成すると、SAPドットが HCL Accelerate で「マージ済み」の状態に移動します。

項目がマージされると、Jenkins で自動的にビルドが開始されます。このビルドが完了すると、Jenkins はそのビルド情報を HCL Accelerate に渡し、SAP ドットは自動的に「ビルド」状態に移行します。Jenkins が SAP を介したデプロイを完了すると、SAP ドットはデプロイ先の開発環境に移動します。

これらのドットの移動は、単に作業アイテムがパイプラインのどこにあるかを視覚的に確認するだけのものではありません。ワークアイテムがバリューストリームに沿って移動すると、対応するデータが HCL Accelerate に送信されます。パイプラインのどの段階でも、ドットをクリックすると、そのアイテムの完全な変更履歴、関連するワークアイテムやプルリクエストが表示されます。HCL Accelerate の「インサイト」セクションでは、パイプライン内のすべての作業項目からのデータを使用したダッシュボードや詳細なレポートを見ることができます。すぐに使えるダッシュボードを使用して、ビルド数やデプロイメントチャートなどを追跡したり、カスタムレポートを設定して、ビジネス独自の主要なパフォーマンス指標を追跡したりできます。

HCL Accelerate の DevOps パイプラインの視覚的な「ドット」表示により、作業項目がどこにあるかを簡単に確認することができます。また、すでに使用しているソフトウェア開発ツールを接続するための簡単な統合機能により、HCL Accelerate は、DevOps データの単一の真実のソースとなります。無料の Community Edition で HCL Accelerate を今すぐご利用ください。

2020/8/29 - 読み終える時間: ~1 分

Virtualizing Middle-Tier and Back-end Applications の翻訳版です。

HCL OneTest: 中間層およびバックエンドアプリケーションの仮想化

2020年8月28日

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

テストプロセスの間、異なる開発チームが異なる速度で移動するという事実により、配信はしばしば課題となります。

例えば、モバイルチームは毎日確実にリリースできるかもしれません。しかし、ミドルウェアチームは毎週のようにリリースし、メインフレームチームはリリースに1ヶ月以上かかるかもしれません。

目標が継続的なデリバリーであれば、自動テストを行っても、この問題がボトルネックになる可能性があります。

HCL OneTest Virtualization は、不足しているシステム・コンポーネントをシミュレートして、より迅速な開発とテストを可能にします。実際のサービスと同じ方法でネットワーク・トラフィックをリッスンするため、実際のサービスが利用できない場合でも開発とテスト活動を継続することができます。

さらに、受信メッセージをチェックし、それらのメッセージを処理し、記述された動作に従って応答します。

HCL OneTest Virtualization は、元の環境を再構成することなく導入することができ、時間を節約し、エラーを回避することができます。

HCL OneTest Virtualization の詳細については、こちらをご覧ください。

2020/8/29 - 読み終える時間: 3 分

How HCL Launch enables enterprise-level DevOps の翻訳版です。

HCL Launch がエンタープライズレベルの DevOps を実現するしくみ

2020年8月28日

著者: Madhavarao Kulkarni / Associate General Manager

業界を超えた迅速なソフトウェア開発の需要の高まりにより、複雑なDevOpsのセットアップが必要になることがあります。開発ライフサイクルの短縮、デプロイの失敗の減少、コミュニケーションの効率化、コスト削減などの高度な機能が、DevOpsソリューションとサービスの需要を後押ししています。市場投入スピードの重要性が高まる中、企業は迅速な開発とデプロイメントのためにDevOpsソリューションを採用し、手動プロセスを大幅に削減してコーディング・エラーを削減しています。

これは実際にはどのようなものなのでしょうか？ HCL Launch は、最も複雑なデプロイメントを処理し、大企業のために迅速なソフトウェアのアップグレードを可能にするように構築されています。

図: HCL Launch がメインの IT アプリケーションとして使用される典型的な継続的デリバリーパイプライン

エンタープライズユースケース - DevOps を実現する単一の IT Webフォーム

開発チームが、ボタンをクリックするだけで簡単にインフラを手に入れたいと思っていると想像してみてください。開発チームは、簡単なフォームに記入して、物事を完了させるために IT に助けを求めるでしょう。このプロセスは、開発ツールやビルド＆パッケージツールからは単純に見えますが、デプロイメントフェーズやリリースフェーズからは複雑になります。しかし、デプロイフェーズからリリースフェーズになると複雑になります。

複雑なフェーズ

複雑な組織では、以下のような主要なグループがそれぞれ異なる方法でITを管理しており、それぞれが好ましいツールを持っています。効果的な DevOps を提供するためには、すべてが単一のフォームの下に置かれなければなりません。

• オンプレミス、クラウド向けの IT インフラストラクチャのプロビジョニングツール
• 開発と継続的な統合ツール
• デプロイメントとリリースツール
• ユーザーアクセス管理ツール

HCL Launch は、多くのITツールのセットと統合するのに適しており、継続的なデプロイメントを実現するために、開発チームの要求をそれにマッピングするための簡単なオプションを提供します。HCL Launch の大きな特徴の1つは、テンプレートのコンセプトを通して、IT ヘッドの「シングルフォーム」インフラストラクチャの要求を満たしていることです。ユーザーのウェブフォームで定義したものが、HCL Launch のテンプレートとして機能します。

デプロイとリリースのフェーズでは、以下のことを効率的かつミスなく完了させる必要があります。

• アプリケーションを、異なるスクラム/マイクロサービスチームによって開発されたいくつかの成果物の束として可視化する
• 異なるバージョンの成果物を含むアプリケーションを、成果物に変更を加えることなく、安全に Dev-QA-Stage-Prod 型の環境にスムーズに移行させる
• デプロイ、ロールバック、監査を週単位で数回実施する
• この規模のオンプレミスとクラウドインフラへのデプロイメントで 100 のアプリケーションをサポートする
• 適切なチームが成果物のデプロイの適切なセットで動作していることを確認する
• 自動および手動の承認プロセスのオプションを提供する
• 成果物を取得し展開するために、IT ツールに広い範囲で統合する

最後に、異種プロセスを管理し、追跡するのは非常に複雑なので、すべてのエンタープライズアプリケーションが同じ成熟度レベルに入ることを保証する責任があることを覚えておいてください。あなたは、上記の各質問のテンプレートを用意しておく必要があります。これを超えて、成功した DevOps は以下のことを必要とします。

• 最高レベルのフルアプリケーションをデプロイするためのオプションを提供すること
• アプリケーションのフルリリースではなく、影響を受けるモジュールやコンポーネントに基づいて部分的にデプロイすること
• 可能な限り迅速かつ容易なロールバック

複雑なフェーズを単純化するための HCL Launch のキーコンセプト

HCL Launch では、以下のように、ソフトウェアアプリケーションを可視化するための非常にシンプルな定義を提供しています。

• アプリケーション
• コンポーネント
• 環境への取り組み
• リソース
• プロセス
• チーム
• カスタマイズを制御するプロパティ

これらのキーコンセプトを適用することで、上記のユースケースで見てきたすべての基準を満たすような小規模なアプリケーションや大規模なアプリケーションを定義できます。

なぜ HCL Launch がここで正しい選択なのでしょうか？

• テンプレート: HCL Launch は、アプリケーション、コンポーネント、エージェント、プロセス、リソース、チームなどのテンプレートを提供します。

• API ファーストのアプローチ: HCL Launch は API ファーストのアプローチを信じており、APIを介してほぼすべての機能を提供しており、あらゆる規模の企業に容易に統合できます。

• サーバ & エージェントのモデル: アプリケーション・リソースを簡単に定義し、必要に応じてプラグ・プレイができます。デプロイメントのためのインフラストラクチャの健全性と稼働時間を確保するのに役立ちます。

• プラグインを使った IT ツールとの連携・統合: HCL Launch が提供するいくつかのプラグインは、最も一般的なDevOpsツールとの統合を可能にし、デプロイとオーケストレーションのプロセスを定義します。また、独自のツール用に独自のプラグインを作成できます。

• デプロイメントカレンダー: シンプルなデプロイメントカレンダーを保持して、ITにおける全体的なデプロイメントを可視化します。

• コンプライアンスのための監査？デフォルトでは、すべての活動を追跡するために監査情報を提供し、デプロイメントは、コンプライアンスのためにいつでも参照してください。

• 成長管理: デプロイメントに最適なものを提供する場合、HCL Launch を使用したアプリケーションの数の増加を期待できます。HCL Launch は、HAトポロジー、エージェントリレー、アクティブアクティブサーバー、分散フロントエンドなどを提供します。

よく定義された継続的なデプロイメントは、エンタープライズ向けの強力なリリース管理プラクティスを可能にし、よく定義された継続的なデプロイメントは、HCL Launch によって達成されます。

2020/8/27 - 読み終える時間: ~1 分

パフォーマンス・テスターの最大の悩みは、負荷をかけるためのデータを作成でしょう。HCL OneTest Performance はワークロードを生成し、テスターの負荷を下げると共に、現実に即した検証ができるようにします。紹介記事 Identifying and Managing the Risk of Application Performance Failures の翻訳版を掲載します。

アプリケーションのパフォーマンス障害のリスクの特定と管理

2020年8月27日

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

アプリケーションへの負荷の影響を分析するパフォーマンス・テストを迅速に実行することは、大変な作業になります。

テスターは、Web およびサーバーベースのアプリケーションのスケーラビリティを検証し、システム・パフォーマンスのボトルネックの存在と原因を特定し、バージョン間のパフォーマンスの変化を追跡できる必要があります。

HCL OneTest Performance は、パフォーマンス・テスターが日々のユーザー活動をモデル化した現実的なワークロードを簡単に作成できるようにすると同時に、土壇場のパフォーマンス問題を排除することができます。ベアメタルや Docker エージェントを介して拡張可能で、パフォーマンス・テスト・プラットフォームのプロビジョニングがこれまでになく簡単になりました。

HCL DevOps との統合により、デリバリー・パイプラインにパフォーマンス品質のメトリクスをもたらすことが簡単かつ効果的になります。

HCL OneTest Performance の詳細についてはこちらをご覧ください。

2020/8/26 - 読み終える時間: ~1 分

HCL OneTest API は文字通り API のテストを行う製品です。その紹介記事 Ensuring Sound Integration of Complex Systems の翻訳版です。

複雑なシステムの健全な統合

2020年8月26日

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

最近では、さまざまなネットワークプロトコルやメッセージフォーマットに対応したシステムのAPIを検証することが必須となっています。

大規模なトランザクション内の個々の交換を検証するために、テストケースを作成する必要があります。そして、これは、記録とサービスの仮想化のための同じ技術を使用して、押しつけがましくない方法で行われなければなりません。

HCL OneTest API は、さまざまなネットワーク・プロトコルやメッセージ・フォーマットを横断して、システムのAPIをトリガーし、検証します。

HCL OneTest API は、エンタープライズ・メッセージングやビジネス・プロセス統合プロジェクトのテストを開発するためのスクリプトなしの環境を提供します。HCL OneTest API のオーサリング環境は、環境発見、システムモデリング、メッセージ記録のための同じツールを使用して、テストを作成するためのベースライン・データを提供する機能を提供します。

サンプルメッセージを作成し、複数のテストケースで参照することで、最大限の再利用性を得ることができます。これらのメッセージはテンプレートとして使用することができ、テストグループの簡単な更新を可能にし、共有された検証ルールにより、複数のテストケースで検証を再利用することができます。

HCL OneTest API の詳細については、こちらをご覧ください。