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

Introducing HCL Accelerate 2.1 の翻訳版です。

HCL Accelerate 2.1 のご紹介

2020年10月1日

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

HCL Accelerate は、今、バリュー・ストリーム管理の未来を構築しています。HCL Accelerate 2.1 のリリースでは、この市場における当社の継続的な改善と最先端の機能の提供をご覧いただけます。お客様からのフィードバックと深い市場分析により、当社は、VSMの主要な価値領域に焦点を当て続けることができました。HCL Accelerate をお使いの場合にはアップグレードして、以下の最新機能を試してみてください。まだ HCL Accelerate を使用していない場合は、無料の Community Edition をここでチェックすることで、今すぐ HCL Accelerate を使い始められます。

データ駆動型インテリジェンスによるガバナンスの自動化

• 自動化されたルールベースのゲート - セキュリティと品質データの統合を活用して、自動化されたルールベースのゲートで複数のアプリケーションを単一のパイプラインで管理します。自動プロモート機能を利用して、ハイブリッド集中型フルコントロール CI/CD システムでビルドをより低い環境にシームレスに移行できます。

• オープンパイプライン - HCL Accelerate の特長は、パイプラインビューです。2.1 では、HCL Launch や Azure DevOps などの市場をリードするデプロイツールと接続する、真にオープンなパイプラインにより、ビルドから本番までの可視性がさらに向上しました。さらに、パイプラインビューのロード時間が 70% 速くなり、常に最新の作業状況を把握できるようになりました。

作業を可視化し、予測可能に

• 新しいバリュー・ストリーム・メトリクス - ロード、スループット、およびディストリビューションの 3 つのメトリクスで、フローがどのように発生しているか、そして顧客に最も価値を提供するために最適な数値は何であるべきかを正確に確認できます。2.1 では、これらのメトリクスはダッシュボードで経時的な傾向を見るためにサポートされているだけでなく、バリュー・ストリームのメトリクス・バーを介して、チーム全体が素早くアクセスできます。

• 強化されたレポート - 新しい「スプリントの状態」レポートでは、Velocity などのメトリクスを活用し、コントリビューターやポイントされたグラフとそうではないグラフなどの重要な情報を組み込むようになりました。また、2.1 の新機能として、ワンクリックでセキュリティ監査を実行し、HCL Accelerate のインスタンスで誰がどのような権限を持っているかを素早く確認できるようになりました。

• 質問に答えられる表示 - バリューストリームを「お気に入り」にして、プロジェクトやチーム間の主要なメトリクスを素早く確認したり、比較したりすることができるようになりました。点や作業項目を確認し、DevOps クエリ言語 'issue.sprints.active=true' の拡張により、スプリントがどのように進行しているかを正確に視覚化します。

バリューを得るまでの時間が早い

• HCL Software Factory (SoFy) で利用可能 - HCL Accelerate は、HCL Software Factory (SoFy) で利用可能になりました。SoFy は、Kubernetes 対応製品を Docker イメージや舵取り図としてカタログ化したもので、クラウドネイティブのレジストリでホストされています。SoFy がどのようにソリューションを合理化するかについての詳細は、こちらからお問い合わせください。

• 複数のパフォーマンスと安定性の改善 - 私たちは、パフォーマンスと安定性を継続的に改善するよう努めています。今回のリリースサイクルも例外ではありません。技術的な詳細については、こちらの累積リリース情報をご覧ください。

小規模な機能強化

• リリースオーケストレーションの改善 - リリース機能に様々な改善とバグ修正が行われました。これには、リリース参加者の表示の改善、情報の表示の改善、リリースロックの小さな強化が含まれます。

• Jenkinsサーバー用の新しいプラグイン（プラグインバージョンv2.1.0） - HCL Accelerate v2.1.0では、Jenkinsサーバー用の新しい改良された v2.1.0 プラグインを使用する必要があります。

• 複数の新しい HCL Accelerate プラグイン

  • ブラックダック
  • HCLコンパス
  • Azure DevOps
  • HCL Launch
  • まだまだ続く! Docker Hub をチェック

• 既存のプラグインでより多くのデータを

  • プラグインのイメージバージョンがUIから明確に表示されるようになりました
  • Azure Devops プラグイン。マスター以外の別のブランチをコミットのために追跡できるようにする
  • SonarQube プラグイン。正しいビルドにリンクするメトリクスのアップロード
  • ServiceNow プラグイン。変更やインシデントと一緒に問題データを引き出す
  • Github プラグインのプロキシ対応
  • 壊れていたすべてのパーサープラグインの最新バージョンを修正し、すべてのドキュメントを更新しました。

• 新しい Pipeline Designer ロール - この新しいロールは、パイプラインの編集を許可しながらも実行を禁止する権限を持っています。

• ユーザーリストの改善 - 新しいシングルユーザーリストを使用して、LDAP、SSO、ローカルユーザーを表示できます。

これらの新機能は、10月8日（木）午後2時（EDT）に開催されるウェビナーでご確認ください。参加できない場合でも、サインアップしていただければ、録画を視聴できます。登録するにはここをクリックしてください。

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

Pipeline Governance with Automated Rule Based Gates, new in HCL Accelerate 2.1 の翻訳版です。

HCL Accelerate 2.1 の新機能: 自動化されたルールベースのゲートを使用したパイプラインガバナンス

2020年9月30日

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

バリューストリーム管理と聞くと、メトリクス、主要業績評価指標（KPI）、可視性を思い浮かべるかもしれませんが、HCL Accelerate は2.1 のリリースでそれをさらに向上させています。

2.0 では、ユーザーが手動でバージョンを承認または拒否することができる単一の場所を提供していましたが、エクスペリエンスを向上させることができることがわかっていました。そこで私たちは、DevOps データレイクとデータの深い複雑な関係を活用して、セキュリティルールと品質ルールを導入することで、ゲートを迅速に強化しました。

多くの開発チームにとってパイプラインは、CI/CD ツールがバラバラでプロセスが複雑なワイルドウェストであり、情報が失われる可能性のある領域を生み出しています。例えば、計画されていなかった Pull Request が、実際にはリリースの最終ビルドに含まれていたという状況があるかもしれません。その場合、この小さな変更が壊滅的な脆弱性をもたらしていた可能性があります。作業項目がなかったため、誰も変更が入るとは予想していなかったので、手遅れになる前に誰も戻ってセキュリティ脆弱性の結果をチェックしなかったのです。

これらは、私たちのほとんどが夜も眠れない原因となっています。さらに悪いのは、ツールでレポートをチェックしたり、他の部署に連絡したり、回答を待ったりするためにリリースを遅らせなければならない場合です。より速く、より良い品質を実現する唯一の方法は、プロセスを自動化することです。自動化されたルールベースのゲーティングでできることに飛び込んでみましょう。

まず最初に気づくのは、新しいルールが2.0の手動ルールをベースにしていることです。多くのお客様がBETAモードでこれを使用してきました。彼らは、すべてのツールを HCL Accelerate に接続していませんでしたが、手動ルールを使用して、どのツールが必要で、いつ接続できるかという目標を設定することから始めていました。アプリケーション・セキュリティ・スキャン・ツールを探しているのであれば、AppScan を強くお勧めします。

自動化されたルールは、コードカバレッジ、機能テスト、ユニットテスト、アプリケーションの脆弱性、コンテナの脆弱性、静的コード解析など、HCL Accelerate でおなじみのあらゆる種類のメトリクスをチェックすることができます。最も良い点は、これらが設定されると、バージョンに関連付けられたデータを完全に自動分析して実行するため、基準を満たさない限り、どのバージョンもこれらのゲートを通過しないことを信頼できるということです。しかし、心配しないでください - 私たちはすべてのコードを出荷しなければならなかったので、常に「確かですか？」という回避策がありますが、それは監査報告書にキャプチャされます。この機能は、実際には、チームが完全な自律性を持って顧客にできるだけ早くリリースできるようにするためのチェックとバランスを整えることです。 「自分はブロッカーが 0 であると言ったけど、あの時、自分は本当に正しいビルドを見ていたのか」などということを、徹夜して言い出すことがなくなります。

いつものように、質問があれば私や私のチームの誰にでも連絡してください。デモをお見せして、HCL Accelerate とバリュー・ストリーム・マネジメントがどのようにしてチームがタスクに集中することをやめ、より多くの価値を提供できるかをお見せしたいと思っています。

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

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

data-driven-DevOps%e2%80%afpart-2-data-driven-culture の翻訳版です。

データ駆動型 DevOps パート 2: データ駆動型の文化

2020年9月29日

著者: Steve Boone / HCL Software DevOps Head of Product Management

シリーズのパート1を読むにはここをクリックしてください。

堅固な文化は、どのような DevOps 組織にとっても非常に重要です。DevOps 文化の主要な特徴は、開発チームと運用チーム間のコラボレーションを強化し、サポートするアプリケーションの健全性と健全性に対する責任感を共有することです。これは、開発、IT/オペレーション、および「ビジネス」を横断する透明性、コミュニケーション、およびコラボレーションを高めることを意味します。職場内の文化的規範は、優先順位、コラボレーションの方法、問題解決のアプローチに関して意見の相違につながることがよくあります。特に最終的な目標や価値が誰にとっても明らかでない場合は、DevOps 文化は新しい働き方を採用するのに苦労することがあります。

このような文化の移行を容易にするにはどうすればよいのでしょうか？それはデータです。データは、チーム間の知識の公平性を提供することで最大の効果を発揮します。理想的には、優れたデータがあればあるほど、より良い知識を得ることができます。この新しい知識があれば、より効果的に仕事をし、より明確にコミュニケーションを取り、最終的には組織としての働き方を改善するために行動を起こすことができるようになります。つまり、データは、人々が互いに協力し、協力し合う方法を劇的に改善することができるのです。

カルチャーを改善したい場合、どのようなデータを調べればよいのでしょうか？手をつけるべき場所には事欠かないが、HCL Software DevOps での経験から、私たちは開発者、デザイナー、アーキテクトなど、個々の貢献者にとって最も馴染みのあるデータから始める傾向がある。これは通常、ソース・コントロール管理や、課題追跡やプロジェクト管理に関連するデータ（ソースの例としては、Atlassian、JIRA、Gitなどがあります）から来るデータです。

これらのツールから得られるデータからは、多くの分野の洞察が得られます。まず、コードをコミットし、コードの変更をビジネス価値のある特定の項目に関連付ける際に、チームメンバーが使用し、最もよく知っているプロセスを示します。これにより、日々の活動をよりよく理解し、改善点を見つけることができます。また、このデータを使用して、作業中のアプリケーションを特定したり、多くの場合、作業のタイプ（例えば、欠陥と機能）を特定することもできます。このデータは、特定のチーム全体の仕事の分布についての有用な洞察を引き出すために使用することができ、 チームがどのように連携して仕事をしているかを示すことができます。

個々の貢献者から得られるデータを調べることで、以下の7つの主要な分野で文化を改善することができます。

• 誰が何に取り組んでいるか？ 誰が何に取り組んでいるか？ 誰がどのような作業をしているかを知ることは、優先順位に変更があった場合や要件が変更された場合に備えて、開発マネージャやチームの残りの部分を常に把握しておくのに役立ちます。

• 何か重要なものが取り残されていないか？ 進行中の作業を特定することができれば、そのリストをビジネスゴールや成果物のリストとクロスリファレンスすることができます。これにより、「やるべきことに取り組んでいるか」という質問に、より明確に答えられるようになり、時間通りに終わらないかもしれない項目を特定したり、優先順位をつけずに行われている作業を見つけることができます。

• 誰が助けを必要としているのか？ 遠隔地で働くスタッフが増えた今、手を挙げて助けを求めるのは難しい。多くの場合、最も優秀な従業員は、彼らの皿の上にあまりにも多くの仕事を抱えてしまうことになります。データを見ることで、仕事を完遂するのに苦労している貢献者を特定し、必要な助けを得ることができます。また、このデータは、時折行われる消防訓練で少し余力のある人を見つけるのにも役立ちます。

• チームが日々の活動をどのように行うかを改善する。 どのプロセスにも改善の余地があります。より明確なデータがあれば、開発チームが使用しているシステムとどのように相互作用しているかを評価することができ、コードレビューからテストツール、バックログの項目のトリアージまで、ビジネス価値をより効率的に流すことができないボトルネックを明確にすることができます。

• チームの速度を特定することで、計画を改善する。 進行中の作業を特定することで、どのような作業が完了したかを把握することができます。これにより、チームのベロシティを把握することができ、特定のスプリントやリリースに何をコミットできるかを容易に把握することができます。

• スプリント/リリースのスコープがより良くなります。 リリースやスプリントに何をコミットできるかを知ることで、チーム全体がより個人的に責任を持ち、達成された仕事に「納得」するようになります。チームは、短い時間枠の中で過剰な成果を求められていると感じることが少なくなります。

• 予定外の仕事を識別する。 計画外の作業は、時間通りに納品されないビジネス価値の最大のサイレントキラーです。チームがどのような開発努力をしているかを分析することで、そのデータを見て、計画的な作業と計画外の作業のどちらが多いかを判断し、計画外の作業の影響を最小限に抑えるための是正措置を取ることができます。

これらの分野に共通しているのは、開発チーム全体のコラボレーションとコミュニケーションの改善に焦点を当てていることです。個々の貢献者が自分に何が期待されているのかを知り、目標が明確に定義されている場合、貢献者はより積極的に参加し、日々の活動に価値を見出し、成功する可能性が高くなることがわかります。

データは非常に個人レベルでも支援する能力を持っています。DevOps Institute の 2020 Upskilling: Enterprise DevOps Skills Report の調査結果によると、DevOps 人材の採用を検討している企業では、新規採用の要件として「ヒューマンスキル」が上位にランクインしています。上位に挙げられたヒューマンスキルの1位は何だったのでしょうか？コラボレーションと協調性、次いで共有と知識の伝達、そして適応性、共感性。これらのヒューマンスキルはすべて、DevOps 文化がデータを受け入れることで成長させることができます。

DevOps Institute のレポートから得られた重要な調査結果の1つは、雇用主が「E字型」のスキルセットを持つ潜在的な候補者を見つけたいと考えていることでした。I字型、T字型、E字型のスキルセットについてよく知らない方は、下の図をご覧ください。I型スキルセットはスペシャリストです。彼らの知識は、一つのテーマについて非常に深いものです。T型のプロファイルは、特定の領域の専門家でありながら、ビジネス全体に関する幅広い一般的な知識を持っています。このため、機能横断的なチームとの連携を得意とし、より広い戦略をまとめる上で優位に立つことができます。E型スキルセットは、さらに一歩進んだものです。このような人材は、プロセスやフレームワークのスキルの専門知識だけでなく、幅広いヒューマンスキルを持っており、自動化の経験、新しいアイデアを探求する能力、高いレベルで実行する能力を備えています。

出典: DevOps インスティテュート

データは、個人が通常の役割以外の仕事に触れることで、「T字型」のスキルセットがより「E字型」の未来へと成長するのを支援する上で重要な役割を果たすことができる。このような経験は、共感を生み出し、積極的な DevOps 文化に不可欠な責任感を共有する感覚を高めるのに役立ちます。自分のコントロール外に存在する課題を他者が理解できるようにすることで、組織が真の意味で DevOps を受け入れるために必要な健全な対話を始めることができます。

データは DevOps に変革的なメリットをもたらす可能性があります。次回は、データがどのようにして組織がより効果的に作業を追跡し、計画を立てるのに役立つかについて説明します。最後までお読みいただきありがとうございました。

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

Data-Driven DevOps Part 1: An Introduction の翻訳版です。

データ駆動型 DevOps パート 1: 序章

2020年9月28日

著者: Steve Boone / HCL Software DevOps Head of Product Management

ソフトウェア開発の専門家が DevOps について議論するとき、多くの場合、人、プロセス、テクノロジーを中心とした3つの主要な会話が形成されます。これら3つのコンセプトは、DevOps の核心を語るものです。

人」のトピックは、コラボレーションと責任の共有をサポートする健全な文化を構築することに焦点を当てています。プロセスについて議論する場合、会話は特定のワークフローをいかに効率的にできるかに傾く傾向があります。DevOpsのテクノロジーの側面は、ソフトウェア開発における近代化、セキュリティの脆弱性、品質保証、自動化、その他多くの要因に至るまで、常に変化し続ける会話です。私たちは、何がうまくいき、何がうまくいかないかを判断するために、このような会話をしています。私たちは、これらの会話を DevOps が生み出す貴重なフィードバックサイクルの一部として受け入れ、日々の責任を改善する方法を学べます。

すでに DevOps の旅を始めている組織にとって、このような会話は日常生活の一部となっています。振り返りから計画会議まで、1週間を通していくつかの会議が行われますが、これらはすべて、組織全体がこれまでの行動から学び、より良い計画立案の支援に焦点を当てています。これらの会議は、組織のさまざまな部分がそれぞれの意図を共有し、より効果的に協力し、高品質のソフトウェアをリリースするために必要なすべての可動部分をよりよく理解するための素晴らしい方法です。この種の会議の欠点は、主に個人的な経験に基づいていることです。会話に参加している人は皆、自分の視点、自分の主張を示すためのデータ、そして（おそらく最も重要なのは）自分の感情を持ってきます。このため、全員の意見を一致させ、同じ目標に向かう努力は非常に困難です。それはまた構成のある部分にグループの残りの部分より競争の優先順位があれば職場内の分裂を作成できます。

バリューストリームマネジメント (VSM) は、このような継続的な議論から生じる多くの課題を解決できる DevOps のプラクティスとして位置づけられています。VSM の基本的な概念の中で、組織は、機能を市場に投入するために必要なアイデアから納品までのすべてのステップをよりよく理解できます。VSM は、組織のプロセスをマッピングするというコンセプトに基づいています。これには、貢献しているすべての主要なビジネスユニット（設計、開発、製品管理、リリースエンジニア、品質保証、セキュリティなど）と協力して、現在のビジネスがどのように運営されているかを正直に表現し、改善すべき領域を見つけることを目的としています。マッピングはプロセス全体を全体的に見るための素晴らしい方法ですが、ひとつの重要な要素が欠けています。

バリューストリームから生み出されるデータを収集・分析することで、あらゆるチームが直面する古くからの疑問の謎を解き明かす鍵を握っています。どこを改善できるのか？何がうまくいっているのか？何がうまくいっていないのか？データ自体は懐中電灯のような役割を果たし、組織が実際にどのように日々運営されているのか、有用な洞察を照らし出せます。これは、我々はプロアクティブに反応していることから会話をシフトすることができることを意味します。 反応的な会話は、ほとんどの場合、問題を理解し、何が問題を引き起こしたのかを理解し、最終的に問題の解決策を議論することに費やされます。プロアクティブな会話は、グループがリアルタイムで何が起こっているかを見ることができるときに行われます。リアルタイムのデータは、問題を予測し、痛みが現実になる前に解決策を実行に移すことを可能にします。データに基づいた会話をすることで、問題がどこにあるのか、より重要なのはなぜ問題なのかを関係者全員が明確にできるため、問題解決をより迅速に行うことができます。

HCL Accelerate のSwim Lanes ビューでは、チームの仕事の全体像を把握できます。

このブログシリーズでは、データが組織内で果たす重要な役割について見ていきます。特にコアとなる「影響を与える領域」と、データがどのようにDevOpsの主要な会話に影響を与えることができるかに焦点を当ててみたいと思います。

• 人: データを通じたDevOpsの人間化
• プロセス: データを使ったトラッキングとプランニング
• テクノロジー: データ主導のビジネス・アジリティ

データに基づいて DevOps イニシアチブを推進することは、最終的には、個々の貢献者の努力がビジネス目標と明確に一致するような、より共感性の高い DevOps 組織を育てることにつながり、プロダクト・マネージャーは、何がデリバリーのために計画されているのか、何がリスクであり、何を残す必要があるのかを利害関係者や顧客に簡単に伝えることができるようになります。データを DevOps の目標の最前線に持ってくることで、組織全体として、リスク、コスト、収益をより良く管理することができるようになります。 データ駆動型の DevOps とバリュー・ストリーム管理が、組織におけるDevOpsの話を変え、効果的な変化を実感できるようにするために役立つ多くの方法を、今後数週間にわたってご紹介していきます。

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/9/16 - 読み終える時間: 7 分

第一回目の記事「HCL Accelerate: GitHub と Jira と組み合わせた HCL Accelerate Value Stream Management」の第二回目、HCL Accelerate VSM with Jenkins – Part 2 の翻訳版です。

HCL Accelerate VSM を Jenkins と組み合わせて使用する - パート 2

2020年9月16日

著者: Daniel Trowbridge / Technical Lead

このチュートリアルでは、HCL Accelerate パイプラインからパラメトリックなJenkinsジョブを設定してデプロイする方法を説明します。

前提条件

• HCL Accelerate との Jenkins 統合の完了
• HCL Accelerate VSM を Jenkins と組み合わせて使用する - パート 1 の完了
• GitHub と Jira と組み合わせた HCL Accelerate Value Stream Management の完了を推奨しますが、必須ではありません。

1. PRODデプロイ用のJenkinsジョブを作成する

1.1 新しいパイプラインジョブの作成

今回は架空のプロダクションまたは「PROD」環境へのデプロイ用に、2つ目のパイプラインジョブを作成します。

1.2 パイプラインスクリプトの設定

以下のスクリプトをコピーしてパイプラインスクリプトとして貼り付けます。Build、DEV、QAで使用したスクリプトに似ています - PROD スクリプトには、"Download attributes for API" json ファイルから取得しなければならない2つの変数値があります。このファイルは、HCL Accelerate バリューストリームのツールアイコンからダウンロードできます。スクリプトをコピー＆ペーストし、正しい変数値を提供したら、Jenkins で「適用」と「保存」をクリックします。

parameters([
string(name: 'buildNumber', description: 'The version of the application to deploy.')
])
node {
//Get value for VSM_ENV_ID_PROD from HCL Accelerate VSM "Download attributes from API" json file.
def VSM_ENV_ID_PROD="0e9ea7c7-ed1d-43f2-9ebf-a5ab5161d61e"
//VSM_APP_NAME must match your HCL Accelerate pipeline application name
def VSM_APP_NAME="JKE App1"
currentBuild.displayName = "${buildNumber}"
stage ("Deploy to PROD") {
step([$class: 'UploadDeployment',
//"versionExtId" can be used in place of "id" and "versionName"
id: "${currentBuild.displayName}",
versionName: "${currentBuild.displayName}",
name: "${currentBuild.displayName}",
description: 'UploadBuild Example',
tenantId: "5ade13625558f2c6688d15ce",
initiator: "admin",
//Must specify one of "appId", "appExtId", or "appName"
appName: "${VSM_APP_NAME}",
environmentName: 'PROD',
environmentId: "${VSM_ENV_ID_PROD}",
result: "${currentBuild.currentResult}".toLowerCase(),
startTime: "${currentBuild.startTimeInMillis}",
endTime: "${System.currentTimeMillis()}",
type: "Jenkins",
debug: false,
fatal: false,
])
}
}

1.3 ジョブをパラメータ化する

パイプラインジョブを「buildNumber」という文字列パラメータでパラメータ化します。Apply をクリックして Save をクリックします。

2. HCL Accelerate パイプラインのセットアップ

PROD のデプロイメントは、DEV や QA のデプロイメントを設定するのとは少し違った方法で設定します。このチュートリアルでは、パイプラインにバージョンを提供する入力ジョブ(以前のビルドまたはディプロイメント)を設定します。パイプラインには、Jenkin ジョブにビルド番号を渡すパラメータ化された PROD ディプロイメントも含まれます。パイプラインに利用可能な入力バージョンを確認し、このバージョンをPROD環境にデプロイすることができるようになります。

2.1 入力ジョブを構成する

2.1.1 パイプラインから、関心のあるアプリケーション（この例では「JKE App1」）の「Input」の下の「+」をクリックします。

2.1.2 "Create Version "フォームで "Automatically "を選択し、ビルドを生成するJenkinsジョブを選択します。このチュートリアルでは、以前に作成した Build, DEV, QA Jenkins ジョブを使用します。

2.2 PRODの配置を設定する

PRODにデプロイするJenkinsジョブをPROD用のHCL Accelerateパイプライン環境に割り当てる（マップする）必要があります。また、ビルド番号にパイプラインパラメータを使用するように、このジョブを設定する必要があります。

2.2.1 パイプラインから、対象のアプリケーション（この例では「JKE App1」）の「PROD」の下の「+」をクリックします。

2.2.2 PRODにデプロイするために作成したジョブを選択し、「保存」をクリックします。

2.2.3 ビルドをデプロイメントにリンクさせるために、Jenkins ジョブのパラメータとして buildNumber を渡します。パラメータを使用してジョブを構成したので、この時点でパラメータを提供するように求められます。HCL Accelerateは、流動的なパイプラインをサポートするために、様々なバージョン/インベントリーのパラメータを用意しています。この場合、${version.buildNumber} をフォームに入力します。

これで、「入力」と「PROD」の両方の列の下に「まだ実行していない」と表示されるはずです。先に進み、HCL Accelerate に新しいビルド情報を提供するための最初の Jenkins ジョブ (入力ジョブ) を実行します。入力ジョブを実行すると、バージョン情報が表示されるはずです。

• Jenkins ジョブを実行する前に

• Jenkins ジョブを実行した後

3. ファイナルステージから PROD への変更

3.1 PROD へのパイプライン展開

3.1.1 HCL Accelerate パイプラインから、PROD の「Play」ボタンをクリックします。

3.1.2 最新版を選択して「デプロイ」をクリックします。これで、先ほど作成したパラメータ化されたJenkinsジョブが起動します。

3.1.3 ジョブが終了すると、パイプラインはバージョン番号とともに「Deployment succeeded」と表示されます。

価値の流れに戻る

バリューストリームに戻ると、ドットが最終段階であるPRODに向かって移動するのを見ることができます。

結論

これで、Jira、GitHub、Jenkinsのチュートリアルシリーズを終了します。私たちは、バックログから本番までのバリューストリームの旅全体をナビゲートし、途中で4つの別々のツールを使用しました：3つの外部ツール（Jira、GitHub、Jenkins）、そしてデプロイメントツールとしてのHCL Accelerate自体です。私たちは、ステージクエリ、統合、リンクルールを持つvsm.jsonファイル、パイプラインとデプロイメントなど、HCL Accelerateの主要な概念について学びました。ここから戻って、バリュー・ストリームの実験を始めることができます。手始めに、vsm.jsonファイルのステージとクエリを見ることから始めるのが良いでしょう。そこから、独自のプロセスに合わせてバリューストリームを形成し始めることができます。

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

https://blog.hcltechsw.com/accelerate/survey-says-heres-what-the-market-really-thinks-of-value-stream-management/

Survey says...here's what the market really thinks of Value Stream Management

市場はバリュー・ストリーム・マネジメントについてどのように考えているのか

2020年9月15日

著者: Elise Yahner / HCL

バリューストリーム管理は、DevOps のソートリーダー、トレードショー、出版物などで話題になっていますが、ソフトウェア開発の専門家は VSM についてどのように考えているのでしょうか？これは、SD Times と提携してバリュー・ストリーム・マネジメント市場調査を行った際に、私たちが知りたかったことです。

SD Times は何百人もの読者を対象に、「バリュー・ストリーム管理のメリットについての現在の理解度はどうですか？結果は、VSMの認知度と採用はゆっくりと着実に進んでいますが、VSMを使用している人はすでに恩恵を受けていることを示しています。

最近、SD Times の編集長である Dave Rubinstein 氏は、ポッドキャストの中で、HCL Software DevOps の製品管理責任者である Steve Boone とこの調査について語りました。Boone によると、バリューストリームマネジメントは、VSM のアーリーアダプターと VSM のことを聞いたことがない人との間で、「交差する」地点にあると考えているとのことです。データはこれと一致しています。調査回答者の 3 分の 1 は、バリュー・ストリーム・マネジメントについて聞いたことがないと答えていますが、39%は VSM を導入する予定があるか、すでに VSM を実践していると答えています。

では、どうやって業界をその溝を越えさせるのか？教育とトレーニングです。「このソリューションには明らかに価値があるので、そのキャズムを越えて、一般的に採用が増えるまで、そう長くはかからないと思います。業界としては、人々にベストプラクティスを教育し、VSM がもたらしたデータを使って何か意味のあることをする方法を教えることが鍵となります」と Boone は指摘しました。

そのデータは、しばしばバラバラな DevOps ツールに隠されていますが、VSM の成功のハイライトとなっています。「ソフトウェア開発には、サイロ化されている部分がまだあり、組織の他の部分の人間が必ずしも見たり、洞察を得たり、行動に移すことができません。調査回答者の大多数が、「ソフトウェアデリバリパイプライン全体で進行中の作業の可視性が向上したこと」が、VSM の最も価値ある側面であると答えていることは、驚くに値しません」と Rubinstein 氏は述べています。

バリュー・ストリーム・マネジメントのあらゆる利点にもかかわらず、組織的、教育的な課題が VSM への参入を阻んでいます。調査回答者が挙げた課題のトップは経験の不足であり、資金調達や経営陣の協力が挙げられています。

しかし、Boone は「現在のプロセスについて、長く正直に振り返る必要があります」と述べ、VSM を始めるための最良の第一歩は、チームとの会話だとしています。「アイデアはどのようにしてバックログに入るのでしょうか？それが最終的にバックログから設計や計画の段階に移るのはいつですか？どのようにしてスプリントに入るのでしょうか？データはツールに隠されていますが、お互いの作業関係も理解しなければなりません」。

9月24日（木）午後3時（東部標準時）に開催されるパネルウェビナーでは、SD TimesのVSM調査結果について詳しくご紹介します。ウェビナーでは、SD Times の Dave Rubinstein 氏が、HCL Software DevOpsのエキスパートである Steve Boone、Chris Nowak、Bryant Schuck とバリューストリームマネジメント市場について議論します。登録はこちらをクリックしてください。