CI/CDパイプラインを改善する︕ アーティファクト管理採⽤のポイント 2022/09/15(⽊) JFrog Webinar 

はじめに 2 n 資料・動画は後ほど公開します p公開後、本ウェビナーにご登録いただいたメール宛にお知らせします n Zoom機能を使って、是⾮ご参加ください pQ&Aで質問を随時書き込んでください pチャットは⾃由にお使いください（ご⾃⾝の現場のお話、賑やかしなど） n Twitterが好きな⽅は #JFrog でツイートをお願いします 

⾃⼰紹介 3 n Developer Advocate @ JFrog n 「よしQ」と覚えていだけるとうれしいです n ⼭形県鶴岡市からリモートワーク n SIerでアプリケーション開発エンジニアやアーキテクト、ITコンサル など経験 n 提案〜要件定義〜設計・開発〜導⼊〜運⽤保守まで n エンジニア⽬線で情報発信︕ 佐藤 由久 SATO Yoshihisa @umekichi1984 @yoshiq-sato 

Ice Break 4 ＠鵜ノ崎海岸(秋⽥県) 

ゲストスピーカー 5 SB C&S株式会社 ICT事業戦略・技術本部 技術統括部 テクニカルマーケティングセンター ビジネス開発課 ⽂系⼤学卒業後、勤怠管理システム(Java)の開発に従事され、 要件定義からコーディング、保守までご経験。 2021年11⽉より現職。これまでの経験を活かし、 DevOpsやDX推進のエンジニア兼プリセールスとしてご活躍中。 佐藤 梨花 さん SATO Rihwa 本セッションの後半に、アーティファクト管理により得られるメリットについて、 知⾒をご教⽰いただきます。 

アジェンダ 6 n アーティファクトとは (★) n 現状の開発・運⽤現場における課題 n バイナリ・リポジトリを⽤いたアーティファクト管理 (★) n CI/CDにアーティファクト管理を採⽤するポイント n アーティファクト管理により得られるメリット n まとめ・Q&A (★) お知らせのアジェンダに対して追加しています。 

7 アーティファクトとは 本編に⼊る前に︕ このウェビナーの基礎⽤語として 

「アーティファクト」とは 8 n 広義の意味では「ソフトウェアを作る過程で⽣み出されたもの」を指す p 設計書 p ソースコード p ビルドやパッケージングを経て⽣成されるファイル p テスト仕様書・エビデンス p ログファイル など 

このセッションにおける「アーティファクト」 9 n アーティファクト︓ビルドやパッケージングを経て⽣成される実⾏形式、または配布形式のファイル pコンパイル型⾔語の場合、多くはバイナリファイルとして出⼒ pインタプリタ型⾔語の場合、実⾏可能な形式のファイルを⼀括出⼒ n バイナリ、パッケージ、ライブラリなど様々な呼称がある JAR/WARパッケージ (Java) RPM/DEB パッケージ (Linux) Docker イメージ npm (JavaScript) PyPl パッケージ (Python) RubyGems (Ruby) ZIP/tarball ファイル ダイナミックリンク ライブラリ(DLL) (Windows) NuGet パッケージ (.NET) Go Module (Go) 例︓ 9 コーディング ビルド 単体テスト テストデプロイ 結合テスト 本番デプロイ 運⽤ アーティファクトが使われ続けるのがベストプラクティス (1度⽣成したら本番デプロイまで同じものを使う) アーティファクト(実⾏形式)誕⽣ 

アーティファクトのメタデータ 10 n メタデータ︓ ビルドの過程で得られるアーティファクトを特徴づける情報 pいつ、だれが、どのような環境で作った、などのビルドにまつわる情報 pビルド時に取得・利⽤したOSS外部アーティファクトなどの依存関係に関する情報 n アーティファクトそのものの⽐較は難しいため、 メタデータを利⽤して作成時の状況や設定情報などから差分を取る n ビルドの再現を⾏う際の基礎情報にも利⽤可能 ● 作成⽇ 作成者 依存関係 設定情報 ビルドツール どんな設定下でビルドしたか どんな依存関係のある 外部アーティファクトを使ったか どんなツールを使って ビルドしたか 

11 現状の開発・運⽤現場における課題 

ある現場でのシステム開発の流れ 12 VCS 開発チーム 運⽤担当者 ①開発チームで 複数メンバーの ソースコード開発 ③CIサービスがソースコードと、 外部で配布されている依存する パッケージ(外部アーティファクト)を 取得・ビルドしてアーティファクトを ⽣成する ④アーティファクトを テスト環境に デプロイ ⑤QA担当者が QA実施 ⑥開発チームが アーティファクトを 所定の場所に 保管する ⑦運⽤チームが 開発チームの依頼に基いて アーティファクトを取得し、 本番環境にデプロイ (リリース)する ②開発チームが 開発したコードを VCSに保管する CIサービス テスト 環境 本番 環境 パッケージ配布元 インター ネット 外部アーティファクト アーティファクト ファイルサーバ (本番反映⽤) アーティファクト QA担当者 アーティファクト 

よくある課題 – ビルド・デプロイ 13 VCS 開発チーム 運⽤担当者 ①開発チームで 複数メンバーの ソースコード開発 ③CIサービスがソースコードと、 外部で配布されている依存する パッケージ(外部アーティファクト)を 取得・ビルドしてアーティファクトを ⽣成する ⑤QA担当者が QA実施 ⑥開発チームが アーティファクトを 所定の場所に 保管する ⑦運⽤チームが 開発チームの依頼に基いて アーティファクトを取得し、 本番環境にデプロイ (リリース)する CIサービス テスト 環境 本番 環境 パッケージ配布元 インター ネット 外部アーティファクト アーティファクト ファイルサーバ (本番反映⽤) アーティファクト QA担当者 アーティファクト 運⽤担当者が、デプロイ対象 のアーティファクトを探す際に 時間がかかる ⾃動化されていない場合、 作業そのものに時間がかかる デプロイ依頼のために、 アーティファクトを⼿動で配置したり、 ファイル名でバージョン管理するなど、 作業が煩雑 ②開発チームが 開発したコードを VCSに保管する ネットワーク的な問題で、 外部アーティファクトの取得に時間 がかかる。またはアクセスできない。 ④アーティファクトを テスト環境に デプロイ 

よくある課題 – 外部アーティファクト起因のコンプライアンス問題 14 VCS 開発チーム 運⽤担当者 ①開発チームで 複数メンバーの ソースコード開発 ③CIサービスがソースコードと、 外部で配布されている依存する パッケージ(外部アーティファクト)を 取得・ビルドしてアーティファクトを ⽣成する ⑤QA担当者が QA実施 ⑥開発チームが アーティファクトを 所定の場所に 保管する ⑦運⽤チームが 開発チームの依頼に基いて アーティファクトを取得し、 本番環境にデプロイ (リリース)する CIサービス テスト 環境 本番 環境 パッケージ配布元 外部アーティファクト アーティファクト ファイルサーバ (本番反映⽤) アーティファクト QA担当者 アーティファクト 開発チームとCIサーバが 同⼀のパッケージを利⽤ していない場合、作成す るアーティファクトが想定 と異なる場合がある (例: バージョン違いなど) ライセンス違反となるパッケージを利⽤ している場合、コンプライアンスに影響 インター ネット 脆弱性を含むパッケージを利⽤して いる場合、システム全体に波及する ②開発チームが 開発したコードを VCSに保管する ④アーティファクトを テスト環境に デプロイ 

よくある課題 – 運⽤ 15 VCS 開発チーム ①開発チームで 複数メンバーの ソースコード開発 ③CIサービスがソースコードと、 外部で配布されている依存する パッケージ(外部アーティファクト)を 取得・ビルドしてアーティファクトを ⽣成する ⑤QA担当者が QA実施 ⑥開発チームが アーティファクトを 所定の場所に 保管する ⑦運⽤チームが 開発チームの依頼に基いて アーティファクトを取得し、 本番環境にデプロイ (リリース)する CIサービス テスト 環境 本番 環境 パッケージ配布元 インター ネット 外部アーティファクト アーティファクト ファイルサーバ (本番反映⽤) アーティファクト QA担当者 アーティファクト 本番環境で障害発⽣し、切り戻しが必要となった場合、 開発側からの指⽰がなければ再リリースできない (場合によっては、開発コードを戻し、再度ビルドを⾏う) 運⽤担当者 ②開発チームが 開発したコードを VCSに保管する 本番稼働してから脆弱性が発覚した場合、 構成がわからない場合に対処に時間がかかる ④アーティファクトを テスト環境に デプロイ 

「それって課題︖」と思うものもあった⽅もいるのでは︖ 16 

もっと効率化でき、プロセス改善が 『アーティファクト管理』の採⽤で実現できます 17 

ソースコード管理とアーティファクト管理の違い 18 ソースコード管理 n コーディングを⾏う間に必要（可変） n 開発担当間のコラボレーションを促進する pバージョン管理、トラッキング、ブランチ、タグ... コーディング ビルド 単体テスト テストデプロイ 結合テスト 本番デプロイ 運⽤ アーティファクト(実⾏形式)誕⽣ ソースコード管理が 必要な範囲 アーティファクト管理が 必要な範囲 アーティファクト管理 n ビルド後からずっと管理が必要（不変） n 開発担当〜QA担当〜運⽤担当のコラボレーション を促進する pメタデータ(ビルドにまつわる情報)を中⼼とした情報 を共有 … どちらも重要 開発 開発 開発 QA 開発 運⽤ 運⽤ 

19 バイナリ・リポジトリを⽤いたアーティファクト管理 アーティファクトの特徴に適している バイナリ・リポジトリを⽤いた管理がおすすめ︕ 

バイナリ・リポジトリとは 20 n アーティファクトの保管庫 p作成したアーティファクトをメタデータと共に保管する pインターネット上にあるパブリックなものが典型的だが、プライベートなものを⽴てることもできる n “バイナリ”の形で保管される pコンパイル型⾔語の場合、ビルド結果の多くはバイナリファイルとして出⼒ → ファイルをそのまま管理 pインタプリタ型⾔語の場合、実⾏可能な形式のファイルを⼀括出⼒ → まとめた形(zip圧縮)などで管理 Maven Central (Java) mirror.centos.org (Linux) Docker Hub (Docker) npmjs.org (JavaScript) pypi.org (Python) RubyGems.org (Ruby) archive.ubuntu.com (Linux) NuGet Gallery (.NET) Conan (C/C++) gocenter.io (Go) パブリックなバイナリ・リポジトリの例︓ 

n アプリケーション開発で作成・使⽤した、すべてのアーティファクトを⼀元管理する pローカルリポジトリで⾃チームで作成したアーティファクトの管理 n システムに関わるすべての⼈と共有 n バージョン管理機能を有しており、更新された場合も1つの名前で識別できる pリモートリポジトリで開発に使⽤する外部アーティファクトの管理(OSSパッケージなど) n パブリックなリポジトリのプロキシ・キャッシュとして動作する機能を有する n プロキシを通して取得されたアーティファクトを キャッシュしておき、開発・ビルド時に使⽤されるアーティファクトはこれを提供する リモート リポジトリ バイナリ・リポジトリによるアーティファクトの⼀元管理 21 アーティファクトの煩雑な管理が不要となる 使⽤すべき外部アーティファクトを、⾼速に提供することができる プライベートなリポジトリでアーティファクトを管理するポイント① ローカルリポジトリ QA担当者 運⽤担当者 開発担当者 新しいアーティファクト・メタデータを いつもの場所・名前で登録 デプロイするアーティファクトを いつもと同じ形で迷わず取得 想定外の動作がある場合、 メタデータを照らし合わせて検証 CIサービス パッケージ 配布元 開発担当者 外部 アーティファクト インター ネット プロキシ キャッシュ キャッシュを利⽤することで、 開発で使⽤したものと同⼀のものを 地理的に近いところから取得可能 

バイナリ・リポジトリによるメタデータ活⽤ 22 n ビルド時に取得したメタデータをアーティファクトに紐づけて保管し、活⽤が可能 p使⽤すべきアーティファクトの特定のための検索のキー情報として利⽤ p問題発⽣時に、過去のアーティファクト(ビルド結果)との差異を確認する情報として利⽤ p個別に追加可能であれば、ビルド対象となったソースコードとの紐付け ● 作成⽇ 作成者 依存関係 設定情報 ビルドツール トレーサビリティの確保ができ、ビルドの正しさ・信頼性の裏付け プライベートなリポジトリでアーティファクトを管理するポイント② 

バイナリ・リポジトリによるアクセス管理 23 n ⼀元管理されたアーティファクトを、適切なアクセス権限に応じて使⽤させることができる pどのリポジトリにアクセス可能とするか pどのファイルにアクセス可能とするか p登録・更新が可能か、読み取りのみ可能か n アーティファクトを他チームに対して共有においても、最新のものがすぐに提供できる p他拠点のメンバーに対しても即時提供できる p社外パートナーと共有する場合も、ユーザ管理＋アクセス管理により対応可能 セキュリティ・コンプライアンスの確保ができる チーム開発時の効率的な共有を実現できる プライベートなリポジトリでアーティファクトを管理するポイント③ QA担当者 運⽤担当者 開発担当者A Read/Write 開発担当者B Read Read Read 開発者 関連のない ユーザ パートナー開発者 Read/Write 社内開発者 Read プロジェクトA プロジェクトB Read 参照不可 

JFrog Artifactoryのご紹介 24 n JFrogが提供するバイナリ・リポジトリマネージャ p クラウド・オンプレミス双⽅設置可能 n Artifactoryの特徴 p ⾼いユニバーサル性 n 30以上のパッケージマネージャに対応 p メタデータ管理が容易 n ビルド情報以外にもGitのバージョンやテスト状況など、 メタデータを追加で持たせることが可能 p ストレージ最適化 n チェックサムを⽤いたファイル管理 p 外部のツールとの統合が容易 n APIや専⽤CLI、プラグインなどを提供 対応パッケージ 

25 CI/CDにアーティファクト管理を採⽤するポイント 

ある現場でのシステム開発の流れ (再掲) 26 VCS 開発チーム 運⽤担当者 ①開発チームで 複数メンバーの ソースコード開発 ③CIサービスがソースコードと、 外部で配布されている依存する パッケージ(外部アーティファクト)を 取得・ビルドしてアーティファクトを ⽣成する ⑤QA担当者が QA実施 ⑥開発チームが アーティファクトを 所定の場所に 保管する ⑦運⽤チームが 開発チームの依頼に基いて アーティファクトを取得し、 本番環境にデプロイ (リリース)する CIサービス テスト 環境 本番 環境 パッケージ配布元 インター ネット 外部アーティファクト アーティファクト ファイルサーバ (本番反映⽤) アーティファクト QA担当者 アーティファクト ②開発チームが 開発したコードを VCSに保管する Point! Point! ④アーティファクトを テスト環境に デプロイ 

バイナリ・リポジトリ導⼊による効果 27 VCS 開発チーム ①開発チームで 複数メンバーの ソースコード開発 ③CIサービスがソースコードと、 外部で配布されている依存する パッケージ(外部アーティファクト)を 取得・ビルドしてアーティファクトを ⽣成する ⑤QA担当者が QA実施 CIサービス テスト 環境 本番 環境 パッケージ配布元 外部アーティファクト アーティファクト アーティファクト QA担当者 アーティファクト バイナリ・リポジトリ 外部アーティファクト アーティファクト インター ネット ⑥運⽤チームが QA結果を受けて 本番環境にデプロイ (リリース)する 運⽤担当者 トレーサビリティが確保されたアーティファクト を使い回すことによる品質向上 デプロイすべきアーティファクトの特定・取得が 容易になることによる効率向上・エラー軽減 アーティファクト管理を⾃動化の範囲内に 含めることが可能となり、効率向上・ミス軽減 ②開発チームが 開発したコードを VCSに保管する ④アーティファクトを テスト環境にデプロイ 

アーティファクト管理によるコンプライアンス強化 28 VCS 開発チーム ①開発チームで 複数メンバーの ソースコード開発 ③CIサービスがソースコードと、 外部で配布されている依存する パッケージ(外部アーティファクト)を 取得・ビルドしてアーティファクトを ⽣成する ⑤QA担当者が QA実施 CIサービス テスト 環境 本番 環境 パッケージ配布元 外部アーティファクト アーティファクト アーティファクト QA担当者 アーティファクト バイナリ・リポジトリ 外部アーティファクト アーティファクト インター ネット ⑥運⽤チームが QA結果を受けて 本番環境にデプロイ (リリース)する 運⽤担当者 ②開発チームが 開発したコードを VCSに保管する ④アーティファクトを テスト環境にデプロイ キュレーションした安全かつ正しいものを⾼速に 提供することで、セキュリティ・効率が向上 継続的にスキャンが実⾏されることによる 脆弱性に対するリスク低減 

29 アーティファクト管理により得られるメリット 

アーティファクト管理によって得られるメリット 30 n エンジニアの負荷軽減 p⾃動化可能な範囲を増やすことによる時間短縮・ミスの軽減 p問題発⽣時にメタデータを活⽤することによる調査・対応への負荷軽減 p新たなアーティファクトを⽣成する際のビルドにかかる時間短縮 n システム開発におけるコンプライアンスの向上 pメタデータを利⽤したビルドにかかるトレーサビリティの確保 pOSSなどの外部アーティファクトの継続的なセキュリティ・スキャンによる、脆弱性問題に対する初動対応の迅速化 pアーティファクトに対するアクセス管理や監査対応に対しても有効 n システムに関わる⼈全体を通した情報共有の容易化 pメタデータを通じ、開発・QA・運⽤全体を通した相互理解、情報共有が容易になる pDevOps(DevSecOps)導⼊の⼀歩として、機械的な作業は⾃動化するとより、さらに効果が得られる 

感覚的にはわかるけど、うまく説明できない… 31 導⼊するにも、ROIを語らないと予算が取れない… 

SB C&Sの佐藤さん、お願いします︕ 32 

確認完了 （開発側） 開発現場でよくある話 33 ケース︓log4j 運⽤担当者に顧客から連絡 「脆弱性が⾒つかったパッケージ使っていますか︖」 脆弱性発覚 運⽤担当者は開発側に当該パッケージの使⽤状況を確認 確認① （運⽤側→開発側） 開発担当者がソースコードを確認 確認② （開発側） 問 題 発 ⽣ ・確認するためには開発環境を整える必要がある ・逆コンパイルしないと確認ができない 脆弱性があるパッケージを 使⽤していた 使⽤していかなかった 顧客へ連絡 開発担当者は脆弱性対応し、再リリースするために 再ビルド・テスト・デプロイが発⽣ ⼯数:＋２⼈⽇ ⼯数:＋2⼈⽇ ⼯数:＋1⼈⽇ 脆弱性が⾒つかったパッケージの使⽤状況を回答するだけで、１⼈⽇以上の⼯数が発⽣︕ 対応が必要な場合、更なる作業⼯数が発⽣︕︕ 

どれくらいの⼯数がかかっている︖ 例えば... 前提︓エンジニア単価が50,000円/1⼈⽇ ・ 当該パッケージの使⽤状況確認 1⼈⽇ ・ 脆弱性対応が発⽣した場合、対応⼯数 ４⼈⽇〜 ケース︓log4j ▲50,000円 ▲200,000円 ⾒えない対応⼯数・損失が発⽣... <ざっくり対応⼯数の内訳＞ Ø 脆弱性対応作業＆ビルド １⼈⽇ Ø テスト環境準備 １⼈⽇ Ø QAテスト実施 １⼈⽇ Ø 本番環境へデプロイ＆リリース １⼈⽇ 

その他の問題 35 依存関係を調べる・確認作業に時間がかる 本来するべき作業ができないことによる影響 パッケージの使⽤状況を速やかに回答できない 顧客への信頼 低下リスク セキュリティリスク 損害リスク 問題が発⽣した場合 他プロジェクトの遅延リスク ⼯数の圧迫 ⾒えない対応⼯数・損失以上に様々なリスクを抱える状態 

36 まとめ 

まとめ 37 n 現状の開発・運⽤現場における課題 pある現場でのシステム開発の流れを挙げ、課題となりうるポイントを説明 p今現在”課題“と感じていないとしても、効率化できるポイントがある n アーティファクト管理 pバイナリ・リポジトリを⽤いたアーティファクト管理︓アーティファクトの⼀元管理、メタデータ活⽤、アクセス管理 pJFrog Artifactoryのご紹介 n CI/CDにアーティファクト管理を採⽤するポイント pある現場のシステム開発の改善ポイント︓トレーサビリティ、⾃動化、脆弱性問題への対策 n アーティファクト管理により得られるメリット p定性的︓エンジニアの負荷軽減、システム開発におけるコンプライアンスの向上、全体を通した情報共有の容易化 p定量的︓概算レベルで具体的にどの程度の効果があるかを説明 

実際にアーティファクト管理を導⼊する 38 導⼊にあたっての課題 n これまで費⽤をかけてきたCI/CDパイプラインをいきなり全てを変えるのは難しい n システム開発に関わる⼈全体とコンセンサスを取ってプロセスを⼤きく変更するのは難しい できることからやってみる n アーティファクト管理の重要性を共有できる仲間を増やす pエンジニアの負荷軽減や、会社としてのコンプライアンス向上、チーム全体での情報共有など、メリットは多くある n 部分的にアーティファクト管理を導⼊してみる p外部パッケージのプロキシ・キャッシュ、内部アーティファクト置き場、⾃動化の範囲を拡⼤ pJFrog Artifactoryなら、API・専⽤CLI・プラグインなどによって組み込みが容易になるようサポートしている 

JFrog Platform無料版でお試しください 39 n JFrog ArtifactoryをJFrog Platform無料版でお試しください︕ https://jfrog.com/ja/ JFrog Japan Blogで 無料版取得からArtifactory設定まで ご紹介しています︕ 

JFrog Workshopのお知らせ 40 n 2022/09/29(⽊) 10:30〜12:00 バーチャル(オンライン)開催予定 n JFrog Platform無料版を利⽤し、 Artifactory + Xray(セキュリティチェック機能)のハンズオンワークショップ OSS脆弱性の確認画⾯ メール、弊社Connpassページや各種SNSで まもなく開催案内をお送りします︕ Connpassページはこちら︕ 

41 Thank you 

42 Q & A 

43 Appendix 

JFrog Platformの全体像 44 監視、設定、管理者ダッシュボード インテリジェンスメトリクスの分析 すべてのソフトウェアパッケージと コンテナイメージを保存、管理 セキュリティとコンプライアンスの問題解決 (OSS脆弱性・ライセンス問題のチェック) クラウド、データセンターへ 安全なソフトウェア配布 デバイスフリートへの ソフトウェアデプロイ、運⽤、監視 エンドツーエンドのCI/CD⾃動化とオーケストレーション BUILD & TEST RELEASE DEPLOY VCS ソースコード リポジトリ On-premise and Hybrid Regional Sites Public Cloud Platforms IoT Edge 

JFrog Platform全体を活⽤したときの変化 45 VCS 開発チーム ①開発チームで 複数メンバーの ソースコード開発 ③CIサービスがソースコードと、 外部で配布されている依存する パッケージ(外部アーティファクト)を 取得・ビルドしてアーティファクトを ⽣成する ⑤QA担当者が QA実施し、 問題なければ プロモーション処理 テスト 環境 本番 環境 パッケージ配布元 外部アーティファクト アーティファクト アーティファクト QA担当者 アーティファクト 外部アーティファクト アーティファクト インター ネット ⑥運⽤チームが QA結果を受けて 本番環境にデプロイ (リリース)する 運⽤担当者 ②開発チームが 開発したコードを VCSに保管する アーティファクト リモートリポジトリ ローカルリポジトリ (本番⽤) ローカルリポジトリ (開発⽤) コンプライアンス関連 スキャン実施 CIサービス アーティファクト管理 ※QA担当者の プロモーションにより 本番⽤に⾃動コピー (メタデータ含む) ※ビルドにより⽣成 ※キャッシュ提供 による⾼速化 ④アーティファクトを テスト環境にデプロイ 

JFrog Xrayのご紹介 46 n JFrog Artifactoryと統合されたSCAソリューション p Artifactoryに保存されているアーティファクトを分析する n Xrayの特徴 p ⾼いユニバーサル性 n 主要なパッケージタイプをサポート p 再帰的なスキャンの実施 n Dockerイメージやzipファイルでパッケージ化されたものを含めて、 ベースレイヤーだけでなく、推移的依存関係を含めて確認できる p タイムリーかつ包括的な脆弱性データベースを利⽤ n VulnDB + NVD + JFrog Security Research p 継続的なモニタリング n 環境に対してデプロイした後もスキャン可能 対応パッケージ 再帰的なスキャン 

JFrog Pipelinesのご紹介 47 n ワンストップDevOpsのためのEnd-to-EndでCI/CDを実現 p サイロ化されたDevOpsツールを⼀元化 n Pipelinesの特徴 p リアルタイム可視性 n ダッシュボードでCI/CDの状況が確認可能 p Pipelines-as-Code n YAML構⽂でステップを標準化 バージョン管理、モジュール化され再利⽤可能 p セキュリティ・ファースト n パスワード情報などのシークレット管理、きめ細かなアクセス管理 p エンタープライズ対応 n ⽔平⽅向への拡張、HA環境サポート、集中管理型 リアルタイム可視性 Pipelines設定ファイル