SonarQube と HCL Accelerate の接続方法

2020/8/13 - 読み終える時間: 7 分

https://blog.hcltechsw.com/accelerate/how-to-connect-sonarqube-to-hcl-accelerate/

How to Connect SonarQube to HCL Accelerate

SonarQube と HCL Accelerate の接続方法

2020年8月12日

著者: Daniel Trowbridge / Technical Lead, HCL

画像の説明

このチュートリアルでは、HCL Accelerate と SonarQube の統合を設定する方法を説明します。SonarQube は、コード品質の測定と追跡、および静的コード分析のために、バリューストリームと一緒に使用することができます。SonarQube 統合は、後述する webhook パターンに依存するという点で、他の統合とは少し異なります。このパターンは効率的ですが、SonarQube インスタンスの追加設定が必要で、このチュートリアルで説明する証明書の問題が一般的です。

画像の説明

あなたに必要なもの

HCL Accelerate での管理職権限

  • ユーザーアクセスキーの作成
  • 統合の作成

SonarQube の管理者権限

  • SonarQube auth トークンの作成
  • プロジェクトまたはグローバルレベルのウェブフックの作成
  • HCL Accelerate 証明書のトラブルシューティングと問題解決

1. Webhook パターン

HCL Accelerate は、SonarQube と統合するために webhook パターンを使用します。webhookは、プロジェクトの分析が終了するたびにHCL Accelerateに通知するために使用され、HCL Accelerate はその後、分析に関する追加情報を SonarQube から取得します。各統合は、SonarQubeがwebhook URLとして使用する独自の HCL Accelerate エンドポイントを作成します。この方法で複数の SonarQube 統合を設定したり、1 つの統合をウェブフックするように複数の SonarQube インスタンスを設定したりすることができます。ニーズによって異なります。

**2. 統合の作成***

HCL Accelerate で SonarQube 統合を作成します。Settings」>「Integrations」と進み、「Plugins」タブの下にあるSonarQubeプラグインの「Add Integration」をクリックします。必要なフィールドをすべて入力します。

注:イテレーションを作成した後、アップデートが利用可能かどうかを確認してください。統合を最新バージョンにアップデートすることをお勧めします。

  • インテグレーション名
  • SonarQube URL
  • SonarQube 認証トークン: SonarQube の認証トークンは、SonarQube の「ユーザー」>「マイアカウント」>「セキュリティ」(SonarQube のドキュメント)から作成することができます。
  • HCL Accelerate User Access Key: アクセストークンを作成するには、「設定」→「マイプロファイル」で「作成」をクリックします。アクセスキーは、使用するインテグレーションに合わせて名前を付けておくと良いでしょう。後でキーをコピーできなくなるので、この時点で必ずコピーしておきます。

画像の説明

3. Webhookの設定

HCL Accelerate の「統合」タブに移動して、統合が作成されたことを確認します。統合の詳細を展開して、そのエンドポイント URL を確認します。このエンドポイント URL を指すように SonarQube のウェブフックを設定します。SonarQube のウェブフックは、プロジェクトレベルまたはグローバルレベルで設定できます。詳細については、SonarQube のドキュメントを参照してください(https://docs.sonarqube.org/latest/project-administration/webhooks/)。

  • HCL Accelerate からの統合コールバック URL のコピー
  • 統合コールバックURLでSonarQube Webhookを設定

4. Webhooks のトラブルシューティング

4.1 webhook エラーの原因の特定

SonarQube の現在のバージョンでは、Webhook の失敗エラーは簡単には表示されません。webhook エラーをトラブルシューティングするには、まず SonarQube コンピュートエンジンのログレベルを DEBUG に変更してから、プロジェクト解析を実行して webhook を起動し、UI からログをダウンロードして(またはサーバー上のログを検査して)、webhook エラーを報告している行を探してください。詳細は SonarQube のドキュメントを参照してください。

4.2 一般的な証明書エラー

webhook は https であるため、SonarQube は証明書要件を強制するため、通信に失敗する可能性があります。証明書は通常、以下のような理由で失敗します。

  • トラストストアの要件。詳細は下記の自己署名証明書エラーの解決を参照してください。
  • ホスト名の一致: 証明書で指定されたホスト名は、webhook URL で使用されるホスト名と一致している必要があります。

5. 自己署名証明書エラーの解決

HCL Accelerate の本番インスタンスでは、認証局(CA)が発行した証明書を使用する必要がありますが、特にテストや実験システムでは、本格的な証明書が必ずしも利用できるとは限りません。そのような場合は、HCL Accelerate に同梱されている自己署名証明書を代わりに使用することができます。ただし、自己署名された証明書であるため、SonarQube のようなサードパーティ製アプリケーションを信頼するように設定する必要があります。さらに、証明書のホスト名は、webhook ホスト名と同じである必要があります。

5.1 有効な証明書ホスト名の確認

まず、ホスト名が正しく設定されていることを確認します。証明書のホスト名が実際のホスト名と一致しない場合は、実際のホスト名を変更するか、正しいホスト名で新しい証明書を作成してください。例えば、以下のように OpenSSL を使用します。

openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out certificate.pem

新しい証明書が作成された場合、HCL Accelerateはその証明書を使用して設定する必要があります。docker-compose インストールの場合、証明書は /2.0.4/conf/ssl の下に配置する必要があります。

5.2 証明書を SonarQube サーバーにコピーする

証明書は、HCL Accelerate サーバーから直接コピーすることができます。Docker-Compose インストールの場合、証明書は/conf/sslの下にあります。また、ブラウザーから直接証明書をダウンロードすることもできます。Firefoxでは、証明書を表示してダウンロードできるようにすることで、これを簡単に行うことができます。証明書を入手したら、SonarQubeサーバーに転送します。例えば、SCP を使用したり、他の任意の方法で転送することができます。

FireFox で証明書をコピーするには? URL 証明書のドロップダウンから「More Information」をクリックし、「View Certificate」をクリックして、PEM ファイルをダウンロードします(Mac 版 FireFox は以下の図とは異なる UI を持っています)。

5.3 SonarQube サーバーの Trust Store に証明書を追加する

オプション A - デフォルトのトラストストア "cacerts"

デフォルトの Java トラストストアは「cacerts」です。これが SonarQube が使用しているトラストストアであれば、自己署名証明書を "cacerts" に追加し、SonarQube を再起動して作業を進めることができます。

  • を証明書の記述的なエイリアスに置き換えます。
  • を実際の証明書パスに置き換えてください。
  • 実際のパスワードを使用します。そうでない場合は、changeit とします。以下のコマンドを使用して、cacertsのトラストストアに証明書を追加します。

$JAVA_HOME/bin/keytool -import -trustcacerts -keystore -cacerts -storepass changeit -noprompt -alias <cert_alias> -file <cert_path.pem>

  • 証明書がcacertsに追加されたことを確認します(オプション)。

$JAVA_HOME/bin/keytool -list -v -cacerts -storepass changeit | grep <cert_alias>

オプション B - 新しいトラストストア

場合によっては、単に証明書をデフォルトのトラストストアとして cacerts に追加するのではなく、新しいトラストストアを設定する必要があるかもしれません。

  1. トラストストアとして使用する新しいキーストアを作成します。

必要に応じて、以下のコマンドを実行して値を置換してください。

  • を証明書の記述的なエイリアスに置き換える。
  • を実際の証明書パスに置き換える。
  • を実際の名前に置き換える。
  • パスワードは changeit 以外のパスワードを作成することを検討してください。

$JAVA_HOME/bin/keytool -import -trustcacerts -alias <cert_alias> -file <cert_path.pem> -keystore JAVA_HOME/lib/security/<new_trust_store.jks> -storepass changeit -v

  1. 先ほど作成した .jks ファイルをトラストストアとして使用するように SonarQube を設定します。

<SonarQube インストールパス>/conf/sonar.properties を以下のように編集します。

  • <新規作成された .jks ファイルへのパス>を実際のパスに置き換えます。
  • changeit "ではない場合は実際のパスワードを使用してください。
#--------------------------------------------------------------------------------------------------
# TRUST STORE
# Overrides default trust store for certificates (Default is $JAVA_HOME\lib\security\cacerts)
sonar.ce.javaAdditionalOpts=-Djavax.net.ssl.trustStore=<path to newly created .jks file> -Djavax.net.ssl.trustStorePassword=changeit -Djavax.net.ssl.trustStoreType=jks

6. 証明書エラーの代替回避策: http ルート の使用

デフォルトの webhook ルートは https です。これは確かにセキュリティ上の理由から推奨されています。webhook の http ルートを公開することで証明書の要求を回避することは可能ですが、可能であればこれは避けるべきです。自己署名証明書とは異なり、http ルートは証明書の認証の利点を取り除くだけでなく、 トランスポート層の暗号化も取り除きます。http ルートを使う場合は、このトレードオフを意識することが重要です。

6.1 http ポートを公開する

docker-composeインストールでは、以下に示すように、ポート6004を開くために docker-compose.override.yml 構成ファイルを使用します。このファイルは、HCL Accelerateのインストールディレクトリーに、Accelerateのdocker-compose.yml ファイルと一緒に作成します。オーバーライドファイルがすでに存在する場合は、必要に応じて、services、reporting-consumer、および ports の下に適切な構成を追加します。

version: '2.1'
services:
  reporting-consumer:
    ports:
      - "6004:6004"

6.2 webhook の変更

SonarQube の webhook URL を、https レポート作成用の消費者ルートから http ポート 6004 ルートに変更します。

デフォルトの https 形式

https://<accelerate-hostname>/reporting-consumer/pluginEndpoint/<integration id>/sonarqube/callback

http 形式を変更します。

http://<accelerate-hostname>:6004/pluginEndpoint/<integration id>/sonarqube/callback


HCL Accelerate Community Edition を知る

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

HCL Accelerate には、無償利用が可能な Community Edition があります。そのことについての英語版ブログの記事 Get to know the HCL Accelerate Community Edition の解説記事です。


HCL Accelerate Community Edition を知る

2020年8月6日

著者: Bryant Schuck / Product Manager for HCL Software DevOps

画像の説明

HCL Software DevOps のチームは、当社のバリュー・ストリーム管理ツールの無料版である HCL Accelerate Community Edition を提供することに興奮しています。

HCL Accelerate Community Edition には、2 ユーザーの同時使用権が付属しており、「2 つのピザ開発チーム」に最適です。Community Edition は、Standard Edition と同じバリューストリーム管理、リリースオーケストレーション、分析機能をすべて備えていますが、小規模なチームに最適です。HCL Accelerate Community Edition は、hclsw.co/getaccelerate にアクセスすることで、すぐに使い始められます。

Community Edition は、バリュー・ストリーム管理を始めるのに最適な方法ですが、エンタープライズレベルの組織には HCL Accelerate Standard Edition をお勧めします。Community Edition はチーム間での拡張はできませんが、HCL Accelerate の使用を拡大する準備ができたら、Community Edition の個々のインスタンスを Standard Edition にアップグレードできます。アップグレードすると、すべてのデータと設定が保存され、Standard Edition に転送されるため、まず Community Editionを試してみて損はありません。HCL Accelerate に 2 人以上のユーザーが必要になることがわかっている場合は、60日間の無料トライアルを利用してすぐに Standard Edition を利用できます。60 日間の無料トライアルが終了すると (ライセンスを購入しなければ) HCL Accelerate の Standard Edition は Community Edition となります。

HCL Accelerate の Get Started ページには多くの情報が掲載されていますが、ここではCommunity Edition に関するその他のよくある質問をご紹介します。



画像の説明


Community Edition のシステム要件は何ですか?

Docker Compose をインストールするには、4 CPU コア、8GB の RAM が必要です。Linux、MacO、Windows OS をサポートしています。ただし、OS のサポートは選択した Docker Platform に基づいています。CEとSEの機能セットは同じなので、システム要件も同じです。

本番環境で HCL Accelerate を構成する場合は、当社のドキュメントに記載されている推奨システム要件に従ってください。注: 本番環境での使用のための Docker Compose はサポートしていません。

自分が辿って習得できるような、サンプルやテンプレートの値ストリームはありますか?

HCL Software のドキュメントには、リンクルール、メトリクス、ステージなど、バリューストリームの構築方法についての多くの例があります。

HCL Accelerate プラグインと統合の違いは何ですか?

他の HCL Software DevOps 製品と同様に、HCL Accelerate では、プラグインのセットをサポートしています。HCL Accelerate では、統合はプラグイン自体のインスタンス化です。プラグインの複数の設定(異なるプロジェクトやサーバー用に設定された JIRA プラグインなど)があるかもしれないので、区別を指定できるようにしたいと思います。

HCL Accelerate プラグインはどこでダウンロードできますか?

HCL Accelerate の素晴らしい点の一つは、プラグインの管理をプラグインフレームワークが行うことです。HCL Accelerateプラグインは、HCL Software の Docker レジストリ内の Docker イメージとしてホストされ、インストールおよびアップグレード時に自動的にプルされます。ローカルにインストールされると、HCL Accelerate は内部レジストリからプルされ、より高速な統合ランタイムを実現します。

ネットワークチームが当社の公開 Docker レジストリからのダウンロードを禁止している場合は、ファイアウォールの後ろにある既知のカスタムレジストリからダウンロードするように HCL Accelerate を設定できます。

設定された HCL Accelerate 統合をバリューストリームに接続するにはどうすればよいですか?

すべてのバリューストリームは、JIRA や GitHub などの設定済みの統合からのデータで構成されています。今日では、これらの統合は VSM json 内で設定する必要があります。

例えば、次のスニペットを VSM JSON の integrations セクションに追加して、2 つの設定された統合を割り当てます。

“integrations”:

{

"name". "my-bitbucket-integration"

},

{

"name". "my-github-integration"

},

インポートすると、HCL Accelerate は、設定で構成された統合から自動的に値を取得します。VSM JSON をエクスポートすると、新しくマッピングされた統合の下に、より多くの設定値があることがわかります。

VSM JSON を使用して新しい統合を作成したい場合は、すべてのプラグインの設定値を提供できます。各プラグインで設定に必要な値が異なるため、プラグインのドキュメントを参照してください。

HCL Accelerate の設定について、1対1のサポートを受けられますか?

はい!このページのフォームにご記入ください (英語)。


HCL Accelerate Metrics Bar を使用して、バリュー・ストリームの洞察を獲得する

2020/8/6 - 読み終える時間: 2 分

HCL Accelerate の機能紹介シリーズの Get insights into your value stream with the HCL Accelerate Metrics Bar の翻訳版です。


HCL Accelerate Metrics Bar を使用して、バリュー・ストリームの洞察を獲得する

2020年8月5日

著者: Bryant Schuck / Product Manager for HCL Software DevOps

画像の説明

今日のソフトウェア開発ライフサイクルの世界では、継続的な改善は非常に一般的な目標であり、多くのチームが手法としてアジャイルを使用しています。多くのチームがアジャイルの一部を導入していますが、実際に改善しているでしょうか?そして、SDLC のどの部分が改善されているのでしょうか?多くの企業がフォローしたい主要なメトリクスを追跡しているかもしれませんが、それは通常、スプレッドシートを介してか、エコシステム全体の中から1つのツールを使って生成されています。これらの方法はどちらも正確ではなく、面倒です。

HCL のバリュー・ストリーム管理プラットフォームである HCL Accelerate は、メトリクス・バーと呼ばれる機能でこの問題を解決しています。メトリクス・バーはバリュー・ストリームに特化したもので、リードタイム、サイクルタイム、ビルド頻度、ワークアイテムの分布など、チームが気にしている主要なメトリクスをレポートできます。これは、プロセス全体を改善しようとするチームにとって非常に重要です。

画像の説明

サイクルタイムが品質とどのように相関しているか、ということを示す素晴らしい例があります。高いパフォーマンスを発揮するチームは、頻繁にリリースしても、作成される欠陥が少ないことはよく知られています。HCL Accelerate のメトリック・ウェアハウスを使用すると、メトリック・バーは、多くのツールにわたってこれら 2 つのメトリックをリアルタイムで追跡し、1 つのメトリックを改善しても他のメトリックが損なわれないように正確な画像を提供できます。

メトリック・バーは、バリュー・ストリームごとに最大 6 つのメトリックをサポートしています。これにより、プロセスがどのように改善されているかを確認するのに十分なメトリクスが得られますが、圧倒されるほど多くのメトリクスは得られません。メトリクスの追加は、メニューから1つを選択するのと同じくらい簡単で、組織のニーズに合わせてメトリクスをカスタマイズできます。

これらのメトリクスは、統合からのデータを使用して入力されるので、データが表示されない場合は、そのデータと相関する統合があることを確認してください。例えば、デプロイ頻度をバーに追加したい場合は、HCL Launch やその他のデプロイツールとの統合が必要になります。

チームが必要としているメトリクスが見つからない場合は、いくつかの簡単なステップを踏むだけで、デプロイ頻度を追加できます。いくつかの簡単なステップで、カスタムメトリックを作成できます。プロプライエタリなツールからの特定のデータがある場合、これは誰にでも可視性を得るための簡単な勝利です。ここでは、あなたを始めるための簡単なワークブックをご紹介します。すべての呼び出しとデータ操作を、設定されたスケジュールでメトリックを生成する軽量なスケジュールイベントにラップできる独自のカスタムプラグインを作成できます。

無料のコミュニティー版で HCL Accelerate のメトリクスバーやその他の機能をチェックしてみてください。ダウンロードはこちらから。


HCL Accelerate: Value Stream Manager とは?

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

DevOps の実際においては、全体の流れとその価値創出や問題点の把握・解決を行う「バリュー・ストリーム・マネージャー」が重要な役割を担います。この「バリュー・ストリーム・マネージャー」についての解説記事 What is a Value Stream Manager? の翻訳版です。


HCL Accelerate: Value Stream Manager とは?

2020年8月3日

著者: Nick Mathison / Value Stream Manager

画像の説明

HCL Value Stream Manager としての私の役割は、通常の開発プロセスの中で発生する可能性のあるドラッグや問題点を減らしながら、開発プラクティスを流れる作業のスループットを向上させることです。要するに、私の仕事は、改善すべき領域を特定し、それに対処することです。

もしあなたが新しいバリュー・ストリーム・マネージャーであれば、最初から設計、分析、開発、テスト、QA、開発、リリースに至るまでのバリュー・ストリームをマッピングすることからこのプロセスを始めるでしょう。その後、チームと協力してギャップや誤解を特定します。このバリュー・ストリーム・マップは、私がデリバリ・パイプラインを分析するために使用している主要なツールです。

このマップをダイアグラム化したら、バリューストリームを、すべてのツールと統合できるバリューストリーム管理製品に変換して、バリューストリームの項目をフォローしてください。そうすれば、バリュー・ストリームの問題を簡単に発見し、診断し、行動計画を立てることができます。バリュー・ストリーム管理ツールは、バリュー・ストリームを可視化できるだけでなく、リードタイム、サイクルタイム、平均回復までの時間などのメトリクスを追跡し、改善の測定をさらに容易にします。

バリュー・ストリーム・マネージャーになるために必要なことの詳細については、以下のビデオをご覧ください。


HCL Accelerate と ServiceNow によるリリース管理

2020/8/4 - 読み終える時間: 5 分

HCL Accelerate は ServiceNow とも連携できますが、その実際について記した記事 Release Management with HCL Accelerate and ServiceNow の翻訳版を掲載します。


HCL Accelerate と ServiceNow によるリリース管理

2020年7月31日

著者: Brian Stump / Product Specialist

画像の説明

リリース管理は、アプリケーションやインフラストラクチャを問わず、企業のソフトウェア環境に変更を加える際の基本的な側面です。特に、リリースがさまざまなチームやビジネスユニットにまたがる複雑なものになると、そのための再現性のあるプロセスを確保することが重要になります。

HCL Accelerate は、使いやすくテンプレート化されたリリース管理ソリューションを提供し、ネイティブの ServiceNow との統合により、変更とリリース管理プロセスを緊密に同期させています。このブログ記事では、ServiceNow と連携した HCL Accelerate でエンタープライズリリース計画を設定し、本番環境にソフトウェアを配信する方法を説明します。

HCL Accelerate でエンタープライズリリーステンプレートを作成する

最初のステップは、HCL Accelerate でエンタープライズリリーステンプレートを作成することです。このテンプレートは、メジャーリリースイベントの一部として新しいソフトウェアをリリースするたびに実行されるプロセスを表しています。これを、チーム、ビジネスライン、またはこのイベントの一環として本番稼動を希望するグループ全体のリリースをオーケストレーションするための「親」計画と考えてください。

画像の説明

リリースが作成されたときに、このテンプレートから作成された計画を自動的に開始する」オプションがあることに注意してください。はい」ボックスにチェックを入れると、リリースが HCL Accelerate で作成されるたびに、リンクされた ServiceNow 変更チケットも作成されます。この場合、「いいえ」に設定するつもりなので、変更チケットは、セクション3でリリースの実行を開始した後に作成されます。

テンプレートを作成したら、リリースがテンプレートから作成されるたびに、リリースのタスクを定義します。ここでは、ServiceNow との統合を設定し、承認と通知タスクを介してガバナンスを確立し、他の自動または手動のタスクを設定します。

ServiceNow との統合のために、リリース計画が実行されるたびに変更チケットを作成して更新する一連の ServiceNow タイプのタスクを定義します。最初のタスクは変更を作成することになります。次のスクリーンショットは、ServiceNow に接続する変更チケットの作成タスクを示す設定例です。HCL Accelerate のリリースプロセス全体を通して、変更を ServiceNow でいつ、どのように更新したいかに応じて、この設定方法には多くの柔軟性があります。

画像の説明

設定している 'ticketId' フィールドに注目してください。これは、リリースの進行に合わせて新しく作成されたチケットを更新していることを確認するために、後のステップで参照するプロパティを作成します。

作成できる ServiceNow タスクのもう一つのタイプは、変更チケットの承認を待つことです。これを行うには、アクション「変更要求を待つ」を選択し、関連するフィールドと値を設定する必要があります。リリース計画がこのステップに達すると、HCL Accelerate は、設定された間隔に基づいて ServiceNow をポーリングし、それらのフィールドと値が設定されたものと一致するまで待ちます。この場合、チケットが承認されるまでタスクは「進行中」になります。

画像の説明

システムIDフィールドは、チケット作成ステップで設定した'ticketId'プロパティを参照していることに注意してください。このプロパティは、HCL Accelerate が使用するタスク間で一貫している限り、任意の名前を持つことができます。また、このプロパティは子プランには継承されないので、他のテンプレートが競合せずに同じプロパティ名を使用できることにも注意してください。

ServiceNow タスクの最後のタイプは、「変更要求の更新」アクションです。wait'タスクと同様に、これは最初に作成されたチケットを参照するためにシステムIDを使用します。今回は、ServiceNow で変更が発生するのを待つ代わりに、HCL Accelerate を使用して ServiceNow でチケットに変更を加えることができます。追加プロパティ」フィールドでは、「field=value」構文を使用して、フィールドを新しい値で更新することができます。ほとんどの場合、チケットを「実装」や「スケジュール」などの新しい「状態」に更新します。更新された値がチケットの現在の状態に基づいて ServiceNow で許可されていることが重要です。

画像の説明

ServiceNow のデフォルトの「状態」の値はここに示されています。ServiceNow API はこれらの数値を使用して値を割り当てます。

画像の説明

他のエンタープライズリリースの管理タスクと同様に、ServiceNow タスクを設定した後、他のテンプレートのプランをデプロイメントタスクとして追加して、より大きなリリースのガバナンスを設定できます。前述したように、この「エンタープライズ」プランは、ソフトウェアをデプロイするプランの親となります。HCL Accelerate で作成されたパイプラインステージごとに、対応するテンプレートが存在します。これらのテンプレートをエンタープライズプランに追加するには、「別のプランを実行」というタスクを使用します。

画像の説明

このユースケースでは、JKE-パイプラインPRODステージテンプレートをすでにセットアップしていると仮定しています。このテンプレートは、私のエンタープライズプランに似ていますが、Jenkins、HCL Launch、またはAnsibleのいずれかを介して実際にソフトウェアをデプロイするためのタスクが含まれています。Run another plan」タスクでこのプランを参照することで、エンタープライズリリースプランを介して、1つまたは多数のデプロイメントプランをオーケストレーションすることができます。

さて、私はエンタープライズリリース計画のテンプレート化を完了しました。この作業は、全体のプロセスを変更したり改善したりするために、あちこちで微調整することを除けば、すべて一度きりの作業です。私の組織がエンタープライズリリースを実行したいと思うたびに、このテンプレートから実行を開始します。

画像の説明

実行するリリースの作成

テンプレートが作成され、ServiceNow と同期されたので、最初のリリースを実行する準備ができました。最初のステップはリリースを作成することです。次のスクリーンショットは、テンプレートから作成されたエンタープライズリリースの例を示しています。

画像の説明

後で検索して見つけやすくするために、タグを使用していることに注意してください。

私のリリースが作成されると、私のチームやビジネスユニットは、自分のデプロイメントテンプレートを使ってこのリリースに参加できます。ここで使用している例は、「JKE-パイプライン」のためのものです。エンタープライズリリースに参加するには、示されているように、PRODステージの横にある矢印をクリックして、「リリースに参加」をクリックします。

画像の説明

ここから、どのリリースに参加したいか、また、どのアプリケーションのバージョンをリリースと一緒にデプロイしたいかのオプションが与えられます。デフォルトでは、最も近いステージにあるバージョンが選択されますが、この場合は、すでに「QA」ステージに配信されているバージョンです。

画像の説明

「スケジュール」をクリックすると、エンタープライズリリース計画のビューには、新しく参加した JKE-パイプラインチームの計画が反映されます。

画像の説明

エンタープライズリリースの実行

セクション 1 では、エンタープライズリリースのテンプレートを作成する方法を示しました。セクション2では、スケジュールされたエンタープライズリリースを作成する方法と、様々なチームが参加できる方法を示しました。このセクションでは、そのリリースの実行例を説明します。

リリースを開始するには、エンタープライズリリースの最初のタスクで再生ボタンをクリックするだけです。これにより、ServiceNow チケットが作成され、リリースクロックが開始されます。このチュートリアルの最初に「このテンプレートから作成された計画を自動起動する」というオプションがあったことを覚えていますか?ここで 'Yes' を選択していた場合、リリースが作成されたときにプランはすでに開始されており、次の手動タスクを待っていました。この例では、私たち自身が計画を開始しています。

画像の説明

リリースが開始されたので、ServiceNow の承認を待つタスクで一時停止します。ServiceNow でチケットを承認するためには、ServiceNow サーバーにログインして変更の承認を要求し、指定された承認者に変更を承認させる必要があります。実際の実行では、このプロセスには、HCL Accelerate ツールと ServiceNow ツールの両方にまたがるさまざまな利害関係者が関与することになります。両者が同期するように設定しているため、ServiceNow で承認が得られれば、すべての更新が自動的に発生し、リリース計画は継続していきます。

画像の説明

エンタープライズリリース計画が自己定義した「デプロイメント」タスクに到達すると、エンタープライズリリースに参加した PROD テンプレートが実行を開始することがわかります。次のスクリーンショットは、この PROD テンプレートがどのように見えるかの例を示しています。

画像の説明

このテンプレートには、ServiceNow との統合も含まれていることに注意してください。これは、この例では、エンタープライズリリース自体のチケットを作成し、それと一緒にリリースしているアプリの各チームやグループのチケットを作成しているからです。このようにして、エンタープライズレベルだけでなく、より詳細なチームやアプリケーションレベルでも承認と変更を管理できます。

JenkinsやHCL Launchを介したデプロイが完了し、ServiceNow のチケットが更新されると、エンタープライズの計画を進めていくための Success が返ってきます。スケジュールリリースのページを確認してみると、作成した変更チケットがリンクされて表示されています。この場合、エンタープライズプラン用に1つ、それに参加したパイプライン PROD デプロイメント用に1つ作成しています。多くのチームがこのエンタープライズリリースに参加していた場合、ここには多くのチケットが表示されます。

画像の説明

同様に、ServiceNow では、HCL Accelerate によって作成・管理されたこれらの変更チケットを見られます。

エンタープライズリリース計画が成功したので、リリースサマリーページでこのように確認できます。

画像の説明

また、このエンタープライズリリースに参加したパイプラインを確認できます。パイプラインビューでは、私のQA環境から選択した最新バージョンが本番環境にデプロイされて実行されていることがわかります。

画像の説明

HCL Accelerate の詳細と無料トライアルを入手するには、ここをクリックしてください。


HCL Accelerate: バリューストリームにおけるボトルネック

2020/8/4 - 読み終える時間: 2 分

HCL Accelerate は、バリュー・ストリーム・チェーンとそのボトルネックを可視化して、生産性を高めるソフトウェアです。その解説記事 Bottlenecks in the Value Stream の翻訳版です。


バリューストリームにおけるボトルネック

2020年7月29日

著者: Matthew Steele / Data Scientist

画像の説明

さて、バリュー・ストリーム管理システムがすべてセットアップされたとしましょう。あなたはモニター画面を通して、アイデアの創造から、それが組織から価値を提供する瞬間までを追跡しています。つまり、バリュー・ストリーム・メトリクスを監視しているのです。なんと素晴らしいことでしょう!

では、次は何をしますか?次は、バリューストリームのボトルネックを見つけてください。この記事では、バリュー・ストリームのボトルネックについて考察し、ボトルネックがバリュー・ストリームから効率性を奪う前に、HCL Accelerate を使用して、ボトルネックの出現を検出して緩和する方法を説明します。

なぜボトルネックを追跡するのか

バリューストリーム管理の取り組みから利益を得る最善の方法の1つは、バリューストリームのワークフローのボトルネックを見つけることです。 ボトルネックは、整備されたソフトウェア開発マシンから効率を奪います。バリューストリームのボトルネックを特定して修正することで、プロセスやワークフローの不調や非効率を、多額のコストが発生する前に回避または排除することができます。幸いなことに、HCL Accelerate のようなバリューストリーム管理ツールは、ボトルネックを発見するために必要なデータと、ボトルネックの効率性を損なう結果を回避するためのインテリジェントなモニタリング機能の両方を提供します。

ボトルネックとは

少し形式的な話をしましょう。ボトルネックとは、システムのグローバルなスループットを制限するローカルスループットの制限です。言い換えれば、バリューストリームは、バリューストリームの中で最も制約を受けている部分よりも、与えられた時間内に多くの作業を処理することができません。均一なワークロード(すべてのワークアイテムが同じで、等間隔でシステムに入る)を持つシステムの場合、期待されるスループット(ローカルまたはグローバル)は、期待される処理時間(1 単位のワークを処理するのにかかる時間)に対する処理能力(何個のアイテムを並列に処理できるか)の比にすぎません。このような均一なシステムでは、ボトルネックを見つけるのは簡単です。

キャパシティと予想される処理時間を知ることは、非一様なワークロードでも重要ですが、ボトルネックを見つけるのは実世界のワークロードでは困難です。 ソフトウェア開発のバリューストリーム内のすべての作業が同じように作成されるわけではありません。作業項目によって完了までに必要な作業量が異なり、作業項目には相互に関連した依存関係があり、それらがバリューストリームをどのようにナビゲートするかを決定します。 これらの考慮事項はすべて、キャパシティ/処理時間の分析から明らかになる以上に、一時的なボトルネックを発生させる可能性があります。現実のボトルネックは複雑ですが、幸いなことに、適切なデータがあれば、バリューストリームのボトルネックを発見し、修正し、最終的に防ぐことができます。

ボトルネックを見つけるには

ソフトウェア開発の多くの取り組みと同様に、バリューストリームのボトルネックを発見するための取り組みは、基本的なことを見落とさないように、簡単なことから始めるべきです。バリューストリームのどのプロセスでも、常にリソースが不足していないか?バリューストリームのプロセスの中には、バリューストリームのリードタイムに比べて処理時間が長いものがありませんか?この答えをすでに知っていて、キャパシティと予想される処理時間のボトルネックを積極的に緩和するための手順を持っているかもしれません。もしそうでない場合は、データを入手して、これらのシステム的なボトルネックがバリューストリームを遅らせていないかどうかを確認してください。バリュー・ストリームの各プロセスの段階内時間は?各ステージの平均負荷はどれくらいで、それらの負荷に対応するためにどのようなリソースが使われていますか?幸いなことに、HCL Accelerateは、これらの質問に答えるためのデータだけでなく、容量/処理時間のボトルネックを可視化するためのツールへの自動監視とアラートも提供します。

画像の説明

単純なキャパシティ/処理時間のボトルネックを超えて、プラクティスの方法論によってもたらされるボトルネックに遭遇します。私たちは、グローバルなバリューストリーム効率への影響を考慮せずに、特定のタスクのローカル効率を最大化するために開発手法を選択することがよくあります。例えば、トランザクションのオーバーヘッドとコンテキストの切り替えコストを削減するための一般的なプラクティスの1つは、特定の付加価値の高い作業をバッチで処理することです。バッチ処理は、それが採用されている付加価値作業全体の効率を高めることができますが、下流への継続的な流れを阻害することで、バリューストリームの全体的な効率を低下させる可能性もあります。バッチングプロセスの下流のステージでは、使用率不足と過剰供給が交互に発生し、最適な効率で作業する能力が大幅に低下する可能性があります。なぜなら、ボトルネックは局所的に最適化された付加価値プロセスによって発生する可能性があるため、ボトルネックを発生させているステージのバリュー・ストリーム・メトリクスを見ると、すべてが素晴らしいものに見えるからです。けれども、各ステージのフローパターンと、そのパターンが下流プロセスにどのような影響を与えているかに注目する必要があります。時系列スループットの頻繁なスパイクや谷は、実践方法論によって導入されたボトルネックの主要な指標となります。HCL Accelerate は、すべてのバリューストリームのグローバルおよびローカルのスループットを追跡し、実践方法論がバリューストリームにボトルネックが発生している場合には、ユーザーにアラートを提供します。

次に検討するボトルネックのタイプは、ソフトウェア開発のバリューストリームの特徴的なボトルネックである、不均一な作業負荷のボトルネックです。ソフトウェアでは、すべての作業が同じように作成されるわけではありません。同じウィジェットを製造しているわけではなく、複雑で創造的な作業に従事しているのです。ソフトウェアの仕事には、仕事の複雑さ、開発リソースの要件、価値の流れへの流入に固有の不均一性があります。つまり、バリューストリームのキャパシティと処理時間が完璧にバランスが取れていて、すべての実践方法論がグローバルにもローカルにも最適化されていたとしても、ボトルネックが発生する可能性があり、また発生する可能性があるということです。システムを通る不均一な流れは、個々のステージで定期的にキューを発生させたり、他のステージの作業アイテムを枯渇させたりして、バリュー・ストリームのスループットを低下させます。幸いなことに、バリューストリームのステージ負荷とスループットのボトルネックを注意深く監視することで、不均一なワークロードによって発生するボトルネックを、バリューストリームに大きなコストが発生する前に検出し、緩和することができます。さらに HCL Accelerate は、何を監視すべきかを既に知っており、不均一なワークロードのボトルネックが発生し始めると、ユーザーを検出して警告することができます。

ボトルネックを修正するには

バリューストリームでボトルネックがどのようにしてどこで発生するかを知ることは、ボトルネック緩和の最も困難な部分です。ボトルネックが発見されず、バリューストリームの効率性を奪ってしまうことがあっては、ボトルネックは問題となりません。バリュー・ストリームとワークフローのメトリクスを手動で検査する日常的かつ体系的な方法、または HCL Accelerate が提供するような自動化されたモニターとアラート・システムのいずれかが、ボトルネックの脅威と戦うための最良の前線の武器となります。Once you’ve found the bottlenecks, you’ll likely find the tools for mitigating them are already in your software development toolkit. (訳不明瞭)。

処理時間が長いために、バリューストリームのステージがボトルネックになっていないか?プロセスを自動化または合理化できる部分があるかどうかを確認してください。

1つのステージでのバッチ処理が下流の流れを阻害していませんか?より小さく、より頻繁なバッチを検討するか、またはバッチングをすべて廃止することを検討します。

不均一な作業負荷がバリューストリームに大混乱をもたらしていませんか?チームのスキルセットに柔軟性を持たせることで、コストが発生する前にリソースを再配分してキューをクリアできるようにしましょう。

HCL Accelerate を持っているとがわかります。どこで、なぜ、いつボトルネックが発生するのかを。それを知ることで、効果的な効率性節約の緩和を実践することができます。HCL Accelerate の検出およびアラートシステムがボトルネックを発見することで、お客様のチームは、効率的で効果的な価値の流れの中でソフトウェアを開発することができるようになります。


HCL Accelerate: バリューストリーム管理によるリスクの軽減

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

HCL Accelerate は旧 UrbanCode Velocity という製品で、多種多様なツールを使用する DevOps の現場において価値を高める製品です。具体的には、可視性の向上、ボトルネックの特定、DevOps の有効性測定により、リスクを軽減して、チームが変革を推進し、より良い意思決定を行えるよう支援します。さらに、組織全体の DevOps フローの改善により DevOps への投資効果を最大化します。

「バリューストリーム管理」は聞き慣れない言葉かもしれませんが、付加価値を高めていく上で非常に重要な視点です。これについて書かれた英語版ブログ Mitigating Risk with Value Stream Management の翻訳版です。


バリューストリーム管理によるリスクの軽減

2020年7月27日

著者: Bryant Schuck / Product Manager for HCL Software DevOps

画像の説明

今年はパンデミックの影響で、家族で休暇を取ることにしましたが、飛行機ではなく車で行くことにしました。他の大切なことのほとんどと同じように、どこにどのくらいの期間行くのか、そして何をして家族で仲良く過ごすのかについて考えるのに多くの時間を費やし、ノースカロライナ州の島へ行くことを決めました。マップアプリは所要時間が 10.5時間 と、非常に合理的な時間を示したのに対して、。私は12-15時間かかると考えておく必要があることを妻に話しましたが、妻は 11 時間でいいだろうと言い張りました。しかし実際には 15 時間もかかってしまい、フラストレーションと失望で終わったのでした。何が起こったのでしょうか?10.5時間よりも15時間前後になるだろうと予測できたでしょうか。1 歳未満の赤ちゃんがいること、人気のあるバケーションスポットに向かって海岸沿いをドライブしていたこと、出発時間が正確ではなかったこと、事故や交通渋滞で遅れてしまったこと、などなど。Googleマップ上で時間を確認する場合, 旅行時間は、その日のその時間帯における各エリアのトラフィックパターンを考慮に入れる必要があります。

画像の説明

私たちはソフトウェアでも同じような問題に遭遇します。アジャイルや類似の方法論が人気の理由は、リスクの少ない小さな時間単位でリスクを減らそうとしているからです。上の私の休暇の例えを使うと、10 分のドライブは 10 時間のドライブよりもずっとリスクが少ないのです。

ソフトウェアのライフサイクルは開発だけではありません。そこで、アイデアから価値に至るまでのリスクを軽減するために、バリュー・ストリーム・マネジメントの出番です。私たちは皆、なぜ機能 X は失敗したが、コードは完成したのだろうかと疑問に思う会議に参加したことがあります。品質、セキュリティ、コードカバレッジなどに問題があったのかもしれませんが、何らかの理由で、そのアイテムを顧客に展開するにはリスクが大きすぎたのです。当社のバリュー・ストリーム管理プラットフォームである HCL Accelerate は、ソフトウェアの所要時間に関するすべてのメトリクスを可視化し、チームのアウトプットをより予測可能なものにすることで、リスクを管理することを可能にします。

HCL Accelerate を使用することで、ビジネスは新機能を要求することができ、技術チームはリスクについてより良い予測をすることができます。例えば、リードタイムが 25 日であるチームの例を見てみましょう。チームは、コードの品質が平均以上であること、セキュリティスキャンが自動的に実行されていること、そしてすべてのメトリクスが、これが与えられた範囲内で妥当なコミットであることを示していることを確認することができます。さて、もしその機能が平均よりも低いコードカバレッジを持ち、セキュリティスキャンをサードパーティに送る必要があり、ビルドに欠陥があるアプリケーションにあったとしたら、チームはリスクのためにその機能のための期間を長くすることを要求しなければならないかもしれません。

重要なのは、会話をしたり、リスクを管理したりできるように、すべての情報を手元に置いておくことです。もはや「コードが完成した」ということだけではありません。重要なのは、「顧客に価値を提供できたかどうか」ということです。私たちのツールとプロセスは、このような考え方にマッチしていなければなりません。それが、HCL Accelerate が単なるマッピングだけではなく、アイデアから価値への道のりについてのものであり、チームが関連するすべてのデータを克服し、より良い統一性を持つことができるように支援します。

HCL Accelerate を無料でダウンロードして、バリュー・ストリーム・パイプラインの構築を今すぐ始めてみてはいかがでしょうか。


HCL Accelerate はどのようにしてオープンソースツールをより良いものにするのか

2020/7/21 - 読み終える時間: ~1 分

How does HCL Accelerate make open source better? の翻訳版です。

HCL Accelerate はどのようにしてオープンソースツールをより良いものにするのか

2020年7月20日

著者: Bryant Schuck / Product Manager for HCL Software DevOps

画像の説明

皆様が、使い慣れたソフトウェアが好きであることや、オープンソースツールを使用してきた長い歴史を持つ企業の方であることを、HCL Software は理解しています。しかし、HCL Software は、お客様の仕事をより簡単にし、チームをより協調的にすることができるのではないかと考えています。HCL Software DevOps ソリューションは、現在お使いの開発ソフトウェアのエコシステムとして補完することができます。オープンソースのツールをより良くするにはどうすればいいのでしょうか?ガバナンス、可視性、エンタープライズ・スケールなど、より速く実行し、より大きく成長するために必要な要素を追加します。

HCL Software の究極の追跡・確認ツールである HCL Accelerate を、お客様の DevOps エコシステムの上に配置することで、これまでにないほどの洞察力とガバナンスが得られます。ツールチェーンに何があるか、オープンソースであるかどうかに関係なく、HCL Accelerate は、これまでにないほどの洞察力とガバナンスを提供します。HCL Accelerate は、ボトルネックを発見し、チームを改善し、ビジネス価値を高めるために必要なメトリクスを提供します。

カスタム・プラグインを加速する HCL Accelerate の主な利点は、すべての DevOps ツールからのデータを集約するため、使用しているツールにあまり詳しくない関係者でもパイプラインを簡単に解釈できることです。例えば、Jenkins を使用している開発者であれば、そのツールの使い方を熟知しています。しかし、Jenkins はオープンソースであるため、あまり洗練された UI を持っておらず、管理者が必要な情報を掘り下げて見つけるのは容易ではありません。HCL Accelerate は、オープンソースのツールに慣れていない人のために、単一のビューでデータを分析するためのユーザーフレンドリーなレイヤーを提供します。

オープンソースは非常にニッチなアプリケーションであり、コスト節約の面ではとても素晴らしいものです。しかし、オープンソースは、セキュリティやサポートなどの重要な要素を見逃しがちです。HCL Accelerate は、オープンソースツール全体にガバナンス、コンプライアンス、およびレポートを追加することで、このギャップを埋めることができます。リリースオーケストレーションやインテリジェントゲーティングなどの機能を備えた HCL Accelerateは、オープンソースツールの操り人形的な役割を果たします。たとえば、HCL Accelerate を使用して、Jenkins で安全にゲーティングされたリリースを設定することができるので、誤って何かを早期にリリースしたり、間違ったビルドをリリースしたりすることがなくなります。セキュリティ機能を追加し、パイプラインデータを1つのビューにまとめることで、HCL Accelerate はチームに最適なツールを自由に使用できるようにします。

HCL Software は、ソフトウェアデリバリツールへの「リッピング&リプレース (全面的な取り替え)」アプローチが必ずしも理想的ではないことを知っています。しかし、組織の成長にはアップグレードが必要です。そのため、HCL Accelerate は既存のツールセットと統合できるように構築されているため、チームに最適なツールを自由に使用できるようになり、同時に主要な利害関係者に可視性とセキュリティを提供することができます。無料のコミュニティ版で HCL Accelerate をお試しください。


About

HCL Japan の Software 部門の複数担当者で HCL Software 全般について記しています。