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

Tech trends impacting DevOps, and what they mean for you の翻訳版です。

DevOps に影響を与える技術トレンドと、それがあなたにとって何を意味するのか

2021年2月15日

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

調査・アドバイザリー会社のガートナーは先日、DevOps に影響を与えるテクノロジートレンドのトップ 10 を概説したインフォグラフィックを発表しました（ガートナーのサブスクリプションをお持ちの方はこちらからご覧になれます）。このインフォグラフィックは、製品、プラットフォーム、およびガバナンスを改善するためのデジタルトランスフォーメーションの取り組みのロードマップとして機能します。私たち、HCL Software DevOps グループでは、これらのトレンドの実用的な適用と、なぜこれらのトレンドが重要なのかについて議論してきました。DevOps に影響を与える Gartner 社の技術トレンドの一部をご紹介します。

アジャイル製品の提供

Gartner は次のように書いています：「価値あるソフトウェアの継続的なデリバリーは、継続的なインテグレーション、継続的なテスト、機能フラグの管理、継続的なモニタリングを含むアジャイルプラクティスによって達成されます」。

HCL Software DevOps の見解: 適切な自動化ツールを適切に配置することは、組織にとってアジャイルな製品デリバリーの鍵となります。現在のソフトウェア・デリバリー・パイプラインにあるすべての手動プロセスを特定してください - 承認をメールで送信することから、テストを実行するタイミングをシステムに伝えることまで、すべてが適切なツールによって合理化され、改善されます。自動化できるプロセスが増えれば増えるほど、チームがビジネスの成果を出すことに集中できる時間が増えます。

このトレンドをサポートするツール：HCL Launch、HCL OneTest、HCL Accelerate、HCL Compass

継続的な品質維持、向上

ガートナー社は、「継続的品質とは、品質保証の概念を、機能的欠陥と非機能的欠陥からの予防、検出、回復可能性に至る一連の継続的な活動にまで拡大したものである」と述べています。

HCL Software DevOps は言う。繰り返し可能なデリバリー・パイプラインを確立することは、「Day 1 DevOps」ですが、継続的な品質を取り入れることは、成熟した「Day 2 DevOps」パイプラインの特長です。テストは、ソフトウェアのデリバリープロセスの特定の部分だけに限定されるべきではありません。品質を確保し、問題を早期に発見し、進歩を加速させるために、テストは開発全体を通して頻繁に行われるべきです。

このトレンドをサポートするツール：HCL OneTest、HCL Accelerate

継続的なコンプライアンスの自動化

継続的なコンプライアンスの自動化は、コンプライアンス違反の発見と検出、ポリシーの実施とレポートの自動化、および脆弱性の修正により、リスクを軽減するのに役立ちます。

HCL Software DevOps の見解: これらのトレンドに気づいていますか？これらの取り組みの多くの原動力は、セキュリティ、コンプライアンス、品質です。成熟した DevOps 組織では、ガバナンスは誰かの仕事だとは言えません。コンプライアンスの確保は、組織内でのアクセス、役割、責任の割り当て方から始まります。DevOps パイプライン全体で使用するツールは、品質ゲートを強制し、コードとしてのポリシーを維持し、矛盾を報告するために連携する必要があります。ワークフロー全体にまたがることができる、実績のあるセキュリティとコンプライアンスの自動化ツールに投資することは、競争力を維持し、組織が次の大きなセキュリティ侵害の中心になることのないようにするための鍵となります。

このトレンドをサポートするツール: HCL Accelerate

バリューストリームエンジニアリング

ガートナーは、「ローカル最適化を避け、システムレベルのアプローチで顧客価値の流れを改善する」と述べています。

HCL Software DevOps の見解: このトレンドは、他のすべてのトレンドを網羅しています。このトレンドは、他のすべてのトレンドを網羅しています。バリューストリーム管理は、DevOps パイプラインのデータを統合し、パフォーマンスと戦略を全体的に見ることができるようにします。VSM は、データベースの DevOps 環境を構築し、信頼とコミュニケーションを中心とした組織文化を構築するための鍵となります。今、VSM のトレンドに乗っている組織は、あっという間に競合他社よりもはるかに先を行くことになるでしょう。あなたは取り残されている余裕がありますか？HCL Software DevOps の使命は、適切なデータを適切なタイミングで提供することで、製品チームがソフトウェア・デリバリー・パフォーマンスを向上させることです。

このトレンドをサポートするツール: HCL Accelerate

ガートナーのリストに追加するトレンドはありますでしょうか？コメントで教えてください。

2020/12/15 - 読み終える時間: 4 分

Why HCL Software DevOps deserves your vote in the DevOps Dozen Awards の翻訳版です。

HCL Software DevOps が DevOps Dozen Awards で皆様の投票に値する理由

2020年12月14日

著者: Elise Yahner / HCL Software DevOps

今年、DevOpsは、バーチャルカンファレンス、新しい電子書籍、製品のイノベーションなどを継続し、回復力のある業界であることを証明しました。「ニューノーマル」にもかかわらず、これらの活動は、デジタルトランスフォーメーションにとって意味があり、有用なものであることに変わりはありませんでした。

DevOps.com が主催する DevOps Dozen Awards は、DevOps コミュニティーの功績を称えるものです。6 年目を迎えた DevOps Dozen Awards は、コミュニティー賞とツール＆サービス賞の 2 つのカテゴリーに分かれた 20 の賞に拡大しました。コミュニティー賞」と「ツール＆サービス賞」の 2 つのカテゴリーに分かれています。コミュニティー賞は、プレゼンテーション、オピニオンリーダー、プロジェクト、イベント、研究を表彰します。ツール＆サービス賞は、CI/CD、VSM、テスト、セキュリティー、メインフレームのベンダーを表彰します。

HCL Software DevOps は、DevOps Dozen の 2 つのカテゴリーにノミネートされたことを誇りに思います。HCL Accelerate は Best Value Stream Management Tool にノミネートされ、HCL Launch は Best CI/CD Tool にノミネートされました。すべてのノミネート候補を確認し、ここで投票を行うことができますが、その前に、あなたの投票のために私たちの主張を述べさせてください。

HCL Accelerate が 2020 年のベストバリューストリーム管理ツールである理由

HCL Accelerate は、すべてのソフトウェア・デリバリー・ツールからのデータを単一のパイプライン・ビューに統一することで、DevOps の作業を可視化します。私たちは、スタンドアップの必要性を排除し、リモート作業を追跡するためのより良い方法を見つけることで、HCL Accelerate の力を私たち自身の開発チームで見てきました（そう、私たちは自分たちのシャンパンを飲んでいます）。HCL Accelerate は完全にツールに依存しません。つまり、HCL Software ファミリーの一部でなくても、すでに使用しているツールと統合されるため、ツールを破棄して交換することなく、データ駆動型の DevOps の利点を享受できます。今年は、これらの機能強化により、最高の VSM ツールをさらに優れたものにしました。

• スイムレーンビューでは、作業の状況や個々の貢献者がどれだけの作業をしているかを素早く完全に把握できます。
• ルールベースのゲートと手動ゲートにより、チームはパイプラインの段階に応じてゲートすることでガバナンスをシフトさせることができ、スループットを最適化しながらリスクを特定して低減できます。
• プラグイン SDK を使用して、洞察に富んだ意思決定に必要なツールやデータのための独自の統合を開発できます。
• 業界をリードするメトリクスを備えたすぐに使えるレポートやカスタム・ダッシュボードを使用して、より多くの情報に基づいた意思決定を行うことができます。

HCL Accelerate をオンデマンドのインタラクティブなデモでご紹介します（デスクトップでの閲覧が最適です）。

HCL Launch が 2020 年の最高の CI/CD ツールである理由

今年 6 月に HCL Launch を導入したことで、HCL Software は何十年にもわたって DevOps の基盤となっているツールを継続的に改善していくというコミットメントを固めることになりました。HCL Launch の素晴らしいところは、組織のニーズの変化やソフトウェアデリバリの最新のイノベーションに合わせて進化し続けていることです。HCL Launch は、真のプッシュボタンによる自動デプロイメントを提供し、メインフレームからマイクロサービスまで、あらゆるものを扱うことができます。今年 HCL Launch に追加された最新の機能の一部をご紹介します。

• 外部承認プロセスにより、Launch はデプロイの直前に、当社の膨大な統合ライブラリーを使用して外部システムにアクセスできます。
• デプロイのトリガーは、ビルド成果物がインポートされるとすぐにデプロイを自動化します。
• 再構築されたリソースツリーウィジェットは、ページのパフォーマンスと最適化を大幅に改善します。
• デプロイメントの保存と変更は、当社のカスタム "Processes as Code" 言語を使用して HCL Launch プロセスを表現することで、重要なデプロイメントプロセスへの変更を簡単に行い、追跡できます。
• モバイルフレンドリーなレスポンシブデザインにより、どのデバイスでもメール通知からデプロイメント承認を管理できます。

HCL Launch の詳細については、このデモビデオをご覧ください。

1月8日までに DevOps Dozen Awards に投票してください。受賞者は Predict 2021 バーチャルカンファレンスで発表されます。投票するにはここをクリックしてください。

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

More on Process as Code, new in HCL Launch 7.1.1 の翻訳版です。

HCL Launch 7.1.1 の新機能 Process as Code の詳細

2020年11月6日

著者: Madhavarao Kulkarni / Associate General Manager

HCL Launch は、プラグイン、徹底した REST API、簡単に設定できる統合機能のおかげで、構成が容易で信じられないほど拡張性の高い製品です。HCL Launch 7.1.1 のリリースでは、新しい Processes as Code 機能とそれに付随するユーティリティ "Processes as Code Compiler (PACC)" により、HCL Software の継続的なデリバリツールは、開発者や統合統合がさらに容易になりました。

PAC は、プロセスを作成するための命令をHCL Launchに提供するためのシンプルな言語を導入しています。このタイプのインターフェイスは、顧客が HCL Launch のプロセス作成を自動化に統合するために使用することができます。PAC の利点は以下の通りです。

• 理解しやすい言語
• 簡単にオンボードできます。以下に説明するように、ダウンロードコマンドを使用して既存のプロセスを PAC ファイル形式にすることで、PAC の理解を始めることができます。
• PAC コードを JSON に変換し、その逆も可能です。これは、PAC ファイルを素早く学習して使用し、コーディングにある問題を修正するのに役立ちます。
• PAC ファイルを使用して簡単かつ迅速にプロセスを作成します。
• このインターフェイスを使用して、必要なステップを持つプロセスをアップロードしてダウンロードすることができます。
• アップロードとダウンロードのコマンドは、許可されたユーザーがいないとプロセスをダウンロードしたりアップロードしたりできないように安全です。
• PAC を JSON に変換するコマンドとその逆のコマンドはパスワードを必要としません。

PACを使い始めるには

• HCL Launch サーバーを 7.1.1.1.0 にインストールまたはアップグレードします。
• ヘルプ->ツール->プロセス・アス・コード・コンパイラからサーバ上の任意の場所に PAC ツールをダウンロードしてください。
• フォルダに展開し、ccap, pacc, upload-, download- などのコマンドを使用して起動します。
• 言語の構文やコマンドの使用ガイドラインについては、readme.md ファイルを参照してください。

JPetstore プロセスを PAC フォーマットに変換する (例)

このチュートリアルで作成された JPetstore コンポーネントプロセスを以下に示しますが、PACC ユーティリティを使って変換した後の PAC フォーマットでどのように見えるか見てみましょう

JpetStore Web コンポーネントのプロセス HCL Launch からのデザインビュー

PAC ファイルに変換するには、このコマンドを使います。

download-component-process admin https://localhost:8443 1751e0fd-9502-e59c-4e93-9018d1ce2515 6 jpetWebProc.pac

それは以下のようになります。

start is
    start "Clean working directory"
end
plugin step "Clean working directory" is
    plugin "File Utils"
    command "Delete Files and Directories"
    property "baseDir" = "."
    property "includes" = "**/*"
    property "excludes" = ""
    property "followSymlinks" = "false"
    property "caseSensitive" = "true"
on success
    start "Download Artifacts"
end

plugin step "Download Artifacts" is
    plugin "UrbanCode Deploy Versioned File Storage"
    command "Download Artifacts"
    property "directoryOffset" = "."
    property "artifactSetBaseDir" = ""
    property "fileIncludePatterns" = "**/*"
    property "fileExcludePatterns" = ""
    property "syncMode" = "true"
    property "handleIncrementalVersions" = "false"
    property "fullVerification" = "true"
    property "setFileExecuteBits" = "false"
    property "verifyFileIntegrity" = "false"
    property "charset" = ""
    property "versionId" = "${p:version.id}"
    property "versionType" = "${p:version.type}"
    property "serverUrl" = "${p:server.url}"
    property "compId" = "${p:component.id}"
    property "resId" = "${p:resource.id}"
    property "envId" = "${p:environment.id}"
    property "maxMemory" = "1G"
    property "label" = ""
on success
    start "Start Tomcat"
end

plugin step "Start Tomcat" is
    plugin "Tomcat"
    command "Start Tomcat"
    property "launcherLocation" = "${p:environment/tomcat.start}"
    property "options" = ""
    property "timeout" = "60"
    property "port" = "8085"
    property "hostname" = ""
    property "catalinaBase" = ""
    property "catalinaHome" = ""
    property "javaHome" = ""
on success
    start "Undeploy Application"
end

plugin step "Undeploy Application" is
    plugin "Tomcat"
    command "Undeploy Application"
    property "tomcatManagerUrl" = "${p:environment/tomcat.manager.url}"
    property "tomcatUsername" = "tomcat2"
    property "tomcatPassword" = "****"
    property "tomcatContext" = "/${p:environment/tomcat.contextroot}"
on complete
    start "Deploy Application"
end

plugin step "Deploy Application" is
    plugin "Tomcat"
    command "Deploy Application"
    property "tomcatManagerUrl" = "${p:environment/tomcat.manager.url}"
    property "tomcatUsername" = "tomcat2"
    property "tomcatPassword" = "****"
    property "tomcatContext" = "/${p:environment/tomcat.contextroot}"
    property "warFile" = "./JPetStore.war"
    property "configFile" = ""
on success
    finish
end

今後の複雑なプロセス設計で使用するための様々なステップ、プロパティ、ステップ入力値の必要な PAC コードスニペットを理解するために、コンポーネントプロセスを作成し、以下のコマンドを実行してください。

download-component-process <userid> <server_url> <Component_Template_Process_Id> <testdata.pac>

また、PAC コードでどのように表現されているかを知り、PAC をよりよく理解するために、以下の手順を試してみてください。

• 複数のコンポーネントをインストールする
• 複数のコンポーネントのアンインストール
• 複数のコンポーネントの運用プロセスを実行
• 複数のコンポーネントをロールバック
• 各影響を受けるリソースに対して GenericProcess の実行
• ロックの取得と解除
• Status の設定
• Warning の追加
• Switch
• Join
• Note
• Run Generic Process
• Manual Application Task
• For Each Agent
• For Each Tag

HCL Launch における Process as Code の詳細については、こちらのブログ記事をお読みください。

2020/10/29 - 読み終える時間: 5 分

Processes as Code in HCL Launch の翻訳版です。

HCL Launch における “Process as Code”

2020年10月28日

著者: Hayden Schmackpfeffer / Product Manager

導入とユーティリティー

HCL Launch version 7.1.1.0 で追加されたエキサイティングな新機能の1つは、Web UI の外でアプリケーションやコンポーネントのプロセスを設定できることです。HCL Software の “Process as Code” フォーマットにより、開発チームはプロセスを定義し、簡単に変更可能なフォーマットで保存することができます。

HCL Launch サーバーには、いくつかのコマンドで構成されたユーティリティである Process as Code Compiler がバンドルされています。その主な目的は、Launch サーバーと対話し、PAC フォーマットと Launch サーバーによって理解される JSON フォーマットの間で変換することです。

最も便利なコマンドは upload と download です。これらのコマンドには、download-component-process、download-application-process、upload-component-process、upload-application-process の 4つがあります。

ダウンロードコマンドは、Launch 内のプロセスの特定のバージョンを指し示し、そのプロセスをダウンロードし、PAC 形式に変換して保存します。

download-<process-type>-process <user-name> <server-url> <process-id> [<version>|latest] output.pac

アップロードコマンドは逆のことをします; アップロードコマンドはローカルの PAC ファイルをサーバーが期待する JSON フォーマットに変換し、指定されたプロセスの新しいバージョンとしてアップロードします。

upload-<process-type>-process <user-name> <server-url> <process-id> <next-version | latest> input.pac

pacc スクリプトはローカルに保存されている Launch JSON ファイルを PAC フォーマットに変換し、 ccap スクリプトは PAC から JSON フォーマットに変換します。

基本的な構文

PACC ユーティリティの README には、私たちが定義したカスタム構文の詳細な説明が含まれていますが、ここでは基本的なことを説明します。

• "start" と "finish" は、プロセスの入口と出口を表すために使用されます。
• "start " は、定義されたステップを呼び出すために使用されます。
• "plugin step is" は、ステップを定義し、設定します。この一般的な構文は任意のプラグインコマンドを指定することができ、"shell" のような一般的に使用されるステップのための短縮記号があります。
  • "plugin" は使用するプラグインを指します。
  • "command" は、そのプラグインの中で使用する特定のプラグインステップを指します。
  • "on [success | failure | complete]" は、特定のステップが終了した後に実行されるその後のステップを定義する。
  • "property " = " は、プラグインのステップフィールドの値を指定します。

ここでは、シンプルな Tomcat ウェブアプリケーションのアーティファクトセットをダウンロードし、Tomcat プラグインを使用してアプリケーションをデプロイする小さなコンポーネントプロセスの例を示します。

start is
    start "Download Artifacts"
end

plugin step "Download Artifacts" is
    plugin "UrbanCode Deploy Versioned File Storage"
    command "Download Artifacts"
on success
    start "Deploy Tomcat Application"
end

plugin step "Deploy Tomcat Application" is
    plugin "Tomcat"
    command "Deploy Application"
    property "tomcatManagerUrl" = "${p:environment/tomcat.manager.url}"
    property "tomcatUsername" = "exampleTomcatUser"
    property "tomcatPassword" = "${p:environment/secureTomcatPassword}"
    property "tomcatContext" = "/TestA"
    property "warFile" = "./TestApp.war"
    property "configFile" = ""
on success
    finish
end

この例では、Deploy Application ステップのための特定のプロパティを明示的に定義していますが、成果物のダウンロードコマンドは基本的に空のままにして、ステップのデフォルト値を使用しています。PAC プロセスは HCL Launch に直接アップロードされ、サーバーが理解できる形式に変換されているので、プロパティを参照することができます。

始めるには、既存の Launch プロセスを PAC フォーマットに変換するためにプロセスのダウンロードコマンドを使用し、PAC の変更の出発点として使用することをお勧めします。

私は現在、開発用 Launch サーバー上のデプロイメントプロセスを Processes as Code とカスタム githook を使って管理しています。サーバー上で管理したいプロセスは、以下のディレクトリ構造を使って「deployment-processes」リポジトリに格納しています。

Deployment-processes/<processType>/<nameOfComponentOrApplication>/<ProcessID>.pac

これにより、変更した .PAC ファイルのパスには、コミット時に処理をアップロードするために githook が必要とするすべての情報が含まれていることが保証されます。この例では、ブランチにコミットしたらすぐにアップロードするために post-commit フックを使用していますが、toy 以外の例では、git サーバー側の pre-receive フックや post-receive フックのほうが適切です。

下の githook の例は python で書かれたもので、pexpect ライブラリを使用しています。現在のバージョンの PAC ユーティリティでは、Launch サーバーとやりとりするときにパスワードを手動で入力しなければならないという事実を回避しています。

#!/usr/bin/env python3 
from subprocess import check_output
import pexpect
import json
TYPE = 0
NAME = 1
ID = 2
username = ''
password = ''
serverUrl = ''
# returns tuple of type, name, processId
# assumes files are appropriately structured
def parseTargetsFromFile(filepath):
    #component/testComponent/175427f6-0a8b-93b4-d73a-6a8ba534b060.pac
    targets = filepath.split('/')
    filename = targets[ID]
    return targets[TYPE], targets[NAME], filename[:filename.index(".")]
def uploadProcess(cmd):
    child = pexpect.spawn(cmd)
    try:
        i = child.expect([pexpect.TIMEOUT,'password:'])
        if i == 0:
            print("Got unexpected output: %s %s" % (child.before, child.after))
        else:
            child.sendline(password)
        child.read()
    except:
        print("Problem encountered: ")
        print(str(child))
def uploadChangedProcesses():
    # git diff-tree -r --name-only --no-commit-id HEAD
    changedFiles = check_output(['git', 'diff-tree', '-r', '--name-only', '--no-commit-id', 'HEAD']).decode()
    lines = changedFiles.splitlines()
    for line in lines:
        print(f"uploading pac file: {line}")
        line = str(line)
        targets = parseTargetsFromFile(line)
        cmd = buildCommand(targets, line)
        uploadProcess(cmd)

def buildCommand(targets, filename):
    return f"upload-{targets[TYPE]}-process {username} {serverUrl} {targets[ID]} latest {filename}"
if __name__ == "__main__":
    with open('conf.json') as confFile:
        conf = json.load(confFile)   
        username =  conf['username']
        password = conf['password']
        serverUrl = conf['url']
    uploadChangedProcesses()

上記のスクリプトをポストコミットフックとして保存し、私のPACファイルに修正をコミットすると、それらのファイルは、以下のように私のLaunchサーバー上で同じIDを持つプロセスの最新バージョンとしてアップロードされます。

HCL Launch 7.1.1.1 の他のアップデートと一緒に、新しい "Processes as Code "機能が実際に動作しているのを見たい方は、こちらから登録してウェビナーに参加してください。

2020/10/28 - 読み終える時間: 2 分

What's new in HCL Launch 7.1.1.0 の翻訳版です。

HCL Launch 7.1.1.0 の新機能

2020年10月27日

著者: Hayden Schmackpfeffer / Senior Developer

HCL Launch バージョン 7.1.1.1.0 では、これまで以上にデプロイメントの経験を向上させるために、信じられないほどの新しい機能と強化が追加されています。このリリースに含まれている機能セットは、デプロイメントの表示と設定がこれまで以上に簡単になり、QOL を向上させます。

HCL Launchアプリケーションとコンポーネントのプロセスを人間が読みやすい速記法で定義できる新しい言語を作成しました。当社の "Processes as Code" 言語を利用するために、"Tools" セクションに Processes as Code コンパイラが含まれており、既存のプロセスをダウンロードしてPACフォーマットに変換したり、指定したLaunchサーバに直接PACファイルを翻訳してアップロードすることができます。より詳細な情報は、近日中に詳細なフォローアップ記事でご紹介します。

新しい "Get Started" ページでは、HCL Launch と HCL Software DevOps に関する膨大な情報のリポジトリを、あなたの指先に置いています。アプリ内のチュートリアルの代わりに、このページでは、HCL Launch のチュートリアルのほか、ドキュメント、リリースノート、ビデオコンテンツ、そしてこのブログへのリンクが用意されています。ナビゲーションバーの "HCL Launch" セクションをクリックするか、ヘルプドロップダウンの "Get Started" オプションをクリックして、いつでもこのナレッジストアにアクセスしてください。

このリリースでは、便利なメールリンクを介して承認タスクに対処する機能を使用して、チームのデプロイメントを外出先でも管理することができます。バージョン7.1.1.1.0に含まれているデフォルトの通知テンプレートには、電子メールを受信したユーザーに関連付けられた応答URLが埋め込まれています。

このリンクをクリックすると、ユーザーは割り当てられたタスクを承認または拒否するためのモバイル応答ページに移動します。このリンクは、添付されたタスクへの応答にのみ使用でき、5日後に有効期限が切れます。既存のメールテンプレートはアップグレード時に保存されるため、お使いのサーバーがv7.1.1.1.0以前にインストールされていた場合は、承認とタスク通知のテンプレートXMLを変更して、応答URLを含める必要があります。この設定方法については、サポートチームまでお問い合わせください。

設定タブの新しいページでは、すべてのタグ付け可能なオブジェクトを俯瞰的に見ることができます。オートメーション設定の下の "タグ "ページには、エージェント、アプリケーション、コンポーネント、またはリソースのために作成されたすべてのタグを一覧表示するテーブルがあります。

これらのテーブルは、特定のタグのセットを表示するためにフィルタリングしたり、既存のタグ定義を変更したりすることができます。既存のタグの名前、説明、および色を変更することができ、そのタグは、タグが与えられたすべてのオブジェクトで更新されます。

また、ライセンス設定をシステム設定ページの外に移動し、ライセンスサーバー接続に特化した新しいページに移動することで、ライセンス設定を刷新しました。このページでは、接続の詳細を入力し、HCL Launchがライセンスサーバーへの接続に成功すると、ライセンスの使用状況に関する情報が表示されます。

11月5日（木）午後3時（米国東部標準時）に開催されるウェビナーでは、これらの新機能を実際にご覧いただけます。ライブ・ウェビナーに参加できない場合でも、ご登録いただければリプレイへのリンクをお送りします。ウェビナーに登録するには、ここをクリックしてください。

HCL Launchがあなたの生活をどのように楽にするかについて、他にもアイデアがありますか？こちらのアイデアポータルに投稿してください。

2020/9/30 - 読み終える時間: 2 分

HCL Launch – In Love with Snapshots の翻訳版です。

HCL Launch - スナップショットに恋して

2020年9月29日

著者: HCL Software

アプリケーションをサーバにデプロイする際の最大の課題のひとつつは、すべてのシステム要件が必要な構成で設定されていることを確実にすることです。アプリケーションが配置されなければならないすべてのサーバの手動チェックと設定は、面倒で、面倒で、エラーが発生しやすいものです。これが単一の変更のデプロイの場合は、3000以上の変更と数千台以上のサーバへのデプロイの場合を考えてみてください。このような懸念に対処するために、HCL Launchの スナップショット機能を効果的に使用できます。

スナップショットとは何ですか？

HCL Launch では、スナップショットは、単一のデプロイ可能なユニットを表すコンポーネント/バージョンの関連付けのバンドルです。

スナップショットは、アプリケーションが正常にデプロイされた環境で作成されたすべての構成のコピーを作成し、この構成の詳細を使用して、最も成功する可能性の高いいくつかの本番環境/サーバーにアプリケーションをデプロイするために使用できます。

言い換えれば、スナップショットはデプロイを実行する必要があるサーバー/環境のすべての設定を処理します。

スナップショットには、ユーザーがスナップショットの構成をロックできる機能もあり、デプロイを成功させるためにすべてのリソースの構成を保持しながら、ユーザーがスナップショットの外で関連する構成を変更できる柔軟性を提供できます。スナップショットの構成がロックされると、それを元に戻すことはできません。このように、スナップショットを活用して、デプロイメントのあらゆる複雑な詳細を設定できます。

クオリティゲートを使用したスナップショット

HCL Launch では、品質ゲートを環境に設定して、特定の基準を満たすコンポーネントバージョンのアーティファクトのみのデプロイを確実にすることができます。

アプリケーションのデプロイがスナップショットを使用して実行されると、各スナップショット内の単一のコンポーネントバージョンが品質ゲート要件に準拠していない場合でも、デプロイは「ワークフローを開始するエラー」というエラーで中止されます。プロセスを開始できませんでした。<コンポーネント名> <バージョン番号>は、この環境にデプロイするのに必要なステータスを達成していません。完全なエラートレースについては、サーバーログを参照してください。

スナップショットと品質ゲートの関係を理解することが不可欠なのはなぜですか？スナップショットが特定のリリースの構成のゴールドコピーであっても、スナップショットのコンポーネントバージョンの1つに深刻な問題がある場合があり、このバージョンは、品質ゲートによってブロックされている特定のステータスを割り当てることでデプロイからゲートされ、スナップショットが各バージョンをデプロイできないようになっている場合があります。スナップショットと品質ゲートを組み合わせることで、本番環境で品質の高いデプロイを成功させることができます。

アプリケーションプロセスのスナップショットと現在のバージョン

アプリケーション・プロセスのバージョン・プリセットは、アプリケーションプロセスがデフォルトで使用するコンポーネントバージョンを設定できる機能です。

ユーザーがアプリケーションプロセスのバージョンプリセット設定をバイパスするオプションや回避策を探している場合は、スナップショットを使用して実現できます。

スナップショット設定の[事前設定]タブで、ユーザーは、バージョンプリセット設定の詳細を持たない各アプリケーションプロセスの特定のバージョンを選択でき、デプロイメントをプリセットバージョンではなく、スナップショットで設定されたコンポーネントバージョンで実行できます。

ロールバックが簡単に

本番環境でデプロイに障害が発生し、本番環境を確実にバックアップするためには、すべての障害を分析する必要があります。デプロイメントを以前のバージョンにロールバックして、設定からデプロイまでのすべてのステップを踏んで、デプロイメントプロセスを最初のステップからやり直す必要があります。これにはかなりの時間がかかります。

スナップショットを使用すると、このプロセスがはるかに簡単になります。デプロイに失敗した後、以前にデプロイされたスナップショットを使用して、デプロイ可能なコンポーネントを再デプロイできます。

スナップショットは、HCL Launch の非常にリソースの多い機能であり、管理が容易な高速で堅牢なデプロイメントを保証します。特に手動でのデプロイのセットアップが苦手な人は、スナップショットを気に入ることでしょう。