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

Developer Experience向上のために知っておきたい「アーティファクト」

Developer Experience向上のために知っておきたい「アーティファクト」

2022/10/20 JFrog Webinar

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

このウェビナーでは、開発者がソフトウェア開発を通して感じる”Developer Experience”を高めるために知っておいてほしいソフトウェアの「アーティファクト」について、それがどんなものなのかからお話しします。

Yoshihisa Sato

October 20, 2022
Tweet

More Decks by Yoshihisa Sato

Other Decks in Technology

Transcript

  1. Developer Experience向上のために
    知っておきたい「アーティファクト」
    2022/10/20(木)  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. Happy Employees make Happy Customers
    4
    ハッピーワーカーは
    ハッピーカスタマーにします






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

    View full-size slide

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

    View full-size slide

  6. アジェンダ
    6
    ▪ アーティファクトとは
    ▪ アーティファクトの特徴
    ▪ アーティファクト管理の重要性
    ▪ まとめ・Q&A

    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. 10
    アーティファクトの特徴

    View full-size slide

  11. 特徴1: コンピュータ上の実行・配布形式である
    11
    ▪ アーティファクト=ビルドによって生成されるコンピュータ上の実行・配布形式
    ○ コンパイル型言語の場合、バイナリファイルが出力
    ○ インタプリタ型言語の場合、実行形式のファイルが出力
    ○ OSSとして配布される場合、主にバイナリファイルの形(ソフトウェア開発において、 98%がOSSを活用(*2))
    ▪ ソースコードとは異なり、依存関係の解決が確定した状態
    ▪ 一度ビルドされたら本番デプロイまで使い続け、ビルド以降のテストから運用までの各工程で使われる
    コーディング ビルド 単体テスト テストデプロイ 結合テスト 本番デプロイ 運用
    アーティファクトが使われ続ける
    (1度生成したら本番デプロイまで同じものを使う )
    アーティファクト誕生
    *2: MONOist 「オープンソースソフトウェアの採用率は
    98%に
           拡大、脆弱性を含む割合も増加の一途」
    https://monoist.itmedia.co.jp/mn/articles/2105/24/news039.html

    View full-size slide

  12. 特徴2: ビルドするごとに形が変わる
    12
    ▪ ソースコードが変化しなくとも、ビルド時に同じアーティファクトが生成されるとは限らない
    依存関係のバージョン違い ビルド環境や実行環境の設定違い
    時点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のバージョンが異なる (最新バージョンが出るなど ) ビルド時に環境変数を埋め込む場合、端末による設定違い
    アーティファクト
    アーティファクト
    環境変数
    LIB=AAA,BBB
    SOME_VALUE1=XXXX
    SOME_VALUE2=YYYY

    環境変数
    LIB=AAA,BBB,CCC
    SOME_VALUE1=XXXX
    SOME_VALUE2=ZZZ

    端末A
    端末B

    View full-size slide

  13. 特徴3: 数も種類も増え続けている
    13
    ▪ アジャイル開発やCI/CDの広がり
      → ビルド回数が増えており、都度アーティファクトが
        生成される
    ▪ OSSなどのサードパーティが作成したアーティファクトの活用
      → 配布されるアーティファクトが増加している
    ▪ サーバレスなアーキテクチャやマイクロサービスの広がり
      → 1システムで利用するサービスが複数あり、
        それぞれで使用されるアーティファクトが異なる
    ▪ IaC(Infrastructure as Code)やコンテナ技術の活用
      → 実行環境そのものがアーティファクトとして
        扱われるようになった
    ▪ IoTの普及
      → 1つのシステムに必要なデバイスが増加している
    Docker / K8s / Serverless
    Microservices
    DevOps
    CD
    CI
    IoT
    Today
    2000

    View full-size slide

  14. 特徴4: どんなアーティファクトか一見してわからない
    14
    ▪ アーティファクトはメタデータで状態を示し、他と区
    別する
    ○ いつ、だれが、どの環境で作った、などビル
    ドにまつわる情報
    ○ 構成に含まれる依存関係の情報
    ▪ メタデータを比較により差分を取る
    ▪ 内容を読むことができない
    ○ 構成要素を捉えるのが難しい
    ○ 信頼できるものかわからない
    ▪ 差分を取ることができない
    ○ バイナリファイルの場合、そもそも不可
    ○ 複数ファイルの場合、全体比較が難しい
    01010101010010100100
    10010101010100101010
    10101010010101010101
    00101001010101010010
    011101010101010010…
    作成日
    作成者・作成環境 依存関係
    設定情報

    View full-size slide

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

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

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

    View full-size slide

  16. 16
    アーティファクト管理の重要性

    View full-size slide

  17. ソースコード管理とアーティファクト管理の違い
    17
    コーディング ビルド 単体テスト テストデプロイ 結合テスト 本番デプロイ 運用
    アーティファクト誕生
    開発 開発 開発 開発 QA 運用 運用
    ソースコード管理が
    必要な範囲
    アーティファクト管理が
    必要な範囲
    ソースコード管理
    ▪ コーディングを行う間に必要(可変)
    ▪ 開発担当間のコラボレーションを促進
    ○ バージョン管理、トラッキング、ブランチ、タグ...
    アーティファクト管理
    ▪ ビルド後からずっと管理が必要(不変)
    ▪ 開発担当〜QA担当〜運用担当といった
    組織・責務を横断したコラボレーションを促進
    ○ メタデータ(ビルドにまつわる情報)を中心とした情報を共有
    どちらも重要

    View full-size slide

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

    View full-size slide

  19. システム開発時に起こりうる問題
    19
    VCS
    開発チーム
    運用担当者
    ①開発チームで
     複数メンバーの
     ソースコード開発
    ③CIサービスがソースコードと、
     外部で配布されている依存する
     パッケージ(外部アーティファクト )を
     取得・ビルドしてアーティファクトを
     生成する
    ⑤QA担当者が
       QA実施
    ⑥開発チームが
     アーティファクトを
     所定の場所に
     保管する
    ⑦運用チームが
     開発チームの依頼に基いて
     アーティファクトを取得し、
     本番環境にデプロイ
     (リリース)する
    CIサービス
    テスト
    環境
    本番
    環境
    パッケージ配布元 インター
    ネット
    外部アーティファクト
    アーティファクト
    ファイルサーバ
    (本番反映用)
    アーティファクト
    QA担当者
    アーティファクト
    ②開発チームが
     開発したコードを
     VCSに保管する
    ④アーティファクトを
     テスト環境に
     デプロイ
    昨今は脆弱性をつくようなセキュリティに
    対する課題も多く挙がっている
    自動化されている範囲が
    限定的で、手作業も多い
    デプロイや実行時エラーの
    原因究明で遅延
    システム不具合で切り
    戻しが発生する場合、戻
    すアーティファクトも開発
    側の申請ベース
    いずれの課題も開発側の戻ってくることが多く、DXの低減に繋がる可能性
    前バージョンでビルドできたが、
    新バージョンでビルドに失敗した際の原
    因究明で遅延

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  23. JFrog Platform全体を活用したときの課題への対応
    23
    VCS
    開発チーム
    ①開発チームで
     複数メンバーの
     ソースコード開発
    ③CIサービスがソースコードと、
     外部で配布されている依存する
     パッケージ(外部アーティファクト)を
     取得・ビルドしてアーティファクトを
     生成する ⑤QA担当者が
     QA実施し、
     問題なければ
     プロモーション処理
    パッケージ配布元
    外部アーティファクト
    QA担当者
    アーティファクト
    外部アーティファクト
    アーティファクト
    インター
    ネット
    ⑥運用チームが
     QA結果を受けて
     本番環境にデプロイ
     (リリース)する
    運用担当者
    ②開発チームが
     開発したコードを
     VCSに保管する
    アーティファクト
    リモート
    リポジトリ
    ローカルリポジトリ
    (本番用)
    ローカルリポジトリ
    (開発用)
    脆弱性などのスキャン
    CIサービス
    アーティファクト管理
    ※QA担当者の
     プロモーションにより
     本番用に自動コピー
     (メタデータ含む)
    ※ビルドにより生成
    ※キャッシュ提供
     による高速化
    ④アーティファクトを
     テスト環境にデプロイ
    アーティファクト
    アーティファクト
    テスト
    環境
    本番
    環境
    メタデータ
    メタデータ
    メタデータ
    全体でツール活用による
    自動化への移行が可能
    開発はもちろん、
    運用時もスキャンし、
    セキュリティに配慮
    メタデータ
    問題発生時、
    メタデータを利用して 自
    律的に調査が可能
    メタデータを使って過去
    情報も簡単に探せるので、
    切り戻しへの初動が早い
    メタデータ
    ビルド失敗時、前バージョンのメタデータと比較
    し、原因ポイントを探しやすい

    View full-size slide

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

    View full-size slide

  25. 次回ウェビナーのお知らせ
    26
    管理方法のベストプラクティスと、
    導入による現場での効果について
    詳しくご説明します!

    View full-size slide

  26. 参考文献
    29
    • DX用語時点 「Developer Experience」 https://www.arsaga.jp/knowledge/dx-technical-glossary/developer-experience/
    • MONOist 「オープンソースソフトウェアの採用率は98%に拡大、脆弱性を含む割合も増加の一途」 https://monoist.itmedia.co.jp/mn/articles/2105/24/news039.html
    • DeveloperExperience.io 「Good Developer Experience」https://developerexperience.io/practices/good-developer-experience

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide