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

英語版ブログ記事 Boost performance with agent relay caching in HCL Launch の翻訳版です。

HCL Launch: エージェントリレーキャッシングによるパフォーマンスの向上

2020年8月4日

著者: Hayden Schmackpfeffer / Senior Developer, HCL

エンタープライズ規模では、パフォーマンスが制限要因となります。 HCL Launch はもちろんエンタープライズ向けに設計されており、パフォーマンスを維持しながら成長を支援する機能を提供しています。

インストールを拡張するために使用できる機能のひとつはエージェントリレーです。リレーはファイアウォールの外にあるエージェントを管理します。リレーは、サーバとの通信を一箇所で行うことができるため、この機能は拡張がしやすくなっています。「任意の数」というのは大げさかもしれませんが、各リレーは 1,000 エージェントを確実にサポートできます。

ファイアウォールの設定をナビゲートするだけでなく、リレーはエージェント通信の負担をサーバから軽減することでパフォーマンスを向上させます。すべてのエージェントに成果物を送信する代わりに、サーバは成果物をリレーに送信するだけで、リレーからエージェントに成果物が送信されます。多くの顧客がこのトポロジーを使用しています。

ネイティブの HCL Deploy アーティファクト・リポジトリ CodeStation を使用している場合、パフォーマンスを向上させるもう一つの機能は、エージェント・リレー・キャッシングです。この機能は、アーティファクトのコピーをリレーに格納することで、ダウンロード時間を短縮します。サーバーは、すべてのアーティファクト要求に応答する必要がなく、複数のエージェントが同時にキャッシュされたアーティファクトをダウンロードすることができます。

リレーを構成して、「ステージング」などの特定のステータスに基づいてアイテムを自動的にダウンロードするように設定することで、アーティファクトをプリロードすることができます。または、HCL デプロイ・アプリケーションを使用して、リレー・キャッシュにアーティファクトをロードすることもできます。

この機能によって提供されるパフォーマンスの恩恵は、劇的なものになる可能性があります。

リレーキャッシュの最近の強化は、この機能をさらに魅力的なものにしています。今では、アプリケーションが大きなファイルやアーティファクトの一部だけを必要とする場合、最初にファイル全体をダウンロードすることなく、直接それを取得することができます。特に、必要なアーティファクトが10GBなどの大容量ファイルの最後にある場合には、パフォーマンスは大きく向上します。

最後に、リレーは、ユーザーの期待に沿ったキャッシュサイズを維持するために、より積極的になっています。以前は、クリーンアップ間隔の関係で、リレーキャッシュが一時的にサイズ制限を超えることがありました。今では、適切に設定されていれば、実際にはサイズ制限を超えることはありません。

このオンデマンドビデオデモで HCL Launch の動作をご覧ください。

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、開発、リリースに至るまでのバリュー・ストリームをマッピングすることからこのプロセスを始めるでしょう。その後、チームと協力してギャップや誤解を特定します。このバリュー・ストリーム・マップは、私がデリバリ・パイプラインを分析するために使用している主要なツールです。

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

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

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 の詳細と無料トライアルを入手するには、ここをクリックしてください。

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 の検出およびアラートシステムがボトルネックを発見することで、お客様のチームは、効率的で効果的な価値の流れの中でソフトウェアを開発することができるようになります。

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

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

「何でもどこでもデプロイ」ツールである HCL Launch。高速デプロイについて、英語版ブログ Making upgrades easier in HCL Launch の翻訳版です。

アップグレードを容易にする HCL Launch の機能

2020年7月24日

著者: Max Bellin Warren / Software Developer

HCL Launch は、デプロイをスムーズに実行し、生活を楽にするための多くの機能を備えています。v.7.0.4 で私が気に入っている最近の機能強化の1つは、自動化プラグインのアップグレードの変更です。

過去には、HCL Launch サーバーを最新バージョンにアップグレードするのは非常に時間がかかりました。サーバーのアップグレードは、多くのプラグインを更新し、ひいては多くのプロセスを更新することになります。これには何時間も、時には何日もかかることもありました。

今、私たちは HCL Launch のアップグレードプロセスを超高速になるように再構成しました。一度にすべてを更新するのではなく、プロセスやプラグインは使用するたびにその場で更新されます。これにより、アップグレード後に初めて HCL Launch サーバーを起動したときに、アップデートが終わるまで何時間も待たされることなく、すぐに作業に取り掛かることができるようになりました。

これは、以前はアップグレードを実行するためにサーバーのダウンタイムを設定しなければならなかった管理者にとってはゲームチェンジャーです。今では、サーバー管理者はよりリラックスして、より迅速なアップグレードを体験できるようになりました。この余分な時間で何ができるか想像してみてください。

エンドユーザーは、プロセスにわずかな違いを感じることでしょう。この機能強化の前は、プラグインの更新ごとに新しいバージョンのプロセスが生成され、サーバーを停滞させ、作業の速度を低下させていました。今では、すべてのプロセスは、それに関連付けられた自動化プラグインの最新バージョンを自動的に使用します。初めて、古いプロセスのバージョンは、スナップショットであっても、プラグインの最新バージョンを利用することができるようになりました。当社のプラグインはすべて下位互換性があるので、これらのプラグインの自動更新によって業務の流れが中断されることはありません。

私たちは、「何でもどこでもデプロイ」ツールである HCL Launch をより使いやすくする方法を常に探しています。機能や機能強化のための提案があれば、ぜひお聞かせください。

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

旧 UrbanCode Deploy である HCL Launch は「あらゆるものを、どこにでもデプロイするエンタープライズソリューション」です。その製品解説記事 Get to know HCL Launch が英語版ブログにポストされました。その翻訳版を掲載します。

HCL Launch を知る

2020年7月23日

著者: Brian Stump / Product Specialist

HCL Launch は、あらゆるものをどこにでもデプロイできるように構築されたエンタープライズグレードの継続的デリバリーソリューションです。HCL Launch は、サーバーエージェントモデルを使用してアプリケーションをマッピングし、デプロイします。これらのコンポーネントは、ビルドサーバーから引き出され、アーティファクトリポジトリから引き出されます。これらのコンポーネントを設定する方法はたくさんありますので、それらのアーティファクトやファイルを引き出してデプロイできます。

HCL Launch 製品の最高レベルでは、アプリケーションがあります。アプリケーションは通常、複数のコンポーネントで構成されており、これらのコンポーネントをデプロイしたい環境にマッピングされています。これらのアプリケーションのそれぞれについて、このアプリケーションがどのようにデプロイされるかのプロセスを定義します。例えば、デプロイのプロセスでは、Web サーバー、データベースコンポーネント、データベーススキーマ、Java ファイルをインストールできます。これらの各ステップの中には、アプリケーションをデプロイする環境に応じて、ターゲットマシン上でエージェントが実行するスクリプトとステップを含むコンポーネントプロセスがあります。

各環境はコンポーネントで構成されています。コンポーネント・プロセスは、ドラッグ&ドロップのビジュアル・デザイナーを使って非常に簡単にカスタマイズできます。HCL Launch 環境のダッシュボードでは、コンポーネントのバージョン、最後にデプロイされた日付、デプロイに成功した場合はデプロイのログにアクセスできます。これにより、監査、ガバナンス、承認を簡単に追跡でき、エンタープライズ環境に最適です。

コンポーネント、アプリケーション、リソース、および環境ごとに、プロセスをテンプレート化できるので、多くの類似したアプリケーションを簡単にオンボードできます。例えば、類似のプロセスに従う多くの java コンポーネントがあり、そのデプロイメント・プロセスを共有したい場合、テンプレートを簡単に作成して、そのプロセスをシンプルで再現性のあるものにできます。

HCL Launch を使用すると、スナップショットを使用できます。スナップショットを使用すると、一緒にデプロイできることがわかっているバージョンの「黄金の」構成バンドルを作成できます。スナップショットでは、プロパティ、プロセス、テンプレートなどのオブジェクトの特定のバージョンをロックできるので、スナップショットで構成をロックした後にオブジェクトが変更されても、スナップショットをデプロイして、最初にスナップショットを作成した時にデプロイしたのと全く同じ構成を取得できます。言い換えれば、スナップショットにステータスを設定すると、これらのコンポーネントのそれぞれのバージョンがテストされたことがわかり、一緒に進むことができるので、依存関係の問題やバージョンの不一致などの問題に遭遇することはありません。

今実行するデプロイメントをスケジュールすることができ、将来的にはいつでも実行できます。HCL Launch バックエンドAPIは非常にオープンで文書化されているので、スクリプトや継続的インテグレーションサーバーからデプロイメントを開始するのは非常に簡単です。

HCL Launch サーバーの設定と設定では、ユーザーとグループのロールを定義して、誰が承認を行い、誰が履歴を表示し、誰がデプロイを実行できるかを制御できます。ロールは、HCL Launch オブジェクトのサブタイプごとに別々の権限を持つことができます。ユーザーが開発環境、QA 環境、または本番環境と対話しているかどうかに応じて、ロールの権限を簡単に分割できます。設定セクションは、プラグインを設定する場所でもあり、HCL Launch がどのように機能するかの鍵となる機能です。HCL Launch は何百ものプラグインと統合されており、自動化やソースの設定を行うことができます。

上のデモビデオを見て、HCL Launch の動作を確認してください。個別にデモをご希望の場合は、こちらからお申し込みください。

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

Jira や ServiceNow など複数の仕組みを利用している環境では、そのプロセス処理が煩雑になりがちで、ルールの遵守やミス誘発の観点からしっかりした運用管理の仕組みが必要です。HCL Launch は統合された運用指示を実現できます。今回は、その機能のひとつである外部承認機能についての解説です。英語版ブログ External Approvals in HCL Launch の翻訳版です。

HCL Launch の外部承認機能

2020年7月22日

著者: Diego Villafuerte / Solutions Specialist

私たちは、継続的デリバリプラットフォームである HCL Launch を使用している人たちの傾向に気づきました。多くのお客様は、デプロイ前に変更要求がいくつかの定義された基準を満たしているかどうかを検証するために、Jira や ServiceNow などのサードパーティのツールを使用しています。これはガバナンスのギャップにつながり、CR のステータスをチェックしてプロセスをグリーンライト化するために手動で承認する必要があります。この方法は機能しますが、理想的な方法ではありません。だからこそ、自動化するために HCL Launch を開発しました。

7.1.0.0 では、プロセスを自動的に検証するために使用するツールの汎用テンプレートである外部承認機能 (External Approvals) を追加しました。外部承認プロセスは、既存の承認プロセスよりも一般的なプロセスのようなもので、エージェント上で実行され、プラグインのステップにアクセスすることができます。現在のセキュリティスキームに沿って、これらのプロセスを制御するために、新しい権限をいくつか追加しました。ガバナンスの観点からは、これはチームが外部承認のアクセス権を持つ人を完全に制御し、外部承認の設定を要求できることを意味します。

外部承認 (External Approvals) は、Process タブで作成および変更されます。

外部承認は、現在の承認プロセスの概念を置き換えるものではありません。代わりに、承認プロセスは、特定の担当者からの手動承認が必要な配置の任意の部分で利用できますが、外部承認プロセスは、配置の前に自動的に実行され、配置が記録システムに従って実行されるべきであることを検証するのに適しています。承認プロセスは、プロセス要求が送信されたりスケジュールされたりするとすぐにキックオフされますが、外部承認は、手動承認に応答した後、デプロイメントが開始される直前に実行されます。

外部承認は、環境の基本設定で設定します。

ここでの "Validate JIRA Record" (JIRA レコードを検証する) から外部承認プロセスを変更する権限は、他の基本設定とは区別されています。これは、開発者が外部承認を管理することを制限できる一方で、環境レベルのプロパティを変更できることを意味します。

実行ログ (Execution Log) では、外部承認プロセスを展開してステップを詳しく見ることができます。

皆様の期待通り、アプリケーションは外部承認でエクスポートされ、上記で説明した内容を制御するための新しい粒度での細かいセキュリティ権限設定があります。

外部承認機能があなたの DevOps の変革に役立ったかどうかを教えてください。