2021/5月/13 - 読み終える時間: 3 分

How to optimize a secure DevOps pipeline with automation の翻訳版です。

SecureDevOps パイプラインを自動化で最適化する方法

2021年5月12日

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

DevOpsの主な目標の1つは、フィードバックループを加速することです。しかし、このフィードバックループは、しばしば手動プロセスによって停滞してしまいます。これらの手動タスクの一部を自動化することで、機能的なパフォーマンスやセキュリティチェックなどをプロセスの早い段階でシフトさせることができ、フィードバックループの高速化への道が開け、開発者はプロダクションインシデントを回避するできます。私たちのバリュー・ストリーム・マネージメント・プラットフォームである HCL Accelerate には、これを実現するためのいくつかの機能があります。

スマートゲートでは、テスト実行中に取得したデータを使用して、インテリジェントな決定を下せます。例えば、HCL OneTest を HCL Accelerate と統合することで、次の環境に移る前に、すべての機能テストが0回の失敗で合格しなければならないという自動化されたルールを追加できます。同様に、HCL AppScan を使って、静的コード解析でブロッカーがあることがわかった場合、コードを本番環境に移行できないようなルールを設定することもできます。テストと品質のためのこのレベルの自動化は、QAチームに蓄積されるテスト要求のバックログを防ぎ、品質チェックにおけるヒューマン・エラーのリスクを排除します。

同様に、当社の継続的デリバリツールである HCL Launch は、テストとセキュリティのための品質ゲートを提供します。HCL Accelerate を統合することで、HCL Launch で実行されたテスト、スキャン、デプロイメント情報のデータが自動的に HCL Accelerate に送られ、レポートやトレンド分析に利用されます。

HCL Accelerate のオートプロモート機能は、時間を節約し、パイプラインの最適化に役立つもう一つの自動化機能です。本番リリース用のデプロイメントプロセスを構築し、機能テスト、パフォーマンステスト、セキュリティスキャンなどのチェックを含むロジックを追加できます。その後、HCL Accelerate は展開ツールと通信し、どのバージョンをどの環境にどのような条件で展開できるかの指示を送信します。

HCL Accelerate は、テスト・ツールやセキュリティ・ツールを含むパイプライン内のすべてのツールから自動的にデータを取り込むため、すべての DevOps データを1か所に集められます。HCL Accelerate では、利害関係者に合わせたカスタム・ダッシュボードを作成できるため、何を修正すべきか、どのプラクティスを再現すべきかを知るための適切なレベルの情報を得られます。

全体的に、HCL Accelerate は、サイロ化された作業に起因する手動のハンドオフとボトルネックを排除します。多くのソフトウェア・デリバリー環境では、開発チームは、コードがコミットできる状態になったら、リリースチームにメモを送らなければなりません。次に、リリースチームは、コードがテストの準備ができたことを示すメモをQAに送る必要があります。そして、QAはテスト結果のメモをリリースに送り返す必要があります。HCL Accelerate は、アプリケーションが安全であることを確認するためのチェックとレポートを自動的に適用することで、これらすべてのメモを取り除きます。

自動化プロセスに適切なレベルの品質チェックを実装することで、継続的なデプロイメントモデルに真に移行できます。この機能は現在利用可能で、パイプラインの最適化に大きな違いをもたらします。これらの自動化機能のデモをご覧ください。

2021/5月/10 - 読み終える時間: 5 分

What is Value Stream Management for Software Delivery (and why it matters) の翻訳版です。

ソフトウェア・デリバリーにおけるバリュー・ストリーム・マネジメントとは何か (そしてなぜ重要なのか)

2021年5月8日

著者: Steven Wong / Solutions Lead for HCL Software

バリューストリームマネジメント (VSM) は、最近、特にITの世界で注目を集めています。私が話をした多くの人は、これがITにおける「新たな流行」に過ぎないのではないかと問いかけています。今回のブログでは、VSMに対する私の個人的な見解と、なぜそれがソフトウェア・デリバリーにとって重要なのかを紹介したいと思います。

バリューストリームマネジメント (VSM) とは？

VSMは、組織変革のためのアプローチです。

他の多くの組織変革のアプローチとは対照的に、VSM は、お客様と、お客様が最初に組織に近づいたときに期待したものである価値を提供するための組織全体の仕事の流れに、絶え間なく焦点を当てています。

ビジネスや組織を、一方で顧客からの要求を受け、他方でサービスや製品を提供するブラックボックスと想像すると、VSM はそのブラックボックス内のハイレベルな構成要素を評価し、要求がそれらの構成要素を経由して、結果として他方でサービスや製品を顧客に提供する流れを評価することである。

バリューストリームマッピングと呼ばれる手法を用いて、組織はバリューストリーム全体の仕事の流れをマッピングする。バリューストリームマップでは、さまざまなタイプの活動、システム、情報の流れを表す表記を使用します。さらに、ある活動にどれだけの時間が費やされているか、活動の外でどれだけの時間が待たされているか、その活動の成果物の品質、可用性などを明らかにするために、具体的な測定を行います。

ここで重要なのは、VSM は可視性を重視しているということです。可視性を示すのに、フローを図式化すること以上の方法があるでしょうか。

下の図は、バリューストリームマップの一例です。

バリューストリームマップがあれば、企業や組織は、潜在的な問題がどこにあるのかを確認し、パフォーマンス低下の根本原因を明らかにし、さらに重要なことに、どこで、どのように変革し、改善すべきかを明らかにできます。

VSM は新しい手法ではありません。長い間、VSM は主に、バリューストリームが工場の製造現場にある製造業の領域で使用されていました。

2010年初頭、カレン・マーティンやマイク・オスターリングのような組織変革の第一人者が、大成功を収めた著書『バリュー・ストリーム・マッピング』で、VSM とバリュー・ストリーム・マッピングの実践をオフィスやサービス業界に広めた。How to Visualize Work and Align Leadership for Organizational Transformation を出版しました。

なぜなら、顧客が組織に求めるものは「価値」であり、すべての組織はその価値を提供するシステムを持っているからである。

組織のパフォーマンスは、そのシステム (またはバリューストリーム) がいかにうまく機能して製品やサービスを提供できるかにかかっている。

VSM はソフトウェアデリバリーにどのように利用できるか？

「ソフトウェアが世界を食っている (“software is eating the world”)」という言葉を聞いたことがある人は多いと思いますが、これは今日のビジネス環境の文脈で語られることがほとんどで、テクノロジーが私たちの生活のほぼすべての局面に浸透しているため、すべてのビジネスにソフトウェアが必要であるということを意味しています。

それは、テクノロジーが私たちの生活のほとんどすべての側面に浸透しているからです。これを受けて、企業はデジタル面でのイノベーションにますます注力するようになっています。顧客エンゲージメントを高めるオンラインサービスの展開、サプライチェーンを最適化するバックエンドサービス、迅速な意思決定のためにビジネスにリアルタイムの情報を提供するアナリティクスなどです。

多くの場合、勝者と敗者の違いは、いかに早く変化に対応できるか、ソフトウェアの変更を競合他社よりも早く、高品質に展開できるか、ということに尽きるでしょう。

この適応能力を支えているのが、2000年代初頭から導入が進んでいるアジャイルや DevOps の手法です。

このアプローチにより、IT 部門では、IT が顧客 (ほとんどの場合、企業) に提供する製品に焦点を当てたクロスファンクショナルチームが形成されました。これらの「製品」チームは、リクエストから納品までの作業と、生産現場での製品の運用を管理します。

これを VSM と関連付けると、各製品チームとバリューストリームを直接比較できます。

もちろん、これは非常に単純化された見方です。というのも、ご存知の通り、複数の製品チームの間には相互依存関係が存在するからです。IT業界では、単独で存在する製品を見つけることは非常に稀です。

むしろ、ある製品／サービス (製品／サービス A とします) が、製品／サービス B の機能や特徴を必要とし、その製品／サービス B が製品／サービス C に相互依存している場合の方が多いでしょう。

ビジネス (または顧客) からのリクエストの種類に応じて、作業の流れは、単一のチームまたは複数のチームのいずれかによって実行されます。

ここで重要なのは、ソフトウェアデリバリーにおいて VSM を効果的に行うためには、異なる粒度のバリューストリームを見ることができ、ITに寄せられるリクエストの種類が異なることが非常に重要であるということです。

VSMでソフトウェア・デリバリーを最適化するには？

先に述べたように、VSMが有効なのは、あるアクティビティから次のアクティビティへのハンドオフの間の時間、労力、リワークなどの指標を可視化するからです。

製造業におけるオリジナルのVSMでは、これらの指標は、"Gemba Walk" と呼ばれる工場の現場に実際に行って、バリューストリームを構成するアクティビティの各ステップを観察し、測定することで得られます。

ソフトウェア・デリバリーの世界では、"Gemba Walk" をする意味はないかもしれません。むしろ、もっと単純なことかもしれません。

今日のソフトウェア・デリバリー・チームは、仕事を提供するために無数のツールを使用しています。

例えば、プロジェクトの計画と追跡には、Atlassian JIRAやBroadcom Rallyなどのプロジェクト計画・追跡ツールを使用します。並行開発の管理には、Gitやエンタープライズ版のGitHub、Bitbucketなどのソース構成管理 (SCM) ツールを使用しています。テストについては、テスト管理ツールや自動テストツールを使用して、テストの実行や欠陥の管理を行います。

これらのツールは基本的に、ソフトウェアデリバリーのバリューストリームを流れる作業を記録するシステムです。つまり、物理的な "Gemba Walk" を行う代わりに、ツールからデータを取得することで同じ目的を達成することができるのです。

唯一の問題は、各ツールは、そのツールが使用されたアクティビティの記録しか持っていないということです。

つまり、バリューストリーム全体のさまざまなリポジトリに、バラバラのデータが置かれているのです。

エンド・ツー・エンドの可視化のために必要なのは、これらのツールからのすべての異種の情報を、最終的に顧客からの最初の要求に関連する単一のエンド・ツー・エンドのビューにまとめる機能です。

例えば、ソフトウェア・デリバリーのためのVSMソリューションである HCL Accelerate のスクリーンショットをご覧ください。

このビューでは、各ドットが顧客からのリクエストを表しています。ドットの色は異なる優先順位を表しており、また異なるタイプのリクエストを表していることもあります。

ドットは、ServiceNOW、JIRA、TFS、HCL Compassなどのさまざまなツールから「引き込まれ」、バリューストリームのさまざまなプロセスステップやアクティビティを表すさまざまなバブルやカラムを左から右へと流れていきます。

ドットがバリューストリームを横切って進むと、HCL Accelerate のようなVSMツールは、Github、Bitbucket、HCL VersionVault のようなコードリポジトリのような他のツールからのデータを「蓄積」し、これらは顧客からの実際のリクエストにリンクされます。

ここでは、あるリクエスト (技術的な問題) がバックログから本番まで進んだ様子を紹介します。

上の画像で明らかなように、VSMソリューションは、異種ツールからの異なるデータの断片を、リクエストの単一のエンド・ツー・エンドのフローに自動的につなぎ合わせ、各段階でプロセスステップやアクティビティに費やした時間などの詳細を記録します。

HCL Accelerate は、セキュリティスキャンやテストツールとも連携できるため、コード品質やセキュリティに関する関連データを取り込むこともできます。

上記のような単一のワークアイテムでエンド・ツー・エンドの可視性を得ることは良いことですが、より価値があるのは、継続的な改善のためのフローやトレンドに関する洞察を生み出すために、バリューストリームを流れる何百、何千ものリクエストを観察し、分析する能力です。

以下に、これらのメトリクスとインサイトの例を示します。

特定のリクエストが1日遅れることで失われる機会コストをビジネスが特定できる場合、HCL Accelerate のような VSM ツールが提供するリードタイム (アイデア出しから生産までの時間) とサイクルタイム (コードコミットから生産までの時間) を比較する機能は、優先度の高いアイテムをキューに残しておくことのコストを簡単に浮き彫りにします。

バリューストリーム内のアクティビティで計画された作業と計画されていない作業の数を観察し、計画されていない作業がどのように遅延の原因となっているか (例えば、過剰な仕掛品を作成している) を観察することで、IT は作業を計画する必要がある理由をビジネスに伝えられます。

ここでの考え方は、VSM が提供する可視性は、事実に基づいた改善の手段となり、責任のなすり合いをなくすことができるということです。また、フローの最適化に焦点を当て、フローのステップではなく、フローの最適化に焦点を当てます。

まとめ

この記事では、組織変革のための実証済みのアプローチである VSM の方法論やテクニックを紹介しました。VSM は製造業の世界で生まれたものですが、ソフトウェアが普及した今日の世界でも同じように強力で効果的な手法です。VSM の手法は似ていますが、ソフトウェア・デリバリーに VSM を適用すると、いくつかの活動を異なる方法で行うことになります。例えば、ソフトウェア・デリバリーにおける VSM は、"Gemba Walk" でメトリクスを収集する代わりに、ソフトウェア・デリバリー・チームが使用するツールからメトリクスを収集しなければなりません。

HCL Accelerate は、まさにそのような要件のためにゼロから構築された HCL Software の VSM ソリューションです。

2021/5月/7 - 読み終える時間: 2 分

Three lessons from the 2021 Upskilling: Enterprise DevOps Skills Report の翻訳版です。

2021 Upskilling から得られた3つの教訓: エンタープライズ DevOps スキルレポート

2021年5月6日

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

DevOps Institute は3年前から、世界中の何百人もの IT プロフェッショナルを対象に、どのようなスキルが "must-have"、"nice-to-have"、"optional"なのかを調査してきました。最近発表された 2021 Upskilling: Enterprise DevOps Skills Report では、パンデミックによって仕事のやり方を変えざるを得なくなったときに、DevOps がどのように変化したかを明らかにしています（ネタバレになりますが、デジタルトランスフォーメーションの必要性が高まったということです）。DevOps Institute チームによる統計データと洞察を得るために、ここでレポートの全文を読むことをお勧めします。しかしその前に、本レポートが提供する数多くの教訓のうち、3つだけを紹介します。

1つのフレームワークやベスト・プラクティス・モデルは存在しない

組織がDevOpsを実践していると言っても、通常はアジャイル、リーン、ITILなどのプラクティスが混ざっています。DevOpsは組織ごとに異なるものであり、技術的なものであると同時に文化的なものでもあります。IT業界でキャリアを積みたいと考えている人は、自分のプロセスに柔軟性を持ち、新しいツールを学ぶことを厭わない必要があります。また、DevOpsを重視する組織のマネージャーは、チームメンバーが自分の好きな働き方に合ったツールやプロセスを使うことを受け入れる必要があります。HCL Accelerateのようなエンタープライズレベルのバリューストリーム管理ツールは、組織がこれを達成するのに役立ちます。組織のバラバラなDevOpsツールのすべてからデータを集約し、レポートやインサイトに正規化することで、HCL Accelerateはパイプライン全体の方法論に柔軟性を持たせることができます。

重要性を増し続けるバリューストリーム管理

Upskillingの調査回答者の39%が、VSMのスキルはプロセスとフレームワークのスキル領域で必須であると回答しています。その理由は？それは、セキュリティと同様に、お客様に価値を証明することが、ソフトウェア開発のパイプラインの中で左遷されているからです。ソフトウェア・デリバリー・ライフサイクルのエンド・ツー・エンドのインタラクティブなモデルを提供するバリュー・ストリーム・マネージメント・プラットフォームがあれば、さらなる価値の向上に向けてどこにピボットすべきか、より多くの情報に基づいた決断を下すことができます。

DevOpsは進化であり、導入すればいいというものではない

DevOpsはヨガのようなもので、完璧ではなく練習です。"DevOpsを実行する」とは、単に開発チームと運用チームが一緒に作業することではありません。異なる規律を同じ目標に向けて調整するために、文化を持続的に調整することです。DevOpsへの変革を成功させるには、組織内のあらゆるレベルのすべてのステークホルダーの関与が必要です。Upskilling社の調査では、回答者の68%がIT環境における主要なフレームワークとしてDevOpsを採用していると答えていますが、多くの回答者がDesign Thinking、SRE、Agile at Scaleも適用していると答えています。他のオペレーティング・モデルは、適切な文化が存在する限り、実際にはDevOpsを補完し、組織がDevOpsの道を歩むのに役立ちます。

2021 Upskilling.DevOps Enterprise Skills Reportには、非常に多くの素晴らしい洞察と興味深い統計があります。2021 Upskilling: DevOps Enterprise Skills Report」には、就職活動中の方、新入社員を探している方、現在の職務をスキルアップしたい方などに役立つ素晴らしい洞察や興味深い統計がたくさんあります。ダウンロードはこちらから。

2021/4/28 - 読み終える時間: ~1 分

2020年8月18日、2021年8月17日でMicrosoft 365でのInternet Explorer 11のサポートが終了することが発表されました。これに伴い、業務アプリの再検証作業が発生することが予想されます。また、移行先となるブラウザーの配布も課題になります。 HCL OneTest と HCL BigFix を使うと、これらの問題にスムーズに対処できます。詳しくは以下の記事をご覧ください。

• Microsoft 365のInternet Explorer 11サポート終了による影響とHCLが提唱する対策のポイント (DevOpsHub)

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

What’s New in HCL Launch 7.1.2.0 の翻訳版です。

HCL Launch 7.1.2.0 の新機能

2021年4月13日

著者: Hayden Schmackpfeffer / Product Manager

HCL の継続的デリバリ・プラットフォームである HCL Launch に新機能が追加され、これまで以上にソフトウェアを素早く、安全に、スムーズにデプロイできるようになりました。HCL Launch 7.1.2.0 の新機能をご紹介します。

アーティファクト・リテンション・コンフィギュレーション・ビュー

HCL Launch では、ビルドの成果物を独自のファイルリポジトリに保存することができ、デプロイメントを簡素化します。このアーティファクトを保持することで、HCL Launch は、HCL Launch サーバー内にそのバージョンのアーティファクトが存在する限り、特定のバージョンのデプロイメントをシンプルに繰り返すことができます。

しかし、すべてのアーティファクトを永久に保持することに興味がない場合がほとんどでしょう。以前のバージョンのHCL Launch では、アーティファクト・クリーンアップ機能が導入されており、指定された年数よりも古いバージョンや、そのコンポーネントのためにインポートされた最新のN個のアーティファクトに含まれていないバージョンは、HCL Launch サーバーによってアーティファクト・リポジトリからアーカイブされます。これらの設定は、3つの異なる場所で指定できます。

• システム設定ページで全体として
• コンポーネントレベルで
• 環境ごとに

これにより、組織の保持ポリシーに最も適した強力な組み合わせが可能になりますが、3つの異なるビューでクリーンアップポリシーを管理することは困難です。

保持ポリシーの設定を簡単にするために、新しい「クリーンアップ設定」ページを導入しました。新しい「クリーンアップの一括管理」権限を与えられたユーザーは、「設定」タブからこの新しいページにアクセスし、そこからクリーンアップの設定を俯瞰的に管理することができます。

このページには2つのビューがあります。コンポーネント」と「環境」です。コンポーネント」では、サーバー内のすべてのコンポーネント、そのバージョンの合計サイズ、使用されているバージョンキープの値が表示されます。この基本テーブルを使って、ディスク使用量の最大の要因や、どのコンポーネントの保持設定が最も厳しいか／最も緩いかなど、興味深い項目を特定することができます。表示されたコンポーネントを1つまたは複数選択して、ダイアログを開くことができます。このダイアログでは、選択したすべてのアイテムの保持設定を、新しい固定値に更新するか、システムのクリーンアップ値を使用するかを選択できます。

環境セクションでは、サーバー内のすべての環境が一覧表示されます。同様に、スナップショット、バージョン、およびデプロイメント履歴の保持設定を、値と、システムまたは環境テンプレート構成で指定されているかどうかの両方で確認できます。環境エントリは、コンポーネントエントリと同じ方法で変更されますが、クリーンアップの値がテンプレートから継承されている環境を変更する場合は、そのテンプレートに関連付けられているすべての環境に影響を与えます。

この新しいビューは、理想的なリテンションポリシーを構成する上で大きな強みとなります。

スナップショットゲーティング

品質ゲートは、アプリケーションの新バージョンをターゲット環境にデプロイするための絶対的な準備ができていることを確認するための、強力かつ柔軟なツールです。このゲートは、ディプロイメント マニフェストをチェックして、すべてのバージョンに必要なステータスがあること、またはディプロイメント ペイロード内に制限されたステータスが適用されているバージョンがないことを確認します。スナップショットをディプロイすると、スナップショットに含まれるすべてのバージョンが品質ゲートと照合されます。

スナップショットを使用すると、デプロイメント素材の「ゴールデンセット」の管理が簡単になるため、品質ゲートでスナップショットを使用するのがさらに簡単になりました。スナップショットのステータスを品質ゲートの条件に指定できるようになりました。スナップショットのステータスが必須または禁止の場合、デプロイされるスナップショットでその条件を満たす必要があります。これらの条件はバージョン条件と組み合わせることができ、個々のバージョンに「Build Succeeded」や「Tests Passed」などのステータスが与えられていることを確認するだけでなく、アプリケーションコンポーネントのバージョンを合成したスナップショットがチェックされていることを確認することができます。言い換えれば、品質ゲートを使って、アプリケーションの個々の部分や特定のバージョンがリリース基準を満たしているかどうかをチェックすることができます。スナップショット・ステータス・ゲートを使用すると、スナップショットに基づいたデプロイメントを1回のチェックで管理することができます。

OAuth 2.0

7.1.2.0では、HCL Launch はOpen API Connect 2.0仕様を実装したシステムに認証を委ねることができます。これにより、ユーザー認証管理を組織内の他のアプリケーション間でシームレスに共有することができます。OAuth 2.0の詳細については、こちらのブログ記事をご覧ください。

安全なポスト・プロセッシング・スクリプト

後処理スクリプトとは、あるステップが完了した後に実行されるように設定できる、JavaScriptベースのスクリプトです。このスクリプトは通常、ステップの出力ログを処理して新しいプロパティを追加したり、そのステップの成功ステータスを変更したりするために使用されます。

従来、ポスト処理スクリプトは、設定タブまたはプロセスエディタにアクセスできるすべてのユーザーが表示することができ、グローバルな「ポスト処理スクリプトの管理」権限を持つユーザーのみが編集することができました。しかし、セキュリティモデルの柔軟性をスクリプトにも反映させたいと考え、新しい権限セットを追加し、スクリプトにチームを割り当てられるようにしました。

後処理スクリプトにチームを割り当てることができるということは、これらのスクリプトへのアクセスをチームのロールメンバーシップに基づいてゲートすることができるようになったということです。重要な可能性のある配置スクリプトをすべて変更できる権限をユーザーに与えるのではなく、チームの配置にとって重要な可能性のあるスクリプトを変更できるのは、そのチームで編集権限を与えられたロールを持つユーザーだけになります。

スクリプトを表示できるユーザーのみが、その後処理スクリプトをステップに割り当てることができるため、これらの新しい権限は、スクリプトの使用を制限する手段にもなります。まだ使用できないスクリプトは、チームマッピングを保留にして、チームが追加されるまで設定できないようにすることができます。後処理スクリプトをステップに追加すると、実行ユーザーの権限に関係なく、プロセス実行の一部として実行できるようになります。

アップグレード時には、既存のすべてのロールに、そのチームの後処理スクリプトを表示する権限が与えられます。ただし、アップグレード前に存在していたすべての後処理スクリプトには、システムチームへのマッピングのみが与えられます。既存のポスト処理スクリプトへのアクセスを保持するには、システムチームのユーザーがスクリプトにチームを適用するか、または、組織がきめ細かいセキュリティアクセスを利用したくない場合は、すべてのユーザーに読み取りアクセスを与える「ポスト処理スクリプトの表示」ロールを配置することができます。

新機能の実際

HCL Launch 7.1.2.0 の詳細と新機能のデモについては、以下のオンデマンド・ウェビナーをご覧ください。

2021/4/14 - 読み終える時間: ~1 分

Deploying to Modern Architectures with HCL Launch の翻訳版です。

HCL Launch によるモダンアーキテクチャへの展開

2020年6月29日

著者: Diego Villafuerte / Solutions Specialist

すべての組織は、近代化への独自のアプローチを持っています。当社の継続的デリバリ・プラットフォームである HCL Launch は、エコシステムの成熟度に関わらず、お客様のDevOps変革に価値を提供することができます。その前に、ソフトウェア開発におけるモダナイゼーションの意味を説明します。

アプリケーションのモダナイゼーションを説明するために、架空の企業である IceCreamSoft を例に挙げます。IceCreamSoft 社は、古いソフトウェア会社ですが、グルメ・アイスクリーム・トラックを発売することにしました。そのためには、いくつかの新しいシステムを開発する必要があります。以前のような一枚岩のアーキテクチャは避けたいと考え、POS（販売時点情報管理）、在庫、ルート提案などのサービスを独立させたマイクロサービスパターンを採用することにしました。

IceCreamSoft は依然として同じ倉庫にデータを集めたいと考えているので、両方のシステムを同時にメンテナンスし、連動させる必要があります。幸いなことに、彼らはすべての導入に HCL Launch を使用していたため、プロセスはほとんど変わっていません。既存のパイプラインに、SDLC（ソフトウェア開発ライフサイクル）の一部として必要な新しいコンポーネントを追加して使用し続けることができます。パイプラインを変更するにしても、新しいパイプラインを作成して共存させるにしても、どちらの選択肢も用意されています。

HCL Launch visual process designer 最終的に、IceCreamSoft は、新しいPOSマイクロサービスが古いPOSシステムを凌駕していることに気づき、全店舗の近代化を決定します。当然のことながら、切り替えが完了した後は、厳格なテストパイプラインを調整する必要があります。HCL Launch のビジュアルプロセスデザイナーを使えば、切り替え後のパイプラインの特定の部分を簡単に排除することができます。また、HCL Launch には強力なロールバック機能があるので、もしIceCreamSoftが古いバージョンのパイプラインを使用する必要がある場合でも、すべて便利なバージョン管理ができます。

アプリケーションモダナイゼーションとは、実は、アーキテクチャ、インフラ、デリバリーモデルの3つの領域を同時にモダナイゼーションすることです。HCL Launch は、これら3つの領域が異なる段階であっても共存させることができるので、改善のスピードを落としたり、遅らせたりする必要がありません。デリバリープロセスとの一貫性を保ちながら、新しいツールでインフラを近代化する。既存のアーキテクチャを維持しながら、チームが可能な限りマイクロサービスを追加できるようにする。HCL Software DevOpsのソリューション群では、お客様の変革ストーリーに最も適したツールチェーンを構築することができます。

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

New in HCL Launch 7.1.2 - OAuth 2.0 の翻訳版です。

HCL Launch 7.1.2 の新機能 - OAuth 2.0

2021年4月2日

著者: DevOps Team, HCL Software

HCL Launch では、ネイティブの認証方法に加えて、CAS SSO や LDAP とシームレスに統合することで、様々な認証ソリューションでユーザーがログインできるようになっています。7.1.2.0 からは、新しい認証方法である OpenID Connect / OAuth 2.0 が利用できるようになりました。OpenID Connect プロバイダと統合することで、ユーザーが組織内のアプリケーションで認証するのと同じように、HCL Launch でも認証できるようになります。これにより、エンドユーザーのログインプロセスを簡素化し、ビジネス全体の認証セキュリティポリシーを一元的に管理することができます。

OpenID Connect / OAuth 2.0 とは何ですか？

OpenID Foundation は、OpenID Connect を「OAuth 2.0 プロトコル上のシンプルな ID レイヤー」と説明しています。OAuth 2.0 が API への認証を可能にするプロトコルであるのに対し、OpenIDはOAuth 2.0を拡張し、ユーザーのアイデンティティを検証する機能を提供します。これはHCL Launch にとってどのような意味を持つのでしょうか？HCL Launch が OpenID プロバイダ（Okta、Azure、Keycloakなど）と接続するように設定されていれば、ユーザーはそのプロバイダ経由で HCL Launch にログインすることができます。

それは素晴らしいことですが、どうやって始めればいいですか？

最初のステップは、HCL Launch をクライアントアプリケーションとして OpenID プロバイダに登録することです。このプロセスの詳細はベンダーによって異なります。

登録が完了したら、HCL Launch に新しい Authentication Realm を設定しましょう。OpenID プロバイダは、クライアント ID とシークレット、その他の詳細を提供しますが、これらはこのプロセスに必要です。新たに設定された Authentication Realm は、内部の Authorization Realm にのみマッピングされるため、ユーザーが作成されたら、必要なグループやチームに手動で追加する必要があります。

それでは、実際に試してみましょう

ログアウトして、ログインページに戻ります。ドロップダウンを使用して、新しい OpenID Connect ログインレルムを選択します。すべてが正しく設定されていれば、「OpenIDでログイン」をクリックすると、OpenID プロバイダーのログイン画面になります。

あなたのユーザーは新しいOpenIDレルムで作成されたばかりなので、適切なグループ、チーム、ロールに追加する必要があります。

HCL Launch は、OpenIDプロバイダ に定期的に確認することで、あなたのセッションを維持します。あなたが OpenID プロバイダにログインしている限り、あなたのユーザーセッションは開かれたままです。ただし、OpenID プロバイダ からログアウトしている場合は、再認証が必要となります。

以上、ご紹介しましたが、いかがでしたでしょうか？HCL Launch 7.1.2.0 の OpenID Connect 認証を使えば、エンドユーザーの体験を簡単に改善し、セキュリティを簡素化することができます。

2021/4/6 - 読み終える時間: 3 分

Introducing HCL Accelerate の翻訳版です。

HCL Accelerate の紹介

2020年6月23日

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

すべての DevOps データを一度にまとめるバリューストリーム管理プラットフォーム、HCL Accelerate をご紹介します。HCL Accelerate は、ビジネスチームや開発チームが、これまで以上に高い効率性と柔軟性をもって、継続的デリバリのバリューストリームを可視化、編成、最適化することを可能にします。HCL Accelerate 2.0 には、Environment Gates、Plugin SDK、Reports、New Metrics などの新しいエキサイティングな機能が搭載されており、DevOps の変革を次のレベルに引き上げるための多くの機能が強化されています。これらの新機能がお客様のビジネスにどのような価値をもたらすのかを正確に知るために読み進めてください。

環境ゲート機能 (Environment Gates)

HCL Accelerate 2.0 の最大の新機能は、環境ゲートです。これによりチームは、パイプラインのステージに応じてゲートを設定することで、ガバナンスを左にシフトすることができ、スループットを最適化しつつ、リスクを特定して低減することができます。

お客様とお話ししていると、パイプラインにはまだ多くの手作業によるチェックやサインオフがあることがわかりました。現実には、すべてを一晩で自動化できるわけではなく、どのバージョンが良いか悪いかを管理する方法は、今日、ほとんどのデリバリーチームにとって大きなギャップとなっています。手動サインオフを導入すると、一連のルールに基づいてバージョンの承認または拒否を行う権限を持つ人をカスタマイズすることができます。これにより、何をしなければならないか、どのバージョンが良いか、デプロイの準備ができているかを正確に把握することができます。一般的には、下位の環境である種の手動テストを使用し、そのテストが完了した後にバージョンを承認する1人または複数のユーザーに割り当てることができます。上位の環境では、すべてが承認されない限り、そのバージョンを入れないようにすることができます。

多くのチームでは、この手動によるゲート設定は、チャットや電子メール、口頭でのコミュニケーションを通じて行われており、人為的なミスや不整合の余地が多く残されています。Environment Gates では、HCL Accelerate がこのプロセスをより明確に、より正確にします。アクセラレートは完全な監査機能を可能にし、バージョンが不良とされた理由を正確に把握することができます。Accelerate は複数のビルドツールやデプロイメントツールを横断的に見ることができるため、バージョンが問題ないことを確認するために複数のチームに確認する必要はもうありません。

レポート機能

レポート機能はもう一つの非常にエキサイティングな新機能で、表、チャート、グラフをより詳細に収集することができ、アジャイルスプリントの状態、デプロイメントの監査、リリースのリード線など、より具体的な問題を対象とすることができます。

マネージャーやチームリーダーにとって、最も一般的な質問は、"スプリントにどれだけ残っているのか？"や、"スプリント目標を達成するためのリスクは？"です。HCL Accelerate のバリュー・ストリーム・ビジュアライゼーションは、潜在的な問題やボトルネックを見るために作業項目を表現するのに優れていますが、レポートは、そのスプリントのリスクをトリアージして判断するのに必要なすべてのデータを並べることで、さらに深く掘り下げています。

会議で、チームの進捗状況を正確に表示して、特定の項目について的を絞った会話をしたいと思ったことはありませんか？そんなあなたにぴったりのレポートです。HCL Accelerate は、DevOps Data Lake を活用して、バリュー・ストリームのどこにアイテムがあるかを正確に示し、開発者がカードを更新するのが得意でなくても、それをレポートします。開発者のステータス・チェック・ミーティングを減らすことで、あなたとあなたのチームは、作業の完了とより重要な会話に集中することができます。

プラグインSDKによるカスタムプラグイン

カスタム・プラグインを加速させるデータと関係は HCL Accelerate の基盤です。つまり、Accelerate に接続されるツールやデータが多ければ多いほど、より強力になります。しかし、多くのツールやデータが業界標準ではない自家製のものである場合、使用するすべてのものを統合するのは難しいことがあります。そのため、2.0 のリリースでは、HCL Accelerate のプラグインフレームワークをオープンにして、お客様が洞察に満ちた意思決定を行うために必要なツールやデータのための独自のプラグインを開発できるようにすることが重要でした。これにより、チームやビジネスにとって重要なメトリクス、KPI、OKR をさらに進化させる無限の可能性を持つ Accelerate の可能性が開かれます。

プラグインの開発方法がわからないという方。心配しないでください。私たちは、30分以内に最初から最後までできるように「Hello world」を書きました。また、すべてのリソースが製品内に用意されているので、ファイルのダウンロードとアップロードがすぐにできます。

新しいメトリクス

HCL Accelerate 2.0 では、機械学習と新しいメトリクスによるビジネスアジリティに注目しました。今では10以上のアウトオブボックスのメトリクスがあり、チームはトランスフォーメーションの全体像を把握し、ビジネスアジリティを推進することができます。ロード」と「コントリビューター」という2つの新しいメトリクスを導入したことで、バリューストリームにおけるフローが最適であることを確認することができます。

"Load" は、あなたのバリュー・スチームでアクティブになっているワークアイテムの数です。"Contributor" は、これらのアイテムに割り当てられているユニークなリソースの数です。この情報があれば、バリューストリームがどのように行われているかをこれまで以上に迅速に分析することができます。ロード、スループット、コントリビューターのすべてがお互いにどのように影響するかを推測するのをやめて、トレンドを見て、チームにとって最適なダイナミックさを見つけることができます。理想的な使用例は、スピードと品質を備えた最適なスループットを得るために、チームがどれだけの負荷を処理できるかを見つけることです。

どのチームがより多くのリソースを必要とし、どのチームが過剰であるかを明確に示すことで、HCL Accelerate はあなたのビジネスがより少ないリソースでより多くのことを行うことを可能にします。バリューストリームのどこでフローが滞っているかを発見し、チームがどこの改善に注力すべきかを見極めるのは、簡単な作業ではありません。重要なボトルネックを発見するための機械学習モデルを使用することで、Accelerate は、どこで作業がバッチ処理されているか、どのタスクに長い待ち時間があるか、どこに流入/出力の不整合があるかを簡単に知ることができます。改善すべき領域を特定するための推測作業を排除し、変更を裏付ける実際のデータを持つことで、マネージャーは、プロセスの変更や自動化が必要な理由についてビジネスリーダーとのギャップを埋めることができます。これらの新しい測定基準と機械学習アルゴリズムにより、チームを次のレベルに引き上げ、市場での競争力を維持することができます。

HCL Accelerate を実際に見る

HCL Accelerate のバリュー・ストリーム・マネジメント機能の利点を理解する最良の方法は、実際に見てみることです。この録画されたウェビナー で、HCL Accelerate のデモを見て、新機能をチェックしてください。