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/22 - 読み終える時間: 2 分

HCL Accelerate はボトルネックを特定するツールですが、その前提として、あらゆる工程を追跡する機能を持っています。その特長について記した記事 Your item tracking tools aren't enough. Here's why の翻訳版です。

あなたがお使いのアイテム追跡ツールだけでは不十分な理由

2020年8月21日

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

スクラムボードのようなアイテムトラッキングツールについてどう思うか、開発者やチームリーダーに聞いてみると、否定的な答えが返ってくるでしょう。ほとんどの開発チームが使用しているトラッキングツールは、必要悪とみなされたり、貴重な仕事を成し遂げるための障害物とみなされたりします。スクラムボードは常に時代遅れで、開発者だけが知っている微妙な情報があり、ボード上では簡単には伝えられません。スクラムボードは手作業であるため、いくら状態やカラムを作成しても、情報には常にわずかな矛盾があります。

Jira のような作業項目追跡ツールは、プロジェクトの初期計画のために最低限の要件を収集し、チームの作業項目のバックログを構築するという目的には最適です。これらのトラッキングツールがバラバラになり始めるのは、作業が最初の計画段階から進行中の段階に移ったときです。この時点で、多くのチームはスクラムボードやカンバンボードを使用して、作業アイテムがパイプラインのどこにあるかのステータスを追跡しています。これでは、たくさんの列がある乱雑なボードになってしまい、開発者は自分のワークアイテムカードが正しい位置にあるかどうかを確認するために、多くの手作業や退屈な作業をしなければならなくなる可能性があります。その結果、ボードを整理したり、カードが正しい位置にあるかどうかを確認したりするために、無駄な時間を使ってステータスミーティングを行うことになります。ボードが常に正確でないと、本来の価値を失い、管理者は計画を立てるためにボードを頼りにすることができなくなります。そうなると、管理者は開発者を困らせ、状況の更新を求めて開発者に直接連絡を取るようになります。

Standups は、開発者がスプリントを成功裏に完了させるために何をすべきかを知るための方法ではなく、管理者のためのステータスミーティングになってしまっているのです。ミーティングは、ステータスレポートの更新ではなく、価値を高めるためのものでなければなりません。では、なぜステータス ミーティングで時間を無駄にしているのでしょうか？それは、作業を追跡するために使用しているツールが、実際にはより多くの作業を生み出しているからです。

複数のツールにまたがって DevOps データの集計を開始すると、ステータスミーティングの必要性がなくなります。これがまさに、バリューストリーム管理ツールである HCL Accelerate が行うものです。 開発者から手動で入力することなく、チーム全体のすべての作業項目の誰、何、いつ、どこにいるかを明確に示す、常に最新のライブバリューストリームにすべてのデータをまとめます。

HCL Accelerate は、すでに使用しているすべてのツールからデータを集約するので、手動でのステータス更新に別れを告げることができます。

ステータスチェックの必要性がなくなると、最初の大きな成果は、立ち見のミーティングの時間を取り戻すことです。価値を生み出す本当の仕事にすぐに集中し、開発者が仕事を完了させるために直面している障害に対処し始めることができます。スタンドアップ ミーティングでの会話は、「これは正しいデータか」から「どうすればチームの進歩に貢献できるか」へと変化します。さらに良いことに、「カードを作るのを忘れてしまった」という話を二度と聞く必要がありません。 DevOps パイプライン内のすべてのツールからデータが集約されているので、Jiraの問題、ServiceNowのチケット、またはGitHubの不正なプルリクエストから来る予定外の作業によるサプライズを心配する必要はありません。

HCL Accelerate は手動入力に頼るのではなく自動化されているため、正確なステージ完了データを得ることができ、パフォーマンスの高いチームを特定したり、ボトルネックをクリアしたりすることができます。開発者にとっては、これは管理作業を減らし、パイプラインに直接影響を与えるタスクでのマネージャーのサポートを増やすことを意味します。管理者にとっては、信頼できるデータ、可視性の向上、より正確な計画の策定を意味します。

しかし、開発者は新しいツールへの切り替えを嫌がり、使用しているアイテムトラッキングソフトウェアの周りにはすでにプロセスがあります。私たちはそれを理解しています。しかし、HCL Accelerate は、リッピング＆リプレース型のソフトウェアではありません。Jira、GitHub、Jenkinsなどの使い慣れたツールを使い続けることができ、HCL Accelerate はデータを掬い上げて、価値の流れの真実の単一ソースを提供します。プロジェクトの全体像をまとめるためにツールからツールに切り替える時代は終わりました。HCL Accelerate は、ツール間、チーム間、職務間のギャップを埋めます。

HCL Accelerateの「スイムレーン」ビューでは、作業項目がどこにあるのか、どのチームメンバーにサポートが必要なのかを明確に把握することができます。

すべてのソフトウェア企業は、競争の一歩先を行き、より多くの価値を生み出す方法を探しています。しかし、パイプラインがつながっていなければ、データや手動プロセスのギャップを埋めようとすることで、常に不利な状況に陥ってしまいます。HCL Accelerate は、ワークアイテムのトラッキングと KPI 測定を自動化し、チームがこれまで以上に機能するようにします。競争上の優位性はどうでしょうか？

自動化されていない限り、誰もデータを信じません。開発者と管理者の両方にとって、HCL Accelerate は、より良い意思決定のための正確でライブなデータにより、仕事を楽にします。無料の HCL Accelerate Community Edition で今すぐ始めましょう。

2020/8/22 - 読み終える時間: 9 分

今回は Jira と GitHub の活動を統合して見える化する内容 HCL Accelerate VSM with GitHub and Jira の翻訳版です。

GitHub と Jira と組み合わせた HCL Accelerate Value Stream Management

2020年8月20日

著者: Daniel Trowbridge / Technical Lead

このチュートリアルでは、HCL Accelerate で GitHub 統合を作成する方法を説明します。これは、Jira、GitHub 、Jenkins を使用して HCL Accelerateのバリューストリームを設定し、使用するチュートリアルシリーズの第2部です。一部のバリューストリームのステップは、Jiraチュートリアルの完了を前提としています。Jiraチュートリアルを完了していない場合は、ここで完了できます。

1. GitHub リポジトリを設定する

GitHub の要件は以下のとおりです。

• GitHub リポジトリへのアクセス (このワークブックでは公開リポジトリを想定しています)
• GitHub API トークン
• プルリクエスト (PR) を作成する機能。

このワークブックは、公開 GitHub アカウントと公開リポジトリを前提としています。公開 GitHub アカウントを持っていない場合は、公開リポジトリと同様に作成する必要があります。リポジトリの内容は重要ではありませんが、PRが必要で、PR名には、フォローするJira課題の課題IDが含まれていなければなりません（ここでの例は"JKET-1"）。

2. GitHub インテグレーションを作成する

注: GitHub プラグインの設定はバージョン 1.0.31 から変更されました。バージョン1.0.31 以降では、URL フィールドは必要ありませんが、下記のステップ 9 のようにユーザーアクセスキーが必要になります。

• HCL Accelerateのプラグインページ（設定＞統合＞プラグイン）から統合を追加できます。

• このワークブックの統合名は「JKE GitHub App1」としてください。

• GitHub のURLはリポジトリへのURLにしてください (プラグインのバージョン1.0.31以降では必要ありません)

• GitHub リポジトリ URL から「名前」（リポジトリ名）および「所有者」（リポジトリアカウント）フィールドを取得できます。

• API URLは GitHub のインスタンスに依存します。このワークブックでは、"https://api.github.com" を使用する GitHub のパブリックインスタンスを想定しています。

• リポジトリにアクセスできるアカウント用の GitHub パーソナルアクセストークンを作成し、そのトークンをコピーして統合フォームに貼り付けます。GitHub の公開トークンは https://github.com/settings/tokens で作成できます。トークンを作成する際に、「スコープ/権限」のチェックボックスを選択する必要はありません。

• 追加」ボタンをクリックして統合を作成します。統合」ビューに移動して、統合が作成され、「オンライン」になっていることを確認します。ドロップダウンを展開して、統合の詳細を確認できます。(以下に示す Jira 統合は、別の演習の一部として作成されたことに注意してください)

• 統合名の横にある青い点は、アップグレードが可能であることを示しています。この時点でプラグインをアップグレードしておくと良いでしょう。三角点（カボブ）メニューの下にある「アップグレード」をクリックします。プラグインイメージが最新バージョン（1.0.36以降）に更新されるはずです。

• ユーザーアクセスキー（ GitHub プラグインのバージョン1.0.31以降。

1. GitHub プラグインのバージョン1.0.31以降では、HCL Accelerateユーザーアクセスキーが必要です。URLフィールドも削除されました。1.0.31以前のバージョンからのアップデートでは、ユーザー・アクセス・キーとの統合を編集する必要があります。

2. アクセスキーを作成するには、「設定」→「マイプロフィール」で「作成」をクリックします。アクセスキーを作成するには、「設定」→「マイプロファイル」→「作成」をクリックします。アクセスキーの名前は、それを使用する統合に合わせて、「JKE GitHub App1」のような名前にするのが良いでしょう。この時点でキーをコピーしておくと後でコピーできなくなるので、必ずコピーしておきましょう。

3. キーを作成したら、統合ページに戻ります。GitHub 統合の kabob メニューから「編集」をクリックします。フォームにユーザーアクセスキーを入力します。

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

vsm.json ファイルを使って、GitHub 統合と linkRule を値のストリームに追加します。ファイルをダウンロードして、以下のセクションを追加して修正し、再度ファイルをアップロードして変更を適用します。PR が開いているので、作業項目 (ドット) は"In Progress" ステージに移動するはずです。PR またはコミットが作業項目に正しくリンクされていない場合、四角（PR）または三角（コミット）として表示されますが、ドットはリンクされたすべての PR とコミットを含む実際の作業項目を表します。1つの作業項目に複数のPRをリンクできます。PR ブランチへのコミットは、ワークアイテムを更新します。

注: この時点から、いくつかのステップでは、Jira チュートリアルを使用して VSM を事前に完了していることを前提としています。チュートリアルをまだ終えていない場合は、今すぐ完了させるか、Jira との統合を行わずに先に進んでください。GitHub は統合されて PR やコミットを表示できます。しかし、イシュートラッカーの統合とそれに対応するリンクルールがなければ、作業項目のリンクはできません。以下のように vsm.json ファイルを編集して GitHub との連携を含めることに加えて、ステージクエリを編集する必要があります。

"query":"pr.status=open".

1. 作業用の vsm.json ファイルを値ストリームからダウンロードします。

2. GitHub 統合を .json コンテンツに追加します。

別のチュートリアルでJiraの統合を追加するために使用したjsonと同様に、もう一つのjsonオブジェクトを統合配列に追加する必要があります。ここでの名前は、先ほど作成した GitHub 統合の名前と一致させなければなりません。今のところ必要なのは、GitHub オブジェクトをシングルネームプロパティで追加するだけです。vsm.json に Jira のような他の統合が含まれている場合は、無視しても構いません。

"integrations". [
 {
* 名前":"JKE GitHub App1"
 }
 //その他の統合...
],

3. vsm.json の設定に GitHub -Jira の linkRule を追加します。

空のリンクルールの配列を置き換える...

"linkRules". [],

に新しいリンクルールオブジェクトを含む配列を指定します。この linkRule は、pr.name の中の jira.id を認識する正規表現パターンに基づいて GitHub の PR と Jira の課題をリンクします。

"linkRules". [
 {
* fromIntegrationName"。"JKE GitHub App1".
* toIntegrationName"。"JKE Jira 1".
*"fromField"."pr.name":"pr.name
*"toField"."issue.id":"issue.id
*"パターン"です。"([A-Z]+-[0-9]+)"
 }
],

4. vsm.jsonファイルを保存してアップロードします。

四角が見えますか？

GitHub の活動にもよりますが、"Merged" のようなステージにいくつかの四角が表示されていることに気づくかもしれません。これは、Jira カードにリンクされていない以前のコミットを表しています。私たちは新しい PR を作成して Jira カードにリンクさせることに焦点を当てているので、このような四角が表示されても無視して構いません。

4. Jiraと GitHub を使ったステージ変更

さて、GitHub をインテグレーションとして設定したところで、次はバリューストリームの中で GitHub を実際に使ってみましょう。GitHub はスタンドアロンの統合として使うこともできますし、さまざまな統合と一緒に使うこともできます。ここでは、Jira チュートリアルの VSM を使用していることに注意してください。

4.1 ドットを「進行中 (In Progress)」に移動する（PRを作成する)

ドットを「進行中」の段階に移動させるには、GitHub でプルリクエスト（PR）を作成する必要があります。

• リポジトリ内の任意のファイルを編集します。この例では、ファイルの右上にある鉛筆のアイコンをクリックして編集できる、README ファイルを編集しています。

• ファイルに変更を加えます。これらの変更は、以前に作成した Jira カードに対応するものと考えてください。これは、そのカードのコード変更を表しています。

• 変更を別のブランチにコミットします。コミットメッセージとブランチ名は好きなように設定できます。

• プルリクエストを作成するように促されたら、プルリクエスト名に Jira カードの ID/コード (例："JKET-1") を入力し、"Create pull request" をクリックします。

• プルリクエストがオープンで、JiraカードのIDが含まれていることを確認します。

• HCL Accelerateが検出して更新されるのを待った後、「進行中」の段階でドットが表示されるはずです。

4.2 ドットを「レビュー中 "In Review"」に移動する

• Jiraカードを"In Review"に更新してください。
• HCL Accelerateが更新されるのを待ちます。ドットが "In Progress" から "In Review" に移動するはずです。

4.3 ドットを「マージ済み (Merged)」に移動する

• 先に進み、GitHub で PR をマージします。

• HCL Accelerateがアップデートされるのを待ちます。ドットが"In Review"から"Merged"に移動するはずです。

次のステップへ。開発からサーバー構築、そしてその先へ

Wow! Jiraと GitHub の両方の活動が、HCL Accelerateで一つの真実のソースになるのを目の当たりにしています。次のステップは、ビルドとデプロイメントを統合して、本番まで作業項目を追跡することです。そのためには、Jenkins との統合を作成する必要があります。

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

Design Sprint? It's all the rage, but will it work for your team?

Design Sprint? 流行っていますが、あなたのチームには効果があるでしょうか？

2020年8月19日

著者: Ben Vance / UI Designer for HCL Software DevOps

バックストーリー(生い立ち、これまでのこと)。どのようにしてここまで来たのか？

率直に言います。

COVID-19 パンデミックとワーク・フロム・ホームの「ニューノーマル」の始まりに際し、私たちはかなり大きな設計プロセスの失敗をしました。設計に1ヶ月もかからないはずの新機能が、3ヶ月近くもかかってしまいました...最終設計はかなり最初の設計に近いものになってしまいました。全員がオフィスにいたとしても、非効率なことは起きていたでしょうが、リモートであることが問題をさらに悪化させ、そのうちのいくつかの問題が発生しました。

• プロジェクトの開始時に明確な要件がなかったこと
• 最初のミーティングにキーパーソンがいないこと
• プロセスを通して新しい人を連れてくる
• 会議の間隔が長い

では、それぞれの問題を詳しく見ていきましょう

• 私たちが始めたとき、「成功」とは何を意味するのか、明確な考えがありませんでした。さらに悪いことに、誰もが「成功」の意味するところが違っていました。だからデザイナーとして、私たちは動き続ける的中率の矢を暗闇の中で撃っていました。私たちは、ある用語が実際に何を意味するのかを定義し、再定義することに何時間も費やしました。
• 私たちは、ビジネスの "上の方 "にいる数人の主要なステークホルダーからプロセスを始めました。私たちは、彼らの考えと賛同を得ることで、デザイナーがまとめたソリューションを実装するために開発者を引き入れることができると考えました。問題は、開発者がそれぞれの考えを持っていたこと、さらに重要なことは、以前に設計された製品からの洞察を含めて、製品がどのように機能するべきかについての異なる洞察を持っていたことでした。
• 開発者を引っ張っていくと、追加の質問やポイントが出てきて、それを主要な利害関係者のところに持ち帰らなければならないことがわかりました。私たちは、各段階で追加の開発者を入れ続けることで、この問題をさらに悪化させてしまいました。これは結局、一連の循環型の議論を生み出し、タイムラインをさらに悪化させ続けました。
• 最終的には、会議やデザインレビューの間に時間がかかりすぎてしまいました。デザインの更新は1日で終わるのに、チームでレビューするのに1週間も待たされていました。これがリモートワークの一番の弊害だと思います。オフィスでは、即興のフィードバックを得るために人の肩を叩いていました。リモートで仕事をしていると、会議のスケジュールを組んだり、かなり忙しいスケジュールの中で仕事をしたりしなければなりませんでした。

だから、解決策は？全く逆のことをして、次のデザイン機能を1週間以内に完成させよう。何がいけないのでしょうか？

Design Sprint。それはまさにプロセスなり

私たちはリモートで仕事をしていたので、在宅勤務の方針に合わせて Design Sprint の方法論を少し修正しなければなりませんでした。

• すべての会議は、会議室で個人的に行うのではなく、GoToMeeting を介して行われます。
• このデザインを素早く把握するために部屋に入る必要があるキープレイヤーを把握する。私たちは、デザイナー、開発者リード、開発者のミックスに着地しました。我々はまた、日進月歩のレビューを与えるために、"上の人 "とのいくつかのフォローアップミーティングを持つことを決めました。
• チームメンバーを選ぶことで、その人たちがチームの残りの部分を代表して話すことを明確にしました。会社全体をまとめて100%の合意を得ることは不可能でしょう。ある時点では、チームのリーダーは他の人にコントロールを委譲しなければならないでしょう。
• 公式の」 Design Sprint の方法論に従って、チームはこのプロセスに40時間を費やす必要があります。現在進行中の作業と、これが「ベータ版」の取り組みであるという事実を考えると、この機能を完成させるためには1日90分という時間が必要になります。
• デザインチームは、毎日達成したいことを網羅したアウトラインをまとめました（※脚注やスケジュールのスクリーンショットを追加してください）。
• 公式な方法論を確認しましたが、私たちのためにプロセスをかなり自由にしました。

結果はどうだったか

手短に言うと...本当によくできました。

• 開発者は、設計プロセスにもっと参加したいという希望を表明しています。 Design Sprint では、初日から自分たちの考えを表現することができました。また、このプロセスでは、彼らが考えていた解決策をスケッチし、デザインする機会を与えてくれました...それがペンと紙であっても、シンプルなパワーポイントであっても。

• 私たちは、バーチャルホワイトボードとして壁画ソフトを利用することにしました。これは、ブレインストーミング中に全員が自分の考えをタイプしたり、さらに発展したものを見たいと思った項目を「スターリング」したりすることができるようにするための素晴らしい決断であったと思います。一週間を通して、グループは初日のメモやスケッチを参照し続けました。

• 1日目は予定より遅れてしまいました。1日90分というのは、このプロセスを始めるにあたり、私が一番恐れていたことでした。私は、会議がどれだけすぐに逸脱してしまうかを知っているので、簡単に1時間を失ってしまうことになります。私たちは、このような議論をできるだけ早く終わらせるように心がけていましたが、実際にはそうなってしまいました。

次回は何をするか

Design Sprint は成功しましたが、プロセスを改善するために変更できることがいくつかあります。

• 毎日、より多くの時間を割くこと。1日90分だけでは、全員の考えを完全に具現化するには十分な時間ではありませんでした。
• 理想的には、ホワイトボードやポストイット、目と目が合うような形で、直接会って行うのが良いでしょう。電話でできる限りのことはしましたが、やはり対面でのフィードバックが理想です。
• プロトタイプのフィードバックをしてくれる時間を割いてくれる顧客の具体的なグループを持っている。

まとめ

これはあなたのチームでも当てはまることなのでしょうか？私はそう思います。

HCL Software DevOps では、非常に意見の多いチームがあり、彼らの声を聞きたいと思っています。このプロセスは、それを可能にしてくれました。全員が自分たちが取り組んでいることに興奮し、エンドツーエンドのプロセスに手を貸したと感じたとき、製品は恩恵を受けることができます。それを実現するためには、日々の仕事に追われていると感じないように、時間を割き、チームに必要なリソースを与えなければなりません。しかし、最終的には、テスト可能な具体的な成果物プロトタイプができあがります...1週間の作業も悪くありません。

HCL Accelerate は、チームが世界中に分散している場合でも、オフィスで一緒に作業している場合でも、スプリントを成功させるためのお手伝いをします。チームメンバーごとに作業を整理するスイムレーンのような機能や、すでに使用しているツールと統合する機能を備えた HCL Accelerateは、DevOps パイプラインの測定、トラッキング、最適化をこれまで以上に容易にします。ここから無料でダウンロードしてください。

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

ニューノーマルを見据えた DevOps の取り組みの重要性について説いた Leading the Transformation with DevOps の翻訳版です。

DevOps で変革を導く

2020年8月17日

著者: Elise Yahner / HCL

ここ数年、あらゆる規模の組織でデジタルトランスフォーメーションが行われていますが、多くの企業ではそのプロセスが十分に速く動いているとは言えません。DevOps はどのようにしてデジタルトランスフォーメーションの速度とインパクトを向上させることができるのでしょうか？DevOps.com のエキスパートが、新しいeBook「How DevOps Leads the Way to Digital Business Transformation」でそれについて深く掘り下げています。

このeBookでは、ITエグゼクティブや技術リーダーからの洞察をもとに、最新のデジタル・ビジネス・アプリケーションの構築と展開を加速させる唯一の方法は、最高のDevOpsプラクティスを採用することであると主張しています。もちろん、それは言うは易く行うは難しであり、特にCOVID時代のリモートワークで直面した新たな課題など、DevOps の採用にはいくつかの障害があります。

HCL Software の DevOps 戦略担当ディレクターであるブライアン・ムスコフ氏は、「DevOpsの変革を成功させるための第一の障害は、組織の変化です。結局のところ、自動化とプロセスの改善は簡単なことです。何年も同じように運用してきたチームや個人の行動を変えることが真の課題です」と述べています。

DevOps.com は、業界の専門家を招いたパネル・ウェビナーで DevOpsの 変革についての話を続けました。HCL Software の DevOps アドバイザリー＆採用担当ディレクターである Chris Nowak 氏は、変革の文化をサポートするために適切な人材を雇用することの重要性を指摘しました。

「カリスマ性のある一人の人間だけではなく、それ以上の人間を中心にトランスフォーメーションを構築することが本当に重要です。リーダーシップと説明責任を外注することはできません。それはうまくいきません。どちらかといえば、インソースすることです。専門家に頼ったり、コンサルタントを雇ったり、人材を雇ったりするのです。常に人材と才能が重要なのです」と彼は語っています。

DevOpsトランスフォーメーションの重要なポイント

心に刻んでおくべきこと

• DevOpsの採用は、デジタルビジネスが "ニューノーマル "に突入する中で、成功するか、単に生き残るかの違いを分ける鍵となります。
• セキュリティは、デジタルトランスフォーメーションを成功させるための最重要事項ですが、テクノロジーを活用した新しい取り組みのうち、最初からセキュリティチームを含むものは、わずか3分の1にすぎません。
• ビジネスリーダーのサポートがなければ、デジタルビジネスの取り組みは失敗する可能性が高くなります。
• デジタル・ビジネス・アプリケーションを構築・展開するためにマイクロサービスをうまく取り入れることができれば、競争上の優位性は格段に高まります。

チームを編成したら、チームの全員にデジタルトランスフォーメーションが彼らにとってどのような意味を持つのか、個人的にも組織の一員としても透明性を持たせる必要があります。

「組織の DevOps トランスフォーメーションの背後にある「なぜ」を伝えましょう。デジタルトランスフォーメーションの中で、自分たちがどのようにビジネスの目標に沿っているかを理解してもらいましょう。その結果、透明性が高まり、コミュニケーションが向上します。彼らに理由を与え、境界線を与え、そこに到達できるように支援してください」と Nowak 氏は語ります。

これらはすべて、DevOps の変革はチームの努力であり、一人で行うものではないという考えを裏付けるものであり、顧客に焦点を当てたミッションであるということを示しています。

「私たちは、本番の境界線を超えて考え始めなければなりません。価値とは、それを製品化することではなく、製品化した後に誰かが喜んで製品を使用することです。まだ始まったばかりにもかかわらず、私たちは、製品化までたどり着いたということで、自分たちの旅を限定しています」と、Nowak 氏は説明します。

DevOps.com の eBook で、デジタルトランスフォーメーションを推進するための詳細な洞察とアドバイスを得ることができます。お客様の組織に合わせたマンツーマンのアドバイスをご希望の場合は、ここをクリックして、Chris Nowak 氏の無料戦略セッションをリクエストしてください。

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

HCL Accelerate の一連の解説記事の続きです。英語版ブログの記事 Tracking value stream data from issue to deployment の翻訳版です。

課題から展開までのバリュー・ストリーム・データのトラッキング

2020年8月14日

著者: Andrew Clavin / Software Engineer

課題のアクティブなスプリントや最新のレビューコメントから、ビルドの通過テストやコンポーネントのバージョンに至るまで、HCL Accelerate を使用して追跡・分析するデータは無限にあります。すべてのデータは、私たちのDevOpsの旅のより深い理解に役立ちますが、時には、特定のタスクにどのデータと関係を持たせる必要があるのかを知ることが課題になることもあります。この記事では、典型的なエンド・ツー・エンドのバリュー・ストリームのフローにおいて、どの部分が最も重要なのかをゼロにして、作業アイテムが最初のステージから最後のステージに移るのを見られるようにしたいと思います。これが終われば、トラッキングツールの課題が、典型的なバリューストリームの環境のステージで構築、デプロイ、トラッキングされたパーティクルにリンクするまでに何が必要なのかを概念的に理解できるようになります。

まず、典型的なバリュー・ストリームにはどのようなものが含まれるのかを説明します。バリューストリームが初めての方で、「そもそもバリューストリームを初期化するにはどうすればいいのか」などの質問がある場合は、HCL Accelerate のチュートリアルビデオをご覧になるか、1対1のデモをリクエストしてください。基本的な設定ができたら、統合のどのようなプロパティがバリュー・ストリームを介した作業項目の移動を促進するのかについての詳細を学びに来てください。

一般的なバリューストリームには、次のようなステージがあります。バックログ、開発のために選択された、進行中、レビュー中、マージ済み、ビルド、開発、QA、および開発。1つのバリューストリームから別のバリューストリームまで、多くの違いがあると思われますが、計画段階（Backlog および Selected For Development）、開発段階（In Progress、In Review、Merged、Built）、およびデプロイメント段階（Dev、QA、および Prod）の基本的な考え方をここでは、Accelerate が DevOps プロセスをより目に見える形で定量化するために、ビルドとデプロイメントを計画項目にリンクさせる特性をエンドツーエンドで説明する方法で表現しています。

具体的なバリューストリームの関係に飛び込む前に、何を扱っているかの大まかな概要を把握しておきましょう。

最も基本的なレベルでは、Issue、Builds、Deployments があります。課題は様々なコミットで作業され、プルリクエストにマージされます。ある時点で、これらのコミットはビルドされ、バージョンが与えられます。バージョンが与えられたビルドが環境に投入されると、デプロイメントが発生します。では、これらの関係と、それらに関連するプロパティを見ていきましょう。

• issue - issue は値の流れの出発点であり、通常は BacklogとSelected For Development のステージで見られます。コミットと PR の関連付けルールにより、コミットとプルリクエスト（両方ともソース・コントロール・ツールから）にリンクされます。

  • プルリクエストとは - プルリクエスト (PR) は通常、レビュー中の段階で情報を提供します。デプロイメントに向けて課題を関連付けることはありませんが、バリューストリームのいくつかのステージに関連している可能性があります。プルリクエストには、プルリクエストのコードに関連するコミットを参照するプロパティが含まれています。

  • コミット - コミット・データ・オブジェクトには、関連する PR id と同様に、その issue の id への参照が格納されます。

• ビルド - ビルドは、そのビルドのコードに新しく追加された関連するすべてのissue、コミット、および PR への id による参照を含んで保存されます。

  • バージョン - バージョンには、前述のすべてのオブジェクトへの参照が格納されますが、デプロイメントへの参照は保持されません。

• デプロイメント - デプロイメントは、ビルドに関連するバージョン名を持っています。また、重要なことに、バリューストリームのパイプライン上のアプリケーションに応答するアプリケーション ID と環境 ID、およびアプリケーションがデプロイされるパイプラインの環境ステージ (関連するバージョン) を持っています。

これで、HCL Accelerate Value Stream フローを構成するものについて深く掘り下げてみましたが、Accelerate を使用してDevOpsの実践からさらに多くの成果を得る準備ができたことを願っています。プロセスについて知れば知るほど、プロセスをより効率的にできます。ですから、私たちが使用しているプロセスをより詳しく知ることで、効率性を高めることさえできるかもしれません。

HCL Accelerate は、無料の Community Editionで今すぐご利用いただけます。こちらから入手できます。

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

2. 先ほど作成した .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

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

Jenkins と HCL Accelerate を組み合わせて運用する手順を記した英語版ブログの記事 Creating a Jenkins Integration with HCL Accelerate の日本語版です。

HCL Accelerate と Jenkins との統合構成

2020年8月11日

著者: Daniel Trowbridge / Technical Lead

HCL Accelerate のバリューストリームには、Jenkins からのビルドデータとデプロイデータを含めることができます。これ以外にも、Jenkins の統合を HCL Accelerate パイプラインと組み合わせて使用することで、ビルドとデプロイメントを HCL Accelerate から直接実行し、さらにデプロイメントプランとリリースとして整理できます。ここでは、新しい Jenkins 統合を作成する方法について簡単なチュートリアルを紹介します。

Jenkins プラグイン

HCL Accelerate - Jenkins の統合は、他のほとんどのプラグインとは異なり、2つの部分からのセットアップを必要とします。最初に HCL Accelerate で統合を作成し、次に Jenkins サーバーにプラグインをインストールして設定します。また、他のほとんどのプラグインで行われているようにvsm.jsonファイルを介してバリューストリームに追加されるのではなく、Jenkins の統合はバリューストリームのパイプラインを介してバリューストリームに追加されます。

• HCL Accelerate 統合を作成
• Jenkins にプラグインをインストールして設定
• バリューストリームパイプラインでの統合を使用

要件

• Jenkins サーバが利用できない場合は、ローカルインスタンスを実行するための Jenkins のドキュメントを参照してください。https:// Jenkins .io/doc/book/installing/

• この例では、Jenkins 用のパイプラインプラグインを使用しています。このプラグインは、新しいバージョンの Jenkins ではデフォルトでインストールされています。このプラグインが Jenkins にインストールされているかどうかは、"Plugin Manager"の"Installed"タブ(< Jenkins URL>/pluginManager/installed) から確認できます。もしインストールされていない場合は、今すぐ追加するのが良いでしょう: https://plugins. Jenkins .io/workflow-aggregator。

1. HCL Accelerate Integration を作成します。

1.1 HCL Accelerate の設定ページに移動し、左のナビゲーションで「統合」セクションを選択し、「プラグイン」をクリックします。統合の追加」をクリックして、新しい Jenkins の統合を作成します。

1.2 Jenkins の統合に名前を付けてください ( Jenkins のインスタンスを記述してください)。この統合には好きな名前を付けられます。「Create」をクリックします。これにより、Integration ID と Integration Token が生成されます。これらの値は、Jenkins にインストールされている「HCL Accelerate」プラグインを設定するために必要になります。

2. Jenkins にプラグインをインストールして設定する

2.1 HCL Accelerate User Access Key の作成

HCL Accelerate からユーザーアクセスキーが必要になるので、今から作成します。 HCL Accelerate のユーザー・アクセス・キーを作成するには、「設定」>「マイ・プロファイル」に移動し、「作成」をクリックします。キーには、それを使用する統合に応じて名前を付けると良いでしょう。

Jenkins と HCL Accelerate を接続する

2.2 Jenkins サーバにプラグインのインストール

HCL Accelerate プラグインを Jenkins インスタンスにインストールします。Manage Jenkins > Manage Plugins > Available (タブ)をクリックして、Jenkins インスタンスのプラグインページに移動し、"HCL Accelerate" を検索します。プラグインが見つかったら、プラグインをインストールし、可能な場合はインスタンスを再起動します。

2.3 Jenkins からプラグインを構成する

Jenkins の設定ページManage Jenkins > Configure System > HCL Accelerate (section)に移動します。 HCL Accelerate (セクション)」の下にある必要なフィールドを入力します...

• HCL Accelerate で作成した統合によって生成された Integration ID と Integration Token 値。
• Accelerate Base URL を提供します。コンテナから Jenkins を実行している場合、localhost は host.docker.internal としてアクセスできることに注意してください。
• また、このプラグインが Jenkins にアクセスできる Jenkins ユーザーの資格情報も提供してください。
• バージョンによっては、HCL Accelerate ユーザーのアクセストークンを提供する必要があるかもしれません。先に作成したアクセストークンを使用してください。
• HCL Accelerate への接続を確認するために、[接続のテスト]ボタンをクリックする前に、[適用]をクリックして保存します。接続が成功すると、お客様のデータが HCL Accelerate に投稿されます。

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

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

• 「パイプライン」に移動し、「アプリの追加」をクリックします。
• ドロップダウンから "Jenkins" を選択します。

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

• 新しいアプリケーションはパイプライン内の行として表示されます。この Jenkins の統合は、当社のバリューストリームで利用できるようになりました。

• 新しいアプリケーションはパイプライン内の行として表示されます。この Jenkins の統合は、バリューストリームで利用できるようになりました。