Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Developer Experience向上のために導入したい「アーティファクト管理」

Developer Experience向上のために導入したい「アーティファクト管理」

2022/10/27 JFrog Webinar

今日のIT環境を取り巻く環境は変化しており、オープンソース・ソフトウェア(OSS)の活用、Dockerなどのコンテナ技術の活用、セキュリティに対するニーズの高まりなど、開発者はこれまで以上に多くのことに気を回し、手を動かす必要があります。さらにスピードが求められる世界が来たとき、対応できるでしょうか。

このウェビナーでは、ソフトウェアの「アーティファクト」にスポットを当て、特徴を踏まえた管理方法のベストプラクティスと、導入による現場での効果を挙げつつ、システム開発者のDeveloper Experienceを高めるためのヒントをお話します。

Yoshihisa Sato

October 27, 2022
Tweet

More Decks by Yoshihisa Sato

Other Decks in Technology

Transcript

  1. Developer Experience向上のために
    導入したい「アーティファクト管理」
    2022/10/27(木)  JFrog Webinar

    View full-size slide

  2. はじめに
    2
    Twitterが好きな方は
    #JFrog
    公開後、本ウェビナーに
    ご登録いただいたメール宛に
    お知らせします
    #JFrog
    ぜひツイートをお願いします
    本日の資料と動画は
    のちほど公開します!
    Zoom機能で
    ぜひ、ご参加ください!
    Q&A機能でご質問を
    書き込んでください
    いつでも、何度でも!
    チャットもご自由に
    お使いください
    ・ ご自身の現場のお話
    ・ 賑やかしなど・・・
    Q&A チャット

    View full-size slide

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

    View full-size slide

  4. アジェンダ
    4
    ▪ アーティファクトとは
    ▪ アーティファクトの管理方法
    ▪ 開発/運用におけるアーティファクト管理の重要性
    ▪ まとめ・Q&A

    View full-size slide

  5. Happy Employees make Happy Customers
    5
    ハッピーワーカーは
    ハッピーカスタマーにします






    ハッピーに働く人々
    Happy Employees💚
    ハッピーなお客様
    Happy Customers💚

    View full-size slide

  6. Developer Experience
    6
    Developer Experience(DX)
    開発者が製品を開発する際に感じる体験・経験
    *1: DX用語時点 Developer Experience
    https://www.arsaga.jp/knowledge/dx-technical-glossary/developer-experience/
    開発環境 組織 システム 評価体制

    View full-size slide

  7. 7
    アーティファクトとは

    View full-size slide

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

    View full-size slide

  9. このセッションにおける「アーティファクト」
    9
    ▪ アーティファクト:ビルドやパッケージングを経て生成される実行形式、または配布形式のファイル
    ▪ バイナリ、パッケージ、ライブラリなど様々な呼称がある
    JAR/WARパッケージ
    (Java)
    RPM/DEB パッケージ
    (Linux)
    Docker イメージ npm
    (JavaScript)
    PyPl パッケージ
    (Python)
    RubyGems
    (Ruby)
    ZIP/tarball ファイル ダイナミックリンク
    ライブラリ(DLL)
    (Windows)
    NuGet パッケージ
    (.NET)
    Go Module
    (Go)
    例:

    View full-size slide

  10. アーティファクトの4つの特徴
    10
    コーディング ビルド
    単体テスト
    テスト
    デプロイ
    結合テスト
    本番デプロイ
    運用
    アーティファクト誕生から運用、
    新たなものがデプロイされるまで
    使われ続ける
    アーティファクト誕生
    ① コンピュータ上の実行・配布形式である
    ▪コードとは異なり、依存関係の解決が確定した状態
    ▪一度ビルドされたら本番デプロイまで使い続ける
    ② ビルドすることに形が変わる
    ▪ソースコードが変化しなくとも、周辺状況によって同じ
    アーティファクトが生成されるとは限らない
    例: 依存関係のバージョン違い
    時点A
    ソース
    コード
    OSS-A 1.0.1
    OSS-B 1.0.1
    OSS-C 1.0.1
    ビルドツール アーティファクト
    時点B
    ソース
    コード
    OSS-A 1.0.1
    OSS-B 1.0.1
    OSS-C 1.0.2
    ビルドツール アーティファクト
    使用するOSSのバージョンが異なる (最新バージョンが出るなど )

    View full-size slide

  11. アーティファクトの4つの特徴 (Cont.)
    11
    ③ 数も種類も増え続けている
    ▪新たな開発方法・考え方の普及により、アーティファクト
    の作成回数や新たな種類のアーティファクトが増えてい

    ④ どんなアーティファクトか一見してわからない
    ▪多くの場合はバイナリファイル
    ○ 構成要素や信頼性を確認することができない
    ○ 差分を取ることができず、変化を捉えられない
    Docker / K8s / Serverless
    Microservices
    DevOps
    CD
    CI
    IoT
    Today
    2000
    ビルド回数が増加
    複数サービスの
    組み合わせ
    インフラも
    アーティファクトに
    01010101010010100100
    10010101010100101010
    10101010010101010101
    00101001010101010010
    011101010101010010…

    View full-size slide

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

    View full-size slide

  13. システム開発におけるアーティファクト管理の必要性
    13
    利用するアーティファクトを
    素早く特定する必要がある
    アーティファクト作成の背景を把
    握する必要がある
    利用するアーティファクトを
    まとめて管理する必要がある
    ● 数多く生成されるアーティファクトの中か
    ら、正しいものを選択して テストやリリー
    スする必要がある
    ● メタデータを検索することで、 特定できる
    ようになる
    ● 一度生成されたら不変的 であり、
    「いつ」「誰が」「何を」「どこで」といった情
    報を保持する必要がある
    ● 生成過程がわかることで、 信頼性向上
    ● 問題解決のための情報 としても活用でき

    ● システムの構成が複数サービスを
    利用する場合、組み合わせを含めて管
    理する必要がある
    ● 依存関係で使用するもの などの外部
    アーティファクトも管理が必要
    ● ビルド回数を減らし効率化できる
    ● テスト確認できたものを管理することで
    品質向上につながる
    作成日時
    作成者
    設定情報
    依存関係
    ….
    作成日時
    作成者
    作成環境
    設定情報
    ….
    作成日時
    作成者
    設定情報
    依存関係
    ….
    作成日時
    作成者
    依存関係
    取得元

    アーティファクトそのものだけではなく、メタデータと合わせて管理

    View full-size slide

  14. アーティファクト管理によるDX向上にむけた効果
    14
    1. 開発に関わる全てのエンジニアの負荷軽減
    ○ 問題発生時にメタデータを活用することによる調査・対応への負荷軽減
    ○ 信頼性・品質の高い過去のアーティファクトを利用できるため、再度ビルドする必要がなくなる(=負荷軽減)
    2. システム開発におけるリスクの低減
    ○ ビルド〜本番運用で一貫したメタデータを中心としたプロセスによるトレーサビリティの確保
    ○ 外部アーティファクトを含め、一元管理されたアーティファクトを利用することで均一化と、脆弱性などの問題
    に対する初動対応の迅速化
    3. フェーズ間のギャップが埋められる
    ○ メタデータを通じた相互理解・情報共有が容易になり、担当者の自律的な対応を支援

    View full-size slide

  15. 15
    アーティファクトの管理方法

    View full-size slide

  16. アーティファクトをどう管理すべきか
    16
    ▪ 案1: ファイルサーバでの管理:フォルダ構造やファイル命名規則などの一定ルールを設けて管理
    ○ 命名規則やフォルダ構造に意味があるため、場所・名前で一定判別できる
    ○ ファイル名以外の情報が得られず、関連する情報は管理できない(または別管理を要する)
    ○ 自動化の際に検討事項が多い(APIをどうするかなど)
    ▪ 案2: VCSでの管理:ソースコード同様にGitなどのVCSを使った管理
    ○ バージョン管理としての基本的な機能が備わっており、過去生成されたものも含めて管理できる
    ○ アーティファクトそのものの管理は可能だが、関連する情報は管理できない(または別管理を要する)
    ○ バイナリファイルの管理時に、容量消費が大きい
    ▪ 案3: バイナリ・リポジトリでの管理
    案1、案2はファイルそのものは管理できても
    「メタデータ」を合わせもてない

    View full-size slide

  17. バイナリ・リポジトリとは
    17
    ▪ アーティファクトの貯蔵庫・保管庫
    ○ 作成したアーティファクトをメタデータと共に保管する
    ○ アーティファクトは多くの場合、バイナリファイルの形式
    ○ インターネット上にあるパブリックなものが典型的
    ▪ プライベートなバイナリ・リポジトリ
    ○ アーティファクトをより適切に管理することができる
    ■ 開発・運用で生成・使用する全てのアーティファクトを一元管理できる
    ■ バージョン管理の他、メタデータも合わせて管理できる
    ■ アクセス権限制御も含めて対応可能
    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)
    例:

    View full-size slide

  18. ▪ アプリケーション開発で作成・使用した、すべてのアーティファクトを一元管理する
    ○ ローカルリポジトリで自チームで作成したアーティファクトの管理
    ■ システムに関わるすべての人と共有
    ■ バージョン管理機能を有しており、更新された場合も1つの名前で識別可能
    ○ リモートリポジトリで開発に使用する外部アーティファクトの管理
    ■ パブリックなリポジトリのプロキシ・キャッシュとして動作する機能を有する
    ■ プロキシを通して取得されたアーティファクトをキャッシュしておき、
    開発・ビルド時に使用されるアーティファクトはこれを提供する
    ■ セキュリティ担当者により安全性を担保したものを提供(キュレーション)
    バイナリ・リポジトリによるアーティファクトの一元管理
    18
    リモート
    リポジトリ
    アーティファクトの煩雑な管理が不要
    使用すべき外部アーティファクトを高速に提供可能
    ローカル
    リポジトリ
    QA担当者
    運用担当者
    開発担当者
    新しいアーティファクトと
    メタデータをいつもの
    場所・名前で登録
    デプロイする
    アーティファクトを
    いつもと同じ形で
    迷わず取得
    想定外の動作がある場合、
    メタデータを照らし合わせて検

    CIサービス
    パッケージ
    配布元
    開発担当者
    OSS
    インター
    ネット
    プロキシ
    キャッシュ
    キャッシュを利用することで、
    開発で使用したものと同一のものを
    地理的に近いところから取得可能

    View full-size slide

  19. バイナリ・リポジトリによるメタデータ管理
    19
    ▪ ビルド時に取得したメタデータをアーティファクトに紐づけて保管し、活用が可能
    ○ 使用すべきアーティファクトの特定のための検索のキー情報として利用
    ○ 問題発生時に、過去のアーティファクト(ビルド結果)との差異を確認する情報として利用
    ○ ビルド対象となったソースコードとの紐付け
    トレーサビリティの確保ができ、ビルドの正しさ・信頼性の裏付け
    作成日
    作成者・作成環境 依存関係
    設定情報

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  22. 22
    開発/運用におけるアーティファクト管理の重要性

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  26. セキュリティに関する問題
    26
    VCS
    開発チーム
    運用担当者
    ①開発チームで
     複数メンバーの
     ソースコード開発
    ③CIサービスがソースコードと、
     外部で配布されている依存する
     パッケージ(外部アーティファクト )を
     取得・ビルドしてアーティファクトを
     生成する
    ⑤QA担当者が
       QA実施
    ⑥開発チームが
     アーティファクトを
     所定の場所に
     保管する
    ⑦運用チームが
     開発チームの依頼に基いて
     アーティファクトを取得し、
     本番環境にデプロイ
     (リリース)する
    CIサービス
    テスト
    環境
    本番
    環境
    パッケージ配布元 インター
    ネット
    外部アーティファクト
    アーティファクト
    ファイルサーバ
    (本番反映用)
    アーティファクト
    QA担当者
    アーティファクト
    ②開発チームが
     開発したコードを
     VCSに保管する
    ④アーティファクトを
     テスト環境に
     デプロイ
    脆弱性を含むものを利用している場合、 シ
    ステム全体に波及する
    開発担当がバージョン違いなど、
    本来使用すべきではないものを利用 し
    ている場合、手戻りが発生する
    開発担当がライセンス違反となるものを
    利用している場合、コンプライアンスに影響
    本番稼働してから脆弱性が発覚した場合 、
    構成がわからない場合に 開発担当へ問い合わせが
    発生し、対処に時間がかかる。
    運用担当は対処そのものができない。

    View full-size slide

  27. 良いDXを生むための4つのファクター
    27
    1. アーキテクチャの適合
    ○ プロジェクトやチームに合わせて適切なアーキテクチャを選択する
    2. 優れたツール
    ○ 繰り返し行う必要があることは自動化していく
    3. すべてをバックアップするプロセス
    ○ 自動化されたチェックリストとして、毎回行うべき一貫した手順を定義する
    4. 毒のないチーム文化
    ○ 会社の存在意義、共通のゴールや社会へのインパクトなどを共有し、失敗も許容する
    *1: DX用語時点 Developer Experience
    https://www.arsaga.jp/knowledge/dx-technical-glossary/developer-experience/
    *2: Developer Experience.io Good Developer Experience
    https://developerexperience.io/practices/good-developer-experience

    View full-size slide

  28. アーティファクト管理のDX向上のための対応ポイント
    28
    ビルド 単体テスト テストデプロイ 結合テスト 本番デプロイ 運用
    アーティファクト誕生
    開発 開発 開発 QA 運用 運用
    2. 優れたツール: ツールの活用と自動化
    4. 毒のないチーム文化: チーム文化の醸成
    1. アーキテクチャの適合
    2. 優れたツール
    3. すべてをバックアップするプロセス
    4. 毒のないチーム文化
    3. すべてをバックアップするプロセス:
    各担当が責任を果たせるようなプロセスの整備

    View full-size slide

  29. CIサービス
    バイナリ・リポジトリ導入イメージ
    29
    VCS
    開発チーム
    ①開発チームで
     複数メンバーの
     ソースコード開発
    ③CIサービスがソースコードと、
     外部で配布されている依存する
     パッケージ(外部アーティファクト)を
     取得・ビルドしてアーティファクトを
     生成する ⑤QA担当者が
     QA実施し、
     問題なければ
     プロモーション処理
    パッケージ配布元
    外部アーティファクト
    QA担当者
    アーティファクト
    外部アーティファクト アーティファクト
    インター
    ネット
    ⑥運用チームが
     QA結果を受けて
     本番環境にデプロイ
     (リリース)する
    運用担当者
    ②開発チームが
     開発したコードを
     VCSに保管する
    リモート
    リポジトリ
    ローカル
    リポジトリ
    ④アーティファクトを
     テスト環境にデプロイ
    アーティファクト
    アーティファクト
    テスト
    環境
    本番
    環境
    バイナリ・リポジトリ

    View full-size slide

  30. CIサービス
    バイナリ・リポジトリ導入による効果
    30
    VCS
    開発チーム
    ①開発チームで
     複数メンバーの
     ソースコード開発
    ③CIサービスがソースコードと、
     外部で配布されている依存する
     パッケージ(外部アーティファクト)を
     取得・ビルドしてアーティファクトを
     生成する ⑤QA担当者が
     QA実施し、
     問題なければ
     プロモーション処理
    パッケージ配布元
    外部アーティファクト
    QA担当者
    アーティファクト
    外部アーティファクト アーティファクト
    インター
    ネット
    ⑥運用チームが
     QA結果を受けて
     本番環境にデプロイ
     (リリース)する
    運用担当者
    ②開発チームが
     開発したコードを
     VCSに保管する
    リモート
    リポジトリ
    ローカル
    リポジトリ
    ④アーティファクトを
     テスト環境にデプロイ
    アーティファクト
    アーティファクト
    テスト
    環境
    本番
    環境
    バイナリ・リポジトリ
    トレーサビリティが確保されたアーティファクトを
    使い回すことによる品質向上
    デプロイすべきアーティファクトの特定・取得が容易
    になることによる効率向上・エラー軽減

    View full-size slide

  31. CIサービス
    アーティファクト管理によるセキュリティ強化
    31
    VCS
    開発チーム
    ①開発チームで
     複数メンバーの
     ソースコード開発
    ③CIサービスがソースコードと、
     外部で配布されている依存する
     パッケージ(外部アーティファクト)を
     取得・ビルドしてアーティファクトを
     生成する ⑤QA担当者が
     QA実施し、
     問題なければ
     プロモーション処理
    パッケージ配布元
    外部アーティファクト
    QA担当者
    アーティファクト
    外部アーティファクト アーティファクト
    インター
    ネット
    ⑥運用チームが
     QA結果を受けて
     本番環境にデプロイ
     (リリース)する
    運用担当者
    ②開発チームが
     開発したコードを
     VCSに保管する
    リモート
    リポジトリ
    ローカル
    リポジトリ
    ④アーティファクトを
     テスト環境にデプロイ
    アーティファクト
    アーティファクト
    テスト
    環境
    本番
    環境
    バイナリ・リポジトリ
    キュレーションした安全かつ正しいものを高速に提供
    することで、セキュリティ・効率が向上
    継続的に安全性を確認されている外部
    アーティファクトを利用することによる、脆
    弱性に対するリスク低減
    外部アーティファクトが具体的に何を利用しているか
    確認できるため、脆弱性に対しても自律的な対応が
    可能

    View full-size slide

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

    View full-size slide

  33. まとめ
    34
    ▪ アーティファクトの管理方法
    ○ バイナリ・リポジトリを使った管理は、アーティファクトの特徴を考慮した管理が可能
    ■ 一元管理
    ■ メタデータの保管と活用
    ■ 高度なアクセス管理
    ▪ 開発/運用におけるアーティファクト管理の重要性
    ○ 適切なアーティファクト管理を行うことで、さまざまな課題の解決に繋がる
    ○ 個々が本来集中すべき業務に対する時間を十分に確保しつつ、全体でも繋がる要素を持つ

    View full-size slide

  34. アーティファクト管理によるDX向上にむけた効果(再掲)
    35
    1. 開発に関わる全てのエンジニアの負荷軽減
    ○ 問題発生時にメタデータを活用することによる調査・対応への負荷軽減
    ○ 信頼性・品質の高い過去のアーティファクトを利用できるため、再度ビルドする必要がなくなる(=負荷軽減)
    2. システム開発におけるリスクの低減
    ○ ビルド〜本番運用で一貫したメタデータを中心としたプロセスによるトレーサビリティの確保
    ○ 外部アーティファクトを含め、一元管理されたアーティファクトを利用することで均一化と、脆弱性などの問題
    に対する初動対応の迅速化
    3. フェーズ間のギャップが埋められる
    ○ メタデータを通じた相互理解・情報共有が容易になり、担当者の自律的な対応を支援
    ○ DevOps(DevSecOps)の一歩として、機械的な作業は自動化するとより効果が得られる

    View full-size slide

  35. 参考文献
    38
    • DX用語時点 「Developer Experience」 https://www.arsaga.jp/knowledge/dx-technical-glossary/developer-experience/
    • DeveloperExperience.io 「Good Developer Experience」https://developerexperience.io/practices/good-developer-experience

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide