VKS on VCFでCI/CDとGitOpsを組む前に確認する：Harness Delegate、Wiz、Dynatraceの実務ポイント

3行まとめ：VKSのCI/CDは、クラスタではなく配信経路として確認する

配信経路

Git、CI/CD、Helm、VKSまでの変更の流れを説明できるかを見る。

安全な停止

Wizで何を検出したら止めるかを、環境ごとに小さく決める。

健全性判定

Dynatraceのどの指標で継続、確認、rollback候補を判断するかを決める。

最初の確認点はクラスタ作成そのものではなく、変更、スキャン、監視、戻し方を一つの経路として説明できるかです。

• VMware Cloud Foundation Blogは2026年6月16日、VKSとHarness、Wiz、Dynatraceを組み合わせたCI/CDとGitOpsの構成を紹介した。需要シグナルとしては、VKSをアプリ実行基盤だけでなく、配信、スキャン、可観測性まで含む運用経路として見たい読者が増えている点が大きい。
• 導入前に見るべき中心は、Harness DelegateをVCF環境内のどこで動かし、private VKS clusters、Gitリポジトリ、Helm、コンテナレジストリ、SaaS側の管理面とどう接続するかだ。
• WizとDynatraceは「入れれば安全」ではない。Wizで何を検出したら止めるか、Dynatraceのどの指標でリリース継続やrollback候補を判断するかを、PoCの段階で小さく決める必要がある。

VMware vSphere Kubernetes ServiceをVCF上で使うとき、最初の関心はクラスタ作成やネットワーク、Namespace、権限に向きがちです。ただ、2026年6月16日の公式ブログが示した焦点はもう少し先にあります。アプリの変更がGitに入り、CI/CDでビルドされ、HelmなどでVKSへ反映され、Wizでスキャンされ、Dynatraceでリリース後の健全性を見て、必要なら止める。この一連の流れを、どこまで自社の運用として説明できるかが問われます。

この記事では、確認日を2026年6月17日JSTとして、VMware Cloud Foundation Blog、Broadcom TechDocs、VMwareの公開GitHubリポジトリで確認できる範囲をもとに整理します。Broadcom Watch JapanはBroadcom Inc.およびVMware by Broadcomとは非提携の独立ブログです。記事中の製品名、サービス名、商標は各社に帰属し、価格、契約条件、サポート範囲は必ず公式資料で確認してください。

株価や決算の材料としてではなく、導入企業やプラットフォームチームが「明日どこから確認するか」を決めるための記事です。

公式記事を配信経路の話として読む

1. 1Gitリポジトリ

   レビューされた変更とHelm chartを、配信経路の起点として扱う。

2. 2Harness

   CI/CDとGitOpsの管理面として、build、deploy、drift検出をつなぐ。

3. 3Harness Delegate

   VCF環境内で処理を実行し、private VKS clustersとの接続点になる。

4. 4VKS

   アプリの実行先であり、Namespace、権限、ネットワーク境界の確認対象になる。

5. 5WizとDynatrace

   スキャン結果とリリース後の健全性を、継続や停止の判断材料にする。

構成例は標準解ではありません。契約、ネットワーク、監査要件、権限設計に合わせて責任分界を決める必要があります。

公式ブログの主題は、VKSにHarness、Wiz、Dynatraceを組み合わせて、CI/CD、GitOps、セキュリティ、可観測性をつなぐことです。ここで大事なのは、個別ツールの名前を追うことではありません。VKSがアプリの実行先であるだけでなく、変更管理、ビルド、スキャン、デプロイ、監視、rollback判断までを受け止める基盤になる点です。

直近のBroadcom Watch Japanでは、VCF 9.1のVxRail拡張、vSANネットワーク、vDefend、Carbon Blackなどを扱ってきました。今回のテーマはそれらと少し違い、プラットフォームエンジニアリングとDevSecOpsの接続部分にあります。既存のVKS検討を進めている読者は、VKS on VCF 9.1の3ゾーン、VPC/VDS、Antrea、LBの確認記事でクラスタやネットワークの前提を見たうえで、本記事の配信経路を読むと位置づけがつかみやすくなります。

需要シグナルは「VKSでどう運用するか」に寄っている

根拠

公式ブログは、VCF 9の文脈で、プラットフォームチームの関心がインフラ提供から安全なアプリ配信へ移っていると説明しています。そのうえで、HarnessをCI/CDとGitOpsの管理面、Wizをセキュリティスキャン、Dynatraceを可観測性と品質判定の材料として扱っています。

読者が確認すること

この流れは、単に「新しい連携が出た」という話ではありません。読者が知りたいのは、private VKS clustersを外部SaaS型のCI/CDとつなぐとき、資格情報、クラスタ到達性、監査ログ、例外承認をどこで管理するかです。公式記事は導入の入口を示しますが、自社環境ではそこから先の責任分界を決める必要があります。

公式記事を標準構成として読みすぎない

注意点

注意したいのは、公式ブログの構成例を「すべての環境でそのまま標準」と読まないことです。Harness、Wiz、Dynatraceを使う前提は、契約、ネットワーク、セキュリティ方針、監査要件によって変わります。VKS側のNamespace設計やクラスタ権限も、組織ごとの運用境界に依存します。

評価基準

この記事では、公式情報で確認できる構成要素を土台にしながら、導入前に決めるべき問いへ落とします。たとえば「Harness Delegateを置く」ではなく、「DelegateがどのNamespaceで動き、どの権限で、どの宛先に出ていき、どのログを残すのか」を確認します。

Harness Delegateをどこに置き、何をつなぐか

1. 1Harness SaaS manager

   pipeline定義、実行管理、GitOpsの操作面を担う。

2. 2VCF内のDelegate

   HelmベースでVKS cluster内に置き、CI buildやHelm deploymentを実行する。

3. 3private VKS clusters

   外部から直接到達させるのではなく、Delegate経由の権限と通信を確認する。

4. 4Gitとレジストリ

   アプリソース、Helm chart、immutableなコンテナイメージの証跡を分けて追う。

5. 5運用責任

   Delegate更新、クラスタ権限、pipeline変更、例外承認の担当を分ける。

Delegateは踏み台ではなくCI/CDの実行点です。どのNamespaceで動き、どの権限を持ち、どの宛先へ通信するかが確認の中心になります。

この構成の中心にあるのがHarness Delegateです。公式ブログでは、DelegateがVCF環境内で動き、Harness SaaS managerとprivate VKS clustersをつなぐ役割として説明されています。Broadcom TechDocsのHarness設計ページでも、Harness CI/CD platform、VKS cluster、Harness Delegate、コンテナレジストリ、GitHub repositoriesなどが構成要素として整理されています。

ここでの読みどころは、SaaSとプライベートクラスタの間に何を出すかではなく、何を出さないかです。private VKS clustersのエンドポイントや資格情報をどう扱うか、Delegateがどの処理を代行するか、クラスタに対する権限をどこまで許すかを先に決めます。

Delegateは制御プレーン連携の実行点

根拠

Delegateは、単なる踏み台サーバーとして見るより、CI/CDの処理をクラスタ側に近い場所で実行するための実行点として見たほうが実務に合います。TechDocsの構成説明では、HelmベースのDelegateがVKS cluster内で動き、CI buildやHelm deploymentを実行し、クラスタをHarnessへ接続する役割が示されています。

確認項目

導入前に確認したい項目は次の通りです。

確認項目	見る理由	未整理のまま進めた場合のリスク
Delegateを置くNamespace	権限と監査の境界を切るため	アプリNamespaceと運用Namespaceが混ざる
外向き通信	SaaS管理面、レジストリ、Gitなどへの到達性を確認するため	プロキシや証明書でCI/CDが止まる
クラスタ権限	Helm deployやbuild pod実行に必要な範囲を決めるため	便利さ優先で過大権限になる
シークレット管理	レジストリ、Git、Wiz、Dynatrace連携情報を守るため	例外対応や退職者対応で追跡できない
監査ログ	誰が何をデプロイしたかを追うため	障害時に変更元を説明できない

特にprivate VKS clustersでは、外部SaaSからクラスタへ直接到達させる設計にしたくない組織もあります。DelegateをVCF環境内に置く意義は、そうした境界を保ったまま、SaaS側のオーケストレーションを使える可能性にあります。ただし、実際にどの通信が必要かは自社のネットワーク、プロキシ、証明書、DNS、許可リストに依存します。

先に決めるべき責任分界

条件

責任分界を曖昧にしたままPoCを進めると、最初は動いても本番移行で詰まります。たとえば、プラットフォームチームがDelegateとクラスタ権限を管理し、アプリチームがGitリポジトリとHelm chartを管理し、セキュリティチームがWizの停止基準を決め、SREや運用チームがDynatraceの品質ゲートを管理する、といった分担が必要です。

評価基準

この分担は組織によって変わります。重要なのは、次の問いに答えられることです。

• Delegateの更新、再起動、障害対応を誰が見るか。
• Harnessのpipeline定義を誰が変更できるか。
• Gitの変更承認と、Harness上の手動実行権限を同じ人にするか。
• Wizで検出された脆弱性やsecretの例外承認を誰が出すか。
• DynatraceのQuality Gatesが失敗したとき、rollbackを自動にするか手動判断にするか。

ここが決まっていないと、GitOpsやスキャン以前に、組織の運用が先に詰まります。VCF 9.1でIaCを始める前のSDDC Manager API、Terraform、組織とプロジェクトの確認記事でも触れたように、自動化はAPIやツールをつなぐだけでは成立しません。権限、承認、変更履歴の設計が先に必要です。

GitOpsとHelmを運用ルールに落とす

1. 1Git commit

   どのbranchまたはpathが、開発、検証、本番のどの環境を表すかを決める。

2. 2Buildとimage push

   Gitの変更理由と、レジストリ上のimage tagを対応づけて追跡する。

3. 3Helm deploy

   共通label、Probe、resource requests、NetworkPolicyなど標準化する範囲を決める。

4. 4VKS上の状態

   クラスタ上の実態が、レビューされた変更と対応しているかを確認する。

5. 5drift検出

   通知だけにするか、自動修復するかを環境ごとに選ぶ。

Git、レジストリ、クラスタは別々の証跡を持ちます。3つをつなげて説明できることがGitOps運用の前提です。

公式ブログでは、Gitを望ましい状態の起点として扱い、Harness GitOpsでdriftを検出し、Helm chartを使って環境ごとのデプロイを標準化する流れが示されています。ここも用語だけを追うと「GitOpsを使う」「Helmを使う」で終わりますが、実務ではもう少し細かく分ける必要があります。

GitOpsを導入する目的は、Gitを使うことではありません。クラスタ上の状態が、レビューされた変更と対応していることを説明できるようにすることです。

Gitをdesired stateとして扱う前に決めること

確認項目

Gitをdesired stateとして扱うなら、まず「どのリポジトリの、どのbranchまたはpathが、どの環境を表すのか」を決めます。開発、検証、本番をbranchで分けるのか、ディレクトリで分けるのか、値ファイルで分けるのか。どれが正解というより、障害時に追跡できる形であることが重要です。

確認したいのは、次の4点です。

項目	確認する内容
変更単位	アプリコード、Helm chart、環境値を同じpull requestで扱うか、分けるか
承認	本番反映前に誰のreviewを必須にするか
同期	driftを検出したとき自動で戻すか、通知だけにするか
証跡	どのcommitがどのデプロイに対応するかを追えるか

証跡の見方

TechDocsの設計メモでは、GitHub repositoriesがアプリソースコードとHelm chartsを持つ構成要素として扱われ、レジストリにはimmutableなコンテナイメージを置く流れが説明されています。この読み方を実務に寄せるなら、Git、レジストリ、クラスタの3つが別々の証跡を持つことを前提にするべきです。Gitだけ見ても、実際にどのimage tagが動いているかは分かりません。レジストリだけ見ても、なぜそのimageが作られたかは分かりません。クラスタだけ見ても、承認済みの変更かは分かりません。

Helm chartで標準化する範囲を決める

条件

Helm chartは便利ですが、使えば自動的に標準化されるわけではありません。標準化したい項目を決める必要があります。

たとえば、共通label、resource requests、readiness probe、liveness probe、NetworkPolicy、Secret参照、環境変数、ingressやserviceの形式をchartに寄せるのか、各アプリリポジトリへ残すのかを決めます。共通chartに寄せすぎると、アプリごとの例外が値ファイルに溜まり、差分reviewが難しくなります。逆にアプリ側へ任せすぎると、クラスタ全体の運用品質がそろいません。

PoCでの評価基準

PoCでは、最初から全社標準chartを作るより、1つのアプリで次の3点を確認するのが現実的です。

• Gitの変更からVKS上の状態まで追跡できるか。
• driftを検出したとき、通知だけにするか自動修復するかを選べるか。
• Helm valuesの差分を、人がreviewできる粒度に保てるか。

この3点が見えないまま対象アプリを増やすと、GitOpsの仕組みは動いているのに、運用者が状態を説明できないという中途半端な形になります。

WizをCI/CDのどこで止めるか

1. 1IaC scan

   設定ミスを検出し、テストでは警告、本番では停止候補にする条件を分ける。

2. 2secret scan

   secret検出は即時停止に寄せやすく、例外承認の扱いを明確にする。

3. 3container image scan

   severity、修正版の有無、公開面、補完統制を合わせて判断する。

4. 4severity threshold policy

   Critical以上で停止、Highは例外チケット必須など、初版の基準を決める。

5. 5deploy stop

   停止時に誰が直し、誰が例外を承認し、いつ再開するかを残す。

スキャンは検出であり、停止基準そのものではありません。厳しすぎる基準と緩すぎる基準のどちらも、PoCで見直す前提にします。

Wiz連携のポイントは、スキャン対象と停止基準を分けて考えることです。公式ブログは、WizをCI stageへ統合し、コンテナイメージがVKS clusterへ到達する前に、脆弱性、設定ミス、secretを確認する流れを説明しています。TechDocsのWizとDynatrace連携ページでは、Harness STOにWiz CLIを組み込み、IaC、secret、container image scanを扱う構成が示されています。

ここで避けたいのは、「スキャンを追加したから安全」と考えることです。スキャンは検出です。安全に近づけるには、何を検出したら止めるのか、誰が例外を承認するのか、直すまで次へ進ませないのかを決める必要があります。

スキャン対象を3つに分ける

根拠

導入前の確認は、少なくとも3つに分けます。

スキャン対象	見たいリスク	止める判断の例
IaC	Kubernetes manifestやHelm valuesの設定ミス	公開範囲、権限、root実行、危険な設定
secret	認証情報やtokenの混入	GitやCI workspaceへの漏えい
container image	既知脆弱性や危険なパッケージ	CVE severity、修正版有無、例外期限

確認項目

この3つは、検出結果の扱いが違います。secretは即時停止に寄せやすい一方、container imageの脆弱性は、severity、修正版の有無、公開面、補完統制によって判断が分かれます。IaCの設定ミスも、テスト環境なら警告でよいものと、本番では止めるべきものがあります。

読者が最初に作るべきなのは、完璧なセキュリティ基準ではなく、停止基準の初版です。たとえば「本番向けpipelineではCritical以上を停止、Highは例外チケット必須」「テスト環境では通知だけにして検出件数を見る」など、環境ごとに段階を分けるとPoCしやすくなります。

severity threshold policyを誰が決めるか

条件

severity threshold policyは、ツール担当者だけで決めるものではありません。セキュリティチーム、アプリ責任者、プラットフォームチーム、運用チームが、リリース停止の影響を共有して決めるべきです。

下振れ

しきい値が厳しすぎると、デプロイが毎回止まり、例外承認が常態化します。緩すぎると、スキャンは通過儀礼になり、本番に入るリスクを減らせません。最初のPoCでは、検出件数、修正にかかった時間、誤検知や例外の多さを測り、基準を見直すのが現実的です。

この観点は、Tanzu Platform 10.4の脆弱性修復を導入前に確認する記事ともつながります。脆弱性管理は、見つけることより、優先順位を付けて修復し、例外を期限付きで管理することが本番運用では重くなります。

Dynatraceをrollback判断に使う前に見る指標

1. 1onboard前の確認

   operatorのNamespace、OneAgentの監視範囲、ActiveGateやSaaS側への到達性を確認する。

2. 2メトリクス取得

   エラー率、レイテンシ、アプリケーションヘルス、リソース飽和、再起動回数を見る。

3. 3判定期間

   デプロイ直後だけで見るか、一定量のトラフィック後に見るかを決める。

4. 4Quality Gates

   API、batch、管理画面、内部workerごとにしきい値を分ける。

5. 5rollback候補

   異常時に自動で戻すのか、人が確認して戻すのかを運用に合わせる。

同じしきい値をすべてのサービスへ当てるのは危険です。指標の安定性とアプリの性質を合わせて判断します。

Dynatrace連携は、デプロイ後の健全性を見て、Harness側のHealth ChecksやQuality Gatesに生かす文脈で読めます。公式ブログでは、VKS上で動くDynatrace OneAgentからリアルタイムの指標を取得し、新しいデプロイが性能回帰やエラー増加を起こしたかを判断し、必要に応じてrollback候補にできると説明されています。

TechDocsでは、Dynatrace operatorがVKS cluster内でOneAgentやActiveGateのライフサイクルを扱う構成が示されています。ここでも、導入前に見るべきなのは「Dynatraceを入れるか」ではなく、「どの指標を、どの時間幅で、どの失敗条件として扱うか」です。

OneAgent、ActiveGate、operatorの前提を短く整理する

確認項目

VKS clusterをDynatraceへonboardする前に、少なくとも次を確認します。

• Dynatrace operatorをどのNamespaceに入れるか。
• OneAgentがどのワークロードやノードを監視するか。
• ActiveGateやSaaS側への到達性をどう確保するか。
• 監視対象Namespaceをどこまで広げるか。
• メトリクス取得にどの程度の遅延や欠損があり得るか。

注意点

特にQuality Gatesを使うなら、メトリクスが安定して取れていることが前提です。デプロイ直後の数分だけで判断するのか、一定量のトラフィックが入ってから判断するのか、batch処理のようにすぐ指標が出ないアプリはどう扱うのかを決めます。

Quality Gatesのしきい値を運用に合わせる

評価基準

Quality Gatesに入れる候補は、エラー率、レイテンシ、アプリケーションヘルス、リソース飽和、再起動回数などです。ただし、すべてのサービスに同じしきい値を当てるのは危険です。API、batch、管理画面、内部workerでは、見るべき指標が違います。

導入前チェックとしては、次の表を作ると判断しやすくなります。

サービス種別	まず見る指標	注意点
ユーザー向けAPI	エラー率、p95 latency、依存先失敗	短時間のノイズで誤停止しないよう時間幅を決める
バッチ処理	ジョブ失敗率、処理時間、再試行回数	デプロイ直後に指標が出ない場合がある
管理画面	エラー率、ログイン失敗、フロントエラー	トラフィックが少ないと判定材料が薄い
内部worker	キュー滞留、再起動、処理遅延	アプリ固有の正常範囲を先に測る

上振れと下振れ

上振れは、リリース直後の回帰を早く検出し、rollback候補を機械的に出せることです。下振れは、指標のノイズや取得遅延によって、正常なリリースを誤って止めることです。PoCでは、いきなり自動rollbackを本番で有効にするより、まずはQuality Gateの結果を通知として見て、人が判断した結果と差があるかを検証するほうが堅実です。

PoCから本番設計へ進むためのチェックリスト

PoCで確認すること

Delegate稼働、build、image push、Helm deploy、drift検出、Wiz停止、Dynatrace判定を一通り追う。

本番前に固めること

権限、通信先、監査ログ、例外承認、失敗時の復旧担当を曖昧に残さない。

後回しにできること

全社標準chart、自動rollbackの完全化、全アプリ展開は、1アプリで流れを確認してから広げる。

PoCの成功条件は自動化を全部通すことではなく、止まる理由、戻す判断、責任分界を早く見つけることです。

VKS、Harness、Wiz、Dynatraceを一度に本番へ持ち込むと、どこで詰まったのか分かりにくくなります。最初は小さく始めるべきです。1つのVKS cluster、1つのアプリ、1つのHelm chart、1つのWiz停止基準、1つのDynatrace Quality Gateに絞ると、各構成要素の責任が見えます。

PoCの狙いは、すべてを自動化することではありません。配信経路の中で、どこまでを機械に任せ、どこからを人が承認するかを決めることです。

小さく試すなら1アプリ、1環境、1ゲートから始める

条件

最初のPoCで確認したいことは、次の6つです。

1. Harness DelegateがVKS cluster内で安定して稼働する。
2. Gitの変更からbuild、image push、Helm deployまで追える。
3. GitOpsでdriftを検出し、通知またはreconciliationの動きを確認できる。
4. Wizのscanで意図した条件に引っかかったとき、pipelineを止められる。
5. Dynatraceの指標をHarnessの判定材料として読める。
6. 失敗時に、誰が何を見て戻すかを説明できる。

注意点

ここで「自動rollbackまで通った」ことだけを成功条件にしないほうがよいです。むしろ、停止条件が厳しすぎる、メトリクスの立ち上がりが遅い、Delegateの権限が強すぎる、例外承認が手作業すぎる、といった問題を早く見つけるほうが価値があります。

本番前に残してはいけない曖昧さ

確認項目

本番移行前に、次の曖昧さは残さないようにします。

項目	本番前の到達目安
権限	Delegate、pipeline、Git、cluster roleの管理者が分かれている
シークレット	登録先、更新手順、失効手順、監査先が決まっている
例外承認	Wiz検出時の例外条件、期限、承認者が決まっている
監査ログ	Git commit、pipeline実行、image tag、cluster状態を突合できる
障害対応	Quality Gate失敗時の連絡先とrollback手順が決まっている
SaaS障害	Harness、Wiz、Dynatraceの一時障害時に配信を止めるか、手動経路を使うかが決まっている

評価基準

「誰が、どの情報を見て、何分以内に、どの変更を戻すか」まで説明できるなら、本番化の議論に進めます。逆に、ここが説明できないなら、ツールの連携が動いていても運用設計はまだ途中です。

VCF側の防御設計まで広げるなら、vDefend Lateral Security BlueprintsをVCF 9.1で使う前の確認記事も合わせて確認しておくと、アプリ配信経路と東西トラフィックの防御を分けて考えられます。

導入判断の分岐：すぐPoCへ進むケース、先に棚卸しするケース

項目	内容	見方
すぐPoCへ進むケース		VKSの基本設計、Git運用、レジストリ、監視、承認フローがあり、1アプリで試せる担当分担が見えている。
先に棚卸しするケース		クラスタ権限、Gitの環境分離、スキャン停止基準、監視指標、例外承認の責任がまだ説明できない。
判断の主語		VKSでアプリを動かせるかではなく、VKSへ安全に変更を届け、失敗を検出し、戻せるかを見る。

この比較は優劣ではなく準備状態の違いです。契約、ネットワーク、監査要件、組織分担がそろっている範囲から小さく試します。

このテーマは、関心が高いほどすぐ試したくなります。ただし、向いている環境と、先に棚卸ししたほうがよい環境があります。

状態	次の一手
VKS cluster、Namespace、ネットワーク、レジストリ、Gitの運用がすでにある	1アプリでHarness DelegateとGitOpsのPoCへ進む
Kubernetes運用はあるが、スキャン停止基準がない	Wizの検出対象とseverity threshold policyを先に作る
可観測性はあるが、リリース判定に使っていない	DynatraceのQuality Gatesを通知モードで試す
クラスタ権限やシークレット管理が曖昧	Delegate導入前に権限、Namespace、監査ログを棚卸しする
VKSネットワーク設計がまだ固まっていない	まずVKSのネットワーク、ロードバランサ、Namespace境界を整理する

今回の公式ブログは、VKSをアプリ配信の中心に置く流れを示したものとして読めます。一方で、Harness、Wiz、Dynatraceの連携は、契約や設定だけで完結する話ではありません。クラスタ、Git、レジストリ、スキャン、監視、承認、監査が同じ配信経路として説明できて初めて、プラットフォームチームの運用品質につながります。

この意味で、導入前チェックの主語はツールではなく運用です。VKSでアプリを動かす準備ができているかではなく、VKSへ安全に変更を届け、失敗を検出し、戻せる準備ができているか。ここを確認してからPoCへ進むのが、今回の公式情報から読み取れる実務ポイントです。

次に読むなら

参照した主な情報源

• VMware Cloud Foundation Blog「Streamlining CI/CD and GitOps on VMware vSphere Kubernetes Service with Harness, Wiz, and Dynatrace」

https://blogs.vmware.com/cloud-foundation/2026/06/16/streamlining-ci-cd-and-gitops-on-vmware-vsphere-kubernetes-service-with-harness-wiz-and-dynatrace/

• Broadcom TechDocs「Continuous Integration and Delivery with Harness Architecture」

https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-consumption/latest/modern-applications/continuous-integration-and-delivery-with-harness/gitops.html

• Broadcom TechDocs「Continuous Integration and Delivery with Harness Design」

https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-consumption/latest/modern-applications/continuous-integration-and-delivery-with-harness/continuous-integration-and-delivery-with-harness-design.html

• Broadcom TechDocs「Security Integration with Wiz and Dynatrace into the Harness CI/CD pipeline」

https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-service-administration-and-development/9-0/modern-applications/continuous-integration-and-delivery-with-harness/vks-security-integration-with-wiz-and-observability-with-dynatrace-into-the-harness-cicd-pipeline.html

• GitHub vmware/vks-consumption-models

https://github.com/vmware/vks-consumption-models

更新履歴

• 2026年6月17日JST: 公式ブログ、Broadcom TechDocs、GitHub公開リポジトリを確認し、初版を作成。