2020/9/29 - 読み終える時間: 4 分

Mainframe Deployment Process with HCL Launch の翻訳版です。

HCL Launch によるメインフレーム展開プロセス

2020年9月28日

著者: Elise Yahner / HCL

HCL Launch は、メインフレームからモバイルまで、すべてのプラットフォームにデプロイできるエンタープライズワイドなデプロイツールです。IBM IでRPGプログラムをデプロイする場合でも、IBM ZでCOBOLをデプロイする場合でも、分散システムにJavaをデプロイする場合でも、そのすべてを HCL Launch を介して行うことができます。

z/OS のデプロイには、いくつかの特定のカスタマイズが必要であることは理解しています。HCL Launch は、z/OS で非常に一般的なインクリメンタルバージョンをサポートしています。HCL Launch は、バージョンをマージしたり、デプロイ時間を短縮するための成果物のデルタデプロイを行ったりすることをサポートしています。HCL Launch は、環境にデプロイされたバージョンを見つけるために、アーティファクトの検索をサポートしています。

HCL Launch は、成果物のパッケージングを支援します。HCL Launch には、 z/OS の成果物をパッケージ化するためのbuzztoolと呼ばれるユーティリティがあります。

このブログでは、シンプルなメインフレームのデプロイメントプロセス設計についてお話します。メインフレームのデプロイメントのためのシンプルなコンポーネントプロセス設計は、以下のステップを持っています。

• z/OS 用のアーティファクトをダウンロードする。
• データセットのデプロイ
• アーティファクト情報の生成
• DB2 DBRMをバインド
• ニューコピーCICSリソース
• トークンの置き換え

z/OS 用のアーティファクトをダウンロードする

このステップでは、デプロイするバージョンのアーティファクトを Launch の内蔵アーティファクト・リポジトリ ? Codestation からターゲットのメインフレーム LPAR にダウンロードします。アーティファクトをArtifactoryやNexusなどの外部アーティファクト・リポジトリに保存している場合は、このプラグインを使用してターゲットのメインフレームLPARへのダウンロードを行うことができます。

通常、このステップでは、設定するための特別な入力は必要ありません。

データセットの配置

このステップでは、ターゲット・メインフレームLPARのUSSフォルダ/PDSメンバーにデプロイします。前のステップからダウンロードした成果物と、ステップのプロパティで提供されたDatasetマッピングを使用して、それらをターゲット・データセットにマッピングします。

通常、Datasetマッピング (およびデプロイメントプロセスの他の多くのプロパティ) は、環境プロパティとして構成されます。このようにして、新しいターゲット環境が作成されたときに、これらの環境固有のプロパティを環境レベルで定義することができます。

データセット マッピングのサンプルを以下に示します。これは、source_pds , target_pds の形式です。source_pdsは、buztoolを使用してバージョンを作成する際にシップリストで使用されたPDS名です。これらは開発環境の pds 名です。これらは、HCL Launch UIでバージョンを見たときに表示される名前です。(Components -> YourComponentName -> Versions -> YourVersionName) となります。Target_pds は、デプロイが必要なこの環境の pds 名です。

Deploy datasets には "Backup for Rollback" のフラグがあります。チェックを入れると、このステップでは、デプロイ前に置き換えられる予定の現在のPDSメンバーがバックアップされます。この内蔵のバックアップ/ロールバック機能は、HCL Launch Mainframeプラグインに特有のものです。バックアップはターゲットLPARのUSSに保存され、必要に応じて "Rollback Dataset "ステップで使用されます。

ターゲットLPARにデータセットがまだ存在していない場合、プラグインがデータセットを作成できるようにするデータセット作成を許可するように設定できます。

アーティファクト情報の生成

PDSへのデプロイが完了した後、通常、バインド、ニューコピーなどのデプロイ後のステップがあります。このステップは、デプロイ後のプロセス（例えば、バインド）を経る必要があるアーティファクトを特定するのに役立ち、また、テンプレートからそれぞれのアーティファクトのためのコマンド（例えば、バインドカード）を生成します。異なるアーティファクトのセットに対して複数のコマンドを生成できる新しいプラグインがあります。

このステップでは、ソース PDS 名 (コンテナ名)、ターゲット PDS 名、デプロイタイプ、あるいは独自のカスタムプロパティを使用して、成果物をフィルタリングするのに役立ちます。

次に、以下に示すようなJSONテンプレートを提供し、異なるテンプレートを使用して異なる出力プロパティを生成することができます。これらの出力プロパティは、デプロイ後のステップで参照することができます。1つのステップから任意の数の出力プロパティを生成することができます。

ジョブのバインド

DB2 のバインドは、"Submit Job" プラグインのステップでジョブを投入し、前のステップで生成されたバインドパラメータを使用して行われます。

CICS のNewcopy

CICS の Newcopy は、CICS TS プラグインと上記で生成された CICS プログラムのリストを使用して行われます。

トークンの置換

通常、メインフレームのデプロイメントでは、${HLQ}をその環境の高レベル修飾子に置き換える必要がある場合があります。例えば、JCLの場合。JCLのテンプレート化されたバージョン (あるいはDB2のDML文のような他の成果物) をSCMに格納することができます。そして、各環境は、アプリケーション環境プロパティに HLQ/DB2 スキーマ名を設定することができます。

このステップでは、デプロイ後のターゲット環境のすべてのトークンを、その環境固有の値に置き換えることができます。これにより、テンプレート化されたバージョンをSCMに保存し、デプロイツールに環境固有の値を置換させることが容易になります。

スイッチのステップ

上記のプロセス設計の中で、スイッチのステップがあることに気づいたかもしれません。これらのステップは、プロパティ値に基づいてどのパスを取るかを決めるのに役立ちます。このケースでは、バインドするものが何もない場合に、Bind のような展開後のステップをバイパスするためにスイッチ・ステップを使用しています。

Generate Artifact ステップは、出力プロパティごとにカウント変数を生成します。bindCardのカウントが0以外の場合、バインドステップが実行され、それ以外の場合はスキップされます。これは必要なければ、デプロイ後の多くのステップをスキップするための優れた方法です。

HCL Launch でプラグインを設定する際にヘルプが必要ですか。サポートチームに連絡してください。

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

How HCL Launch enables enterprise-level DevOps の翻訳版です。

HCL Launch がエンタープライズレベルの DevOps を実現するしくみ

2020年8月28日

著者: Madhavarao Kulkarni / Associate General Manager

業界を超えた迅速なソフトウェア開発の需要の高まりにより、複雑なDevOpsのセットアップが必要になることがあります。開発ライフサイクルの短縮、デプロイの失敗の減少、コミュニケーションの効率化、コスト削減などの高度な機能が、DevOpsソリューションとサービスの需要を後押ししています。市場投入スピードの重要性が高まる中、企業は迅速な開発とデプロイメントのためにDevOpsソリューションを採用し、手動プロセスを大幅に削減してコーディング・エラーを削減しています。

これは実際にはどのようなものなのでしょうか？ HCL Launch は、最も複雑なデプロイメントを処理し、大企業のために迅速なソフトウェアのアップグレードを可能にするように構築されています。

図: HCL Launch がメインの IT アプリケーションとして使用される典型的な継続的デリバリーパイプライン

エンタープライズユースケース - DevOps を実現する単一の IT Webフォーム

開発チームが、ボタンをクリックするだけで簡単にインフラを手に入れたいと思っていると想像してみてください。開発チームは、簡単なフォームに記入して、物事を完了させるために IT に助けを求めるでしょう。このプロセスは、開発ツールやビルド＆パッケージツールからは単純に見えますが、デプロイメントフェーズやリリースフェーズからは複雑になります。しかし、デプロイフェーズからリリースフェーズになると複雑になります。

複雑なフェーズ

複雑な組織では、以下のような主要なグループがそれぞれ異なる方法でITを管理しており、それぞれが好ましいツールを持っています。効果的な DevOps を提供するためには、すべてが単一のフォームの下に置かれなければなりません。

• オンプレミス、クラウド向けの IT インフラストラクチャのプロビジョニングツール
• 開発と継続的な統合ツール
• デプロイメントとリリースツール
• ユーザーアクセス管理ツール

HCL Launch は、多くのITツールのセットと統合するのに適しており、継続的なデプロイメントを実現するために、開発チームの要求をそれにマッピングするための簡単なオプションを提供します。HCL Launch の大きな特徴の1つは、テンプレートのコンセプトを通して、IT ヘッドの「シングルフォーム」インフラストラクチャの要求を満たしていることです。ユーザーのウェブフォームで定義したものが、HCL Launch のテンプレートとして機能します。

デプロイとリリースのフェーズでは、以下のことを効率的かつミスなく完了させる必要があります。

• アプリケーションを、異なるスクラム/マイクロサービスチームによって開発されたいくつかの成果物の束として可視化する
• 異なるバージョンの成果物を含むアプリケーションを、成果物に変更を加えることなく、安全に Dev-QA-Stage-Prod 型の環境にスムーズに移行させる
• デプロイ、ロールバック、監査を週単位で数回実施する
• この規模のオンプレミスとクラウドインフラへのデプロイメントで 100 のアプリケーションをサポートする
• 適切なチームが成果物のデプロイの適切なセットで動作していることを確認する
• 自動および手動の承認プロセスのオプションを提供する
• 成果物を取得し展開するために、IT ツールに広い範囲で統合する

最後に、異種プロセスを管理し、追跡するのは非常に複雑なので、すべてのエンタープライズアプリケーションが同じ成熟度レベルに入ることを保証する責任があることを覚えておいてください。あなたは、上記の各質問のテンプレートを用意しておく必要があります。これを超えて、成功した DevOps は以下のことを必要とします。

• 最高レベルのフルアプリケーションをデプロイするためのオプションを提供すること
• アプリケーションのフルリリースではなく、影響を受けるモジュールやコンポーネントに基づいて部分的にデプロイすること
• 可能な限り迅速かつ容易なロールバック

複雑なフェーズを単純化するための HCL Launch のキーコンセプト

HCL Launch では、以下のように、ソフトウェアアプリケーションを可視化するための非常にシンプルな定義を提供しています。

• アプリケーション
• コンポーネント
• 環境への取り組み
• リソース
• プロセス
• チーム
• カスタマイズを制御するプロパティ

これらのキーコンセプトを適用することで、上記のユースケースで見てきたすべての基準を満たすような小規模なアプリケーションや大規模なアプリケーションを定義できます。

なぜ HCL Launch がここで正しい選択なのでしょうか？

• テンプレート: HCL Launch は、アプリケーション、コンポーネント、エージェント、プロセス、リソース、チームなどのテンプレートを提供します。

• API ファーストのアプローチ: HCL Launch は API ファーストのアプローチを信じており、APIを介してほぼすべての機能を提供しており、あらゆる規模の企業に容易に統合できます。

• サーバ & エージェントのモデル: アプリケーション・リソースを簡単に定義し、必要に応じてプラグ・プレイができます。デプロイメントのためのインフラストラクチャの健全性と稼働時間を確保するのに役立ちます。

• プラグインを使った IT ツールとの連携・統合: HCL Launch が提供するいくつかのプラグインは、最も一般的なDevOpsツールとの統合を可能にし、デプロイとオーケストレーションのプロセスを定義します。また、独自のツール用に独自のプラグインを作成できます。

• デプロイメントカレンダー: シンプルなデプロイメントカレンダーを保持して、ITにおける全体的なデプロイメントを可視化します。

• コンプライアンスのための監査？デフォルトでは、すべての活動を追跡するために監査情報を提供し、デプロイメントは、コンプライアンスのためにいつでも参照してください。

• 成長管理: デプロイメントに最適なものを提供する場合、HCL Launch を使用したアプリケーションの数の増加を期待できます。HCL Launch は、HAトポロジー、エージェントリレー、アクティブアクティブサーバー、分散フロントエンドなどを提供します。

よく定義された継続的なデプロイメントは、エンタープライズ向けの強力なリリース管理プラクティスを可能にし、よく定義された継続的なデプロイメントは、HCL Launch によって達成されます。

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

デプロイメントツールである HCL Launch がダウンすることで影響がでないように、高可用性を確保することが重要です。それについて書かれた英語版ブログの記事 Planning for High Availability of HCL Launch の記事です。

HCL Launch の高可用性について計画作成

2020年8月14日

著者: Madhavarao Kulkarni / Associate General Manager

IT 標準の要件の 1 つは、優先度の高いすべてのツールに高可用性を提供することである。この点で使用される最も有名な用語は、高可用性(HA)、冗長性、ディザスタリカバリ(DR)です。IT部門は、いくつかのアプリケーションに対してこのようなセットアップを行っているかもしれませんが、アプリケーションは多くの面で異なるため、アプリケーションごとに「何をすべきか、どのようにすべきか」を知っておくことは理にかなっています。HCL Software のお客様のために、この記事では、HCL Launch に関する有益な情報を提供したいと思います。

高可用性を達成するためのフェーズ

• 高可用性を必要とする背景
• HA/DR/リダンダンシーでの業務開始のための業務明細書
• HAを表現するための展開計画
• タイムラインと取り組み
• 予算の検討
• 重要なことを見逃さないための実行計画

HAの背景

まず、何を設定しようとしているのかを確認しておきましょう。

高可用性 (HA) - 使用量が増加している場合、パフォーマンスが重要になっている/パフォーマンスの問題を解決しなければならない場合、ビジネスクリティカルなアプリケーションやSLA駆動のアプリケーションのダウンタイムゼロを達成することができます。

ディザスターリカバリー(DR) - アプリケーションがデータセンターのいかなる災害に対しても回復可能であることを保証しなければならない場合。

冗長性 - アプリケーションが応答時間で改善され、より多くの要求を処理したり、期待される応答基準を提供する場合

それぞれが似たようなケースもあるが、重要なポイントは「何を目標にしているか」を決めなければならないということだ。一部の組織では、DR を確保するためにコンプライアンスの必要性があるので、それを実行しなければならない。他のケースでは、成長、パフォーマンス、標準などの他の要件に追われている。高可用性のために行かなければならないかどうかを決定したら、我々はそれが冗長性か HA かを考えなければならない。

成果物: ユースケース、アプリケーションのパフォーマンス/採用、ダウンタイムや収益への影響の数字、将来の成長率のメトリクス。

HAのためのビジネスステートメント

ビジネスステートメントは、「重要なエンタープライズアプリケーションの HCL Launch へのオンボードを開始したい」とか、「HCL Launch のダウンタイムがゼロになるようにしたい」というようなものです。これは、なぜHAを達成しなければならないのかという方向性と明確さを与えてくれます。HCL Launch の中で、新しいサーバーやリレーを追加して水平展開することで実現できるアプリケーションの数が増えているのであれば、HA のために頑張る必要はありません。そのため、この時点では成果を重視してください。

成果物: ミッションステートメントの詳細、実行、予算、スケジュール、各ステークホルダーの承認などが記載された文書。

期待される事業目標を達成するための展開計画

基本的なリファレンスとして当社の展開図を使用して、サーバー名、地理的な場所、データセンター間のネットワーク遅延、容量などのラベルで図を覆って、組織のために 1 つの図を作成することで、図は多くの情報を提供するようにしてください。その良い負荷要因を言及することによって、それらに期待される負荷を置くことができます。ITの情報を示すようにしようとすると、ストレージ、レプリケーションの必要性（はい/いいえ）、計算の詳細のように尋ねます。ファイアウォール、データセンター名、地理的な場所を含むだけでなく、ラベルポートと通信の有効化計画。あなたは、ネットワークチームと協力する必要があるかもしれません]。

成果物: 洞察力に富んだアプリケーション展開の現在および将来の状態を表現したもの、あなたの組織に特有のチェックリスト、将来のアップグレードのためのチェックリスト、サポート、およびその他の IT の定期的な取り組みを網羅したもの。

タイムラインと努力

調達から展開までのタイムライン計画を作成します。また、ダウンタイムや、あなたのグループと一緒に作業しなければならない他のチームのように整列させる。ネットワーク、データベース、ストレージ、コンピュート、HCL Launch のサポートのように、すべての利害関係者（チェックリストの利害関係者がリストされていることを確認してください）とのタイムラインのレビューを得るための良い練習になります。

成果物: タイムライン情報、ステークホルダーリストと承認、イベントとリード情報。

予算

予算の計画を立てる際には、以下のことを考慮してください。

• HCL Launch のライセンス費用の予算 [各サーバーにかかる費用]について
• 計算、ストレージ、データベースの追加ライセンスのコスト
• バックアップ戦略とコストは、クロスチャージとして組織内のアプリケーションの場合
• 人工コスト

実行計画

実行計画には以下のものが必要です。

• 必要なものの一覧
• サポートチケットのステータス、ステータス、承認
• ダウンタイムウィンドウ
• ロールバックプラン
• テストのチェックリスト
• HCL Launch に期待するサポートのレベルを確認する
• HCL Launch チームにアップグレード計画を伝えるためのサポートチケットを作成し、それは HCL Software が最高のサポートを提供するのに役立ちます。
• 選択したソフトウェアのバージョン一覧 [選択したバージョンのサポート終了情報にご注意ください] ※選択したソフトウェアのバージョン一覧
• HCL Launch で他の製品との統合を使用している場合は、新しい展開計画での動作を確認するためにチェックリストを作成してください。
• 実行中の問題をトラブルシューティングするために、ネットワーク、アプリケーション、統合、プラグインなどのレベルでロギングを有効にするためのチェックリスト

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

HCL AppScan on Cloud と HCL Launch を組み合わせることで、安全ビルドの管理・デプロイを制御しながら運用することについて、英語版ブログの記事 Adding Security to Continuous Delivery を掲載します。

継続的なデリバリーにセキュリティーを追加する

2020年8月7日

著者: Brian Stump / Product Specialist, HCL

物事がうまくいっているときは素晴らしいことだと思いませんか？これは、当社の継続的なデリバリとソフトウェア・セキュリティー・ツールを使用して得られる感覚です。HCL Launch は、AppScan on Cloud (ASoC) と一緒に、自動化、レポート作成、リリース管理を含む DevOps ライフサイクル全体の中で、アプリケーションのセキュリティを自動制御する機能を提供してくれます。

HCL Launch は、ASoC プラグインの出力を処理し、それに応じてビルドを処理できます。ビルドが低レベルの環境に正常にデプロイされたが、深刻度の高い問題で Dynamic ASoC スキャンに失敗した場合、HCL Launch は自動的に最後にデプロイされたバージョンにロールバックし、問題があることを示すステータスでビルドをマークします。ASoC があなたのビルドの中でそれほど深刻ではない問題を識別した場合、HCL Launch は「デプロイメント警告」を表示しますが、ターゲットマシンにインストールされたままにしておきます。そして、もし ASoC が重大な問題を発見しなかった場合、HCL Launch はそのバージョンに AppScan のすべてのスキャンに合格したことを示すアプリのステータスを与えます。言い換えれば、HCL Launch は、AppScan の承認に合格しない場合、Prod やその他の高レベルの環境へのデプロイを防げる環境ゲートを作成します。

ソフトウェアのデプロイメントにおけるセキュリティを簡単にする準備はできていますか？HCL Launch を使用してデプロイメントを実行し、ASoC セキュリティースキャンを開始するパイプラインをセットアップする方法について説明します。

HCL Launch の構成

HCL Launch には、AppScan on Cloud 用の無料でインストール可能なプラグインがあります。このプラグインには、AppScan サーバー上で以下の各作業を行うための手順が含まれています。

• ASoC プレゼンスの作成
• ASoC プレゼンスの削除
• ASoC のプレゼンスを開始
• Start Android Mobile Analyzer ASoC Scan
• Dynamic Analyzer ASoC Scan の起動
• Static Analyzer ASoC Scan の開始
• iOS Analyzer ASoC Scan の起動
• ASoC の存在の停止

このシナリオでは、ASoC で静的スキャンと動的スキャンを同時にキックオフするワークフローを設定します。以下の手順とスクリーンショットでは、HCL Launch プロセスを構成する方法を説明します。

各HCL Launch プラグインのステップは、ASoC アプリケーションID、キーID、およびキーシークレットを設定する必要があります。

スタティック アナライザー ステップでは、スキャンのためにアップロードされる IRX ファイル、またはスキャンするファイルやその他の場所を含むディレクトリーのいずれかを指す IRX ファイルも必要です。このフィールドには、スキャン設定ファイル、eclipseワークスペース、.jar、.war、および.earファイルタイプを指定できます。アプリケーションID、キーID、およびキーシークレットに加えて、ダイナミックアナライザーのステップでは、スキャンする場所のURLが必要になります。ページにログインが必要な場合は、アプリケーションのログイン認証情報も提供する必要があります。

各ステップには、「失敗条件のしきい値」のフィールドがあり、H、M、L、I の文字が含まれていることに注意してください。これらは、そのステップが失敗する前に、そのステップが何個の高、中、低、および情報レベルのセキュリティ脅威を受け入れるかを示しています。たとえば、次の例では、スキャンの結果、5 つ以上の中程度の警告が発生した場合、ステップは失敗します。

また、各 ASoC ステップの後の HCL 起動プロセスエディタ内のグレーの円にも注意してください。これは、ステップが失敗しても、失敗した場合を処理するために、プロセスが先に進めるようにするために重要です。必要に応じて、条件付きロジックを追加して、HCL Launch プロセス・エディタを使用してプロセス全体を失敗させることもできます。

ステップが設定されたら、アプリケーションの展開とセキュリティ・スキャンを実行する時間です。これを実行するための HCL Launch アプリケーションのプロセスは、以下のようになります。

同時に実行されている2つのスキャンを示すステップを丸で囲んでみました。 ASoC サーバーにジャンプすると、これらのスキャンがそこでも実行されていることがわかります。

ここでは、AppScan on Cloud を HCL Software のバリュー・ストリーム管理プラットフォームである HCL Accelerate と統合する方法をご紹介しました。

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/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 の変革に役立ったかどうかを教えてください。