Resiliency for CI/CD Pipeline の翻訳版です。
CI/CD パイプラインのレジリエンス (復元性)
2021年12月14日
著者: Cassandra Stanek / Product Marketing Manager, HCL Accelerate & Launch
ITの黄金律はレジリエンス(回復力) です。侵入、ハッキング、予期せぬトラフィックの増加、ヒューマンエラーなど、デジタルの世界では常に起こることなので、プランBを用意する理由を挙げればきりがない。レジリエントなDevOps自動化フレームワークを構築することは、予期せぬ事態が発生した場合でも、アプリケーションデリバリプロセスを中断することなく継続できることを意味します。
HCL Launch 7.2.1 は、さまざまな方法でディザスタリカバリのためのレジリエントなフレームワークをサポートします。最も大きなものの1つは、分散型フロントエンドサーバー機能です。お客様がDevOpsを採用するにつれ、HCL Launchサーバーにログインするユーザーの数は増え続け、その追加アクティビティによって
分散型フロントエンドサーバーは、ユーザーの負荷を分散させ、すべてのユーザーがUI内でスムーズな体験をできるようにするための優れた方法です。現在の環境にこれらのサーバーを追加することで、フロントエンドの単一障害点から脱却し、耐障害性を高めることができます。
以下は、インスタンスを経由する大量のトラフィックを管理するための推奨アプローチです。エンドユーザーのHTTPトラフィックはロードバランサーを経由して、分散されたフロントエンドサーバーに渡されます。この通信は、オプションで別のバックエンドロードバランサーを介してプッシュしたり、HCL ローンチサーバーに直接配信することができます。
HCL Launch In The Cloud: Automating Continuous Deployment の翻訳版です。
HCL Launch In The Cloud: 継続的なデプロイメントの自動化
2021年7月26日
著者: James Carmichael / HCL Software Senior Software Engineer
HCL Launch は創業以来、クラウドベースの環境にワークロードをデプロイすることができます。特に、HCL Launch は、クラウドネイティブなコンポーネントとオンプレミスのコンポーネントの両方で構成されるハイブリッドアプリケーションのデプロイを得意としています。
この度、HCL Launch がクラウドベースの Kubernetes 環境でのデプロイに対応したことを発表します。このサポートには、サーバー、エージェント、リレーのデプロイメントが含まれており、ユーザーは Kubernetes の多くの利点を活用することができます。これにより、ユーザーは変動するワークロードに合わせて、サーバー、エージェント、リレーを迅速に拡張できるようになります。ワークロードが自動的にスケジュールされ、最高のサービス品質で実行されるようになります。サーバー、エージェント、リレーの新バージョンへのアップグレードは、helm upgrade コマンドを使用することで、迅速かつ簡単に行えるようになります。
グラフィカル・ユーザー・インターフェース、テキスト、アプリケーション、電子メール 説明が自動的に生成される
HCL Launch は、オンプレミスのプライベートクラウドで稼働しているか、マネージド環境で稼働しているかに関わらず、ほとんどの Kubernetes ベースの環境をサポートしています。このサポートは、AKS、EKS、GKE、RHOCP、IKS でテストされています。
この新しいサポートは、以下のようなユーザー環境のために、いくつかのトポロジーの選択肢を提供します。
現在、HCL Launch を Kubernetes 以外の環境で運用している場合は、新しいクラウドソリューションへの移行をサポートしています。
HCL Launch を試すには、HCL SoFy のウェブサイトにアクセスし、SoFy カタログから HCL Launch アプリケーションを選択します。そこから、提供されるサンドボックスでソリューションを実行することもできますし、ソリューションをダウンロードして、自分の Kubernetes クラスタに期間限定でデプロイすることもできます。試用版ソリューションでは、HCL Launch Server と、サンプルデプロイに使用できる接続エージェントが提供されます。
HCL Software DevOps is Cloud Native の翻訳版です。
HCL Software の DevOps はクラウドネイティブ
2021年7月20日
著者: Elise Yahner / Marketing Strategy and Campaigns for HCL Software DevOps
5年前、HCL Software チームは、当社のソフトウェア製品がダイナミックなパブリッククラウド、プライベートクラウド、ハイブリッドクラウドに数分でデプロイされる未来を想像していました。今、私たちは HCL SoFy と HCL Now の立ち上げにより、その時点に到達しました。HCL Software DevOps グループは、このクラウドネイティブな変革の一翼を担えることに興奮しています。私たちのお客様にとってのハイライトは以下の通りです。
最後の点は、当社の DevOps ソリューションを実際に体験して、既存の DevOps パイプラインとの連携を確認したい場合に特に有効です。HCL SoFy を使用すると、HCL Software のお客様とパートナーは、HCL Accelerate、HCL Launch、HCL Compass、または HCL OneTest のトライアルを数秒で入手できます。以下のステップに従うだけです。
HCL Software のお客様やパートナー様でなくても、SoFy へのアクセスは可能です。まずはこちらからデモをご依頼ください。
SoFy サンドボックスにソリューションを導入すると、事前に入力されたデータが得られるので、自分でデータを入力しなくてもソリューションを遊ぶことができ、ソフトウェアの体験にすぐに飛び込めます。現在、HCL Software DevOps ソリューションの SoFy には以下のデモが存在します。
また、ソリューションをローカルにダウンロードして、ご自身のデータで当社のDevOpsソフトウェアをお試しいただくことも可能です。さらに、1対1のサポートをご希望の場合は、いつでも対応いたします。当社のDevOpsエキスパートチームは、ベストプラクティスを説明し、お客様のユニークな組織をサポートする戦略を立てるのが得意です。
クラウドネイティブなソリューションに対して、よりマネージドなアプローチをご希望ですか?HCL Nowはクラウド・ネイティブ・アズ・ア・サービスのソリューションで、お客様が選択したパブリック・クラウド上に専用のセキュアな環境を展開し、管理します。HCL Now は、最新バージョンの HCL Software DevOps ソリューションと、専任のエキスパートによる管理を、クラウドの柔軟性、拡張性、利便性とともに提供します。
当社のすべての DevOps ソリューションは、HCL Now でオンデマンドで利用できますが、HCL Now での HCL OneTest Performance は、テストを簡単にしたい HCL Commerce ユーザーにとって特に便利です。このセットアップでは、インフラストラクチャー管理、製品のアップグレードとサポート、セキュリティとプライバシーコントロールのメンテナンスを含むターンキーテストソリューションを提供します。つまり、新しいインフラに投資することなく、実際のピーク時の負荷を簡単にテストすることで、より早く開始し、コストを抑えることができるのです。
今こそ、DevOps の旅をクラウドで実現する時です。9月16日午後12時(米国東部時間)に開催されるウェビナー に参加して、HCL Now が選択したクラウド・ネイティブ・プラットフォーム上で、当社の DevOps ソリューションの可能性を最大限に引き出す方法を学んでください。HCL Now は、お客様が選択したクラウド・ネイティブ・プラットフォーム上で、HCL Software のDevOps ソリューションの可能性を最大限に引き出します。登録はこちら から。
最後にもう一度。HCL Software の DevOps はクラウドネイティブです。
Launch 7.2: Impactful Updates Enabling Faster Continuous Delivery の翻訳版です。
HCL Launch 7.2: 継続的デリバリーの高速化を可能にするインパクトのあるアップデート
2021年7月1日
著者: Senthil Nathan / HCL Launch Product Manager
継続的デリバリープロセスを促進する適切なツールを持つことは、成功に不可欠です。Launch 7.2 のユーザーは、継続的デリバリーの高速化を可能にするインパクトのあるアップデートの力を利用しています。
世界中で30億台以上のデバイスがJavaを実行しています。環境内の多数のデバイスにパッチやメンテナンスを適用したり、将来のリリースを着実に更新したりすることは複雑です。Javaのパッチを手動で適用している場合、チームはどうやってデジタルトランスフォーメーションに集中できるでしょうか?HCL Launch 7.2では、Javaの配布管理は簡単で、Launchダッシュボードからサーバーサイドで行われます。
接続されているデバイスのステータスをリアルタイムで確認できるので、どのアップデートやパッチを適用する必要があるかをすぐに特定できます。HCL Launch 7.2では、無制限のJavaパッケージをアップロードして、環境内の異なるデバイスやアーキテクチャに適用できます。
エージェントをクリックし、行の右側にあるメニューを使用して、インストールする特定のエージェントを選択できます。
インストール状況の確認とメンテナンスの実行は、リソース>エージェント>特定のエージェントを選択し、メンテナンスタブに切り替えることで行います。ここでは、Java の全メンテナンス履歴を確認できます。
エージェントレベルの新しい Metadata ページでは、そのエージェントにインストールされているすべての Java バージョンを確認できます。
新しい Java バージョンが UI にインストールされると、エージェントの JAVA_HOME を新しい Java のホームに設定できます。
エージェントをすばやく再起動すると、新しいJavaバージョンが稼働します。以上で終了です。新しい Java バージョンをインストールするために、ターゲットマシンにリモートアクセスしたり、複雑なスクリプトを書いたりする必要はありません。
新しい Java バージョンがインストールされた後は、「Java パッケージのアンインストール」オプションを使って、古い Java バージョンのクリーンアップに自由に取り組めます。
Java のアップデートに Launch を使用しない場合でも、「Javaホームの設定」機能を使用してエージェントの Java ホームを設定できます。ただし、この場所は、Java がインストールされているエージェントからアクセス可能な絶対パスである必要があります。
Java の配布管理は大きなタスクであるため、IT リソースの最適化のためには効率的に行うことが重要です。Javaの管理に費やしていた時間を取り戻すことで、チームはデジタルトランスフォーメーションに向けた作業に集中できます。
HCL Launch 7.2 を使って何でもどこでもデプロイする方法について詳しく知りたい方は、次回のウェビナー HCL Launch 7.2 の新機能 にご参加ください。
Collaboration Tool Integration with HCL Launch の翻訳版です。
HCL Launch によるコラボレーションツールの統合
2021年6月22日
著者: Senthil Nathan / HCL Software Launch z/OS Architect
メールが唯一のチームコミュニケーションツールであった時代は終わりました。リモートワークへの急速なシフトに伴い、ダイナミックな企業は Slack や MS Teams のようなツールを採用し、シームレスにファイル共有、チャット、接続を行っています。
最新バージョンの HCL Launch 7.2.0 では、HCL Launchと統合することで、これらのチームコミュニケーションツールを強化できます。連携することで、コラボレーションツールに直接通知が表示され、バリューストリームの状況をリアルタイムに把握できます。Webhookインテグレーションを使用して、Teams、Slack、またはコミュニケーションツールのLaunchチャンネルにサブスクライブするだけで、通知を受け取れます。
Webhooks とは?
Webhook は基本的に、イベントによって駆動する HTTP コールバックです。Webhookは、特定のイベントが発生したときに通知を可能にします。Webhook の URL には、情報を必要とするサービスに関するすべての必要な情報が格納されています。Webhookのテキスト・ボディには、Webhook が生成されたイベントの詳細が記載されています。Webhook は DevOps の自動化でよく使われます。HCL Launch 7.2.0 では、発信型の Webhook をサポートしています。
デプロイメントの状況を簡単に把握するために、以下のようなHCL Launchのイベントに応じて通知 (Webhook) をトリガーすることができます。
現在 Slack や Teams を使用していない場合、通知 (Webhook) は、Webhookを受け付けるあらゆる製品やアプリケーションに送れます。Launch通知に接続したいアプリケーションについては、Apache Velocityのテンプレート形式を使用した Webhook テンプレートを作成する必要があります。上記のイベントタイプごとに、任意の数のテンプレートを作成できます。
例えば、以下の Webhook テンプレートは、Microsoft Teams 用に作成されたものです。このテンプレートには、Webhook の本文のみが含まれており、URLは含まれていないことに注意してください。
Webhookテンプレートには、Teamsの関連付けもされています。これにより、Webhook テンプレートを表示できる人にアクセスが制限されます。
Webhook の URLは、アプリケーション環境レベルで設定されます。このようにして、企業レベルではテンプレートを再利用し、個々のチームではアプリケーション環境レベルで異なる宛先への通知を設定できます。
アプリケーション環境レベルでは、以下のように複数のWebhookを設定できます。
雑音を排除し、チームの集中力を維持します。ユーザーが所属しているチームに応じてアラートを設定することで、関連する通知のみを受け取れます。例えば、低環境用の Webhook トリガー通知を特定の Teams や Slack チャンネルに送信し、本番用の通知を別のチャンネルに送信できます。
あなたの企業のデプロイメントは重要です。次回のウェビナー What's New in Launch 7.2.0 では、Launch ユーザーが何でも、どこでも、より速くデプロイできるようにするための最新機能をご紹介します。
Integrating Jenkins and HCL Launch の翻訳版です。
Jenkins と HCL Launch の統合
2021年6月4日
著者: HCL Software / A division of HCL Technologies (HCL)
多くのチームは継続的インテグレーションに Jenkins を使用していますが、ビルドのデプロイを環境に合わせて調整する必要があります。 Jenkins を使ってこれらのビルドを作成し、新しいビルドをHCL Launch に渡してデプロイできます。オプションとして、ビルドをテスト環境に自動的にデプロイすることもできます。
Jenkins Publisher プラグインをダウンロードします。
プラグインを Jenkins サーバーの Web サイトにアップロードします。
http://jenkins-server:8080/safeRestart を使用して新しいプラグインを確認するために、 Jenkins サーバーを再起動します。
プラグインがインストールされ、有効になっていることを確認します。
HCL Launch サーバーのプロファイルを追加します。
各ジョブの Post-build Actions を設定します。
プラグインが Jenkins サーバーにインストールされ、指定したHCL Launchコンポーネントにアーティファクトがパブリッシュされます。 その他のアプローチ
ポストビルドアクションがチームにとって適切でない場合や、単一のビルドから複数のコンポーネントに成果物をプッシュしたい場合は、いくつかの他のオプションがあります。
HCL Launchの1対1のデモをご希望ですか?こちらからリクエストしてください。
HCL DevOps製品群を使ったリアルなデモを作成しました。
具体的には、HCL Compass、HCL Accelerate、HCL Launch、HCL OneTest を使用したものです。開発現場の実際をリアルに模した A Day in the Life 型のデモです。その分、17分弱とちょっと長めです。
こちらの解説記事もあわせてご覧ください。
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回のチェックで管理することができます。
7.1.2.0では、HCL Launch はOpen API Connect 2.0仕様を実装したシステムに認証を委ねることができます。これにより、ユーザー認証管理を組織内の他のアプリケーション間でシームレスに共有することができます。OAuth 2.0の詳細については、こちらのブログ記事をご覧ください。
後処理スクリプトとは、あるステップが完了した後に実行されるように設定できる、JavaScriptベースのスクリプトです。このスクリプトは通常、ステップの出力ログを処理して新しいプロパティを追加したり、そのステップの成功ステータスを変更したりするために使用されます。
従来、ポスト処理スクリプトは、設定タブまたはプロセスエディタにアクセスできるすべてのユーザーが表示することができ、グローバルな「ポスト処理スクリプトの管理」権限を持つユーザーのみが編集することができました。しかし、セキュリティモデルの柔軟性をスクリプトにも反映させたいと考え、新しい権限セットを追加し、スクリプトにチームを割り当てられるようにしました。
後処理スクリプトにチームを割り当てることができるということは、これらのスクリプトへのアクセスをチームのロールメンバーシップに基づいてゲートすることができるようになったということです。重要な可能性のある配置スクリプトをすべて変更できる権限をユーザーに与えるのではなく、チームの配置にとって重要な可能性のあるスクリプトを変更できるのは、そのチームで編集権限を与えられたロールを持つユーザーだけになります。
スクリプトを表示できるユーザーのみが、その後処理スクリプトをステップに割り当てることができるため、これらの新しい権限は、スクリプトの使用を制限する手段にもなります。まだ使用できないスクリプトは、チームマッピングを保留にして、チームが追加されるまで設定できないようにすることができます。後処理スクリプトをステップに追加すると、実行ユーザーの権限に関係なく、プロセス実行の一部として実行できるようになります。
アップグレード時には、既存のすべてのロールに、そのチームの後処理スクリプトを表示する権限が与えられます。ただし、アップグレード前に存在していたすべての後処理スクリプトには、システムチームへのマッピングのみが与えられます。既存のポスト処理スクリプトへのアクセスを保持するには、システムチームのユーザーがスクリプトにチームを適用するか、または、組織がきめ細かいセキュリティアクセスを利用したくない場合は、すべてのユーザーに読み取りアクセスを与える「ポスト処理スクリプトの表示」ロールを配置することができます。
HCL Launch 7.1.2.0 の詳細と新機能のデモについては、以下のオンデマンド・ウェビナーをご覧ください。