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

2022/10/20 JFrog Webinar

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

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

Transcript

1. Developer Experience向上のために 知っておきたい「アーティファクト」 2022/10/20(木) 　JFrog Webinar
2. はじめに 2 Twitterが好きな方は #JFrog 公開後、本ウェビナーに ご登録いただいたメール宛に お知らせします #JFrog ぜひツイートをお願いします 本日の資料と動画は のちほど公開します！ Zoom機能で ぜひ、ご参加ください！ Q&A機能でご質問を 書き込んでください いつでも、何度でも！ チャットもご自由に お使いください ・ ご自身の現場のお話 ・ 賑やかしなど・・・ Q&A チャット
3. 自己紹介 3 ▪ Developer Advocate @ JFrog ▪ 「よしQ」と覚えていだけるとうれしいです ▪ 山形県鶴岡市からリモートワーク ▪ SIerでアプリケーション開発エンジニアやアーキテクト、ITコン サルなど経験 ▪ 提案〜要件定義〜設計・開発〜導入〜運用保守まで ▪ エンジニア目線で情報発信！ 佐藤 由久 SATO Yoshihisa @umekichi1984 @yoshiq-sato
4. Happy Employees make Happy Customers 4 ハッピーワーカーは ハッピーカスタマーにします ハッピーに働く人々 Happy Employees💚 ハッピーなお客様 Happy Customers💚
5. Developer Experience 5 Developer Experience(DX) 開発者が製品を開発する際に感じる体験・経験 *1: DX用語時点 Developer Experience https://www.arsaga.jp/knowledge/dx-technical-glossary/developer-experience/ 開発環境 組織 システム 評価体制
6. アジェンダ 6 ▪ アーティファクトとは ▪ アーティファクトの特徴 ▪ アーティファクト管理の重要性 ▪ まとめ・Q&A
7. 7 アーティファクトとは
8. 「アーティファクト」とは 8 ▪ 広義の意味では「ソフトウェアを作る過程で生み出されたもの」を指す ◦ 設計書 ◦ ソースコード ◦ ビルドやパッケージングを経て生成されるファイル ◦ テスト仕様書・エビデンス ◦ ログファイル　など
9. このセッションにおける「アーティファクト」 9 ▪ アーティファクト：ビルドやパッケージングを経て生成される実行形式、または配布形式のファイル ▪ バイナリ、パッケージ、ライブラリなど様々な呼称がある JAR/WARパッケージ (Java) RPM/DEB パッケージ (Linux) Docker イメージ npm (JavaScript) PyPl パッケージ (Python) RubyGems (Ruby) ZIP/tarball ファイル ダイナミックリンク ライブラリ(DLL) (Windows) NuGet パッケージ (.NET) Go Module (Go) 例：
10. 10 アーティファクトの特徴
11. 特徴1: コンピュータ上の実行・配布形式である 11 ▪ アーティファクト＝ビルドによって生成されるコンピュータ上の実行・配布形式 ◦ コンパイル型言語の場合、バイナリファイルが出力 ◦ インタプリタ型言語の場合、実行形式のファイルが出力 ◦ OSSとして配布される場合、主にバイナリファイルの形（ソフトウェア開発において、 98%がOSSを活用(*2)） ▪ ソースコードとは異なり、依存関係の解決が確定した状態 ▪ 一度ビルドされたら本番デプロイまで使い続け、ビルド以降のテストから運用までの各工程で使われる コーディング ビルド 単体テスト テストデプロイ 結合テスト 本番デプロイ 運用 アーティファクトが使われ続ける (1度生成したら本番デプロイまで同じものを使う ) アーティファクト誕生 *2: MONOist 「オープンソースソフトウェアの採用率は 98%に 　　　　　　　拡大、脆弱性を含む割合も増加の一途」 https://monoist.itmedia.co.jp/mn/articles/2105/24/news039.html
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
13. 特徴3: 数も種類も増え続けている 13 ▪ アジャイル開発やCI/CDの広がり 　　→ ビルド回数が増えており、都度アーティファクトが 　　　 生成される ▪ OSSなどのサードパーティが作成したアーティファクトの活用 　　→ 配布されるアーティファクトが増加している ▪ サーバレスなアーキテクチャやマイクロサービスの広がり 　　→ 1システムで利用するサービスが複数あり、 　　　 それぞれで使用されるアーティファクトが異なる ▪ IaC(Infrastructure as Code)やコンテナ技術の活用 　　→ 実行環境そのものがアーティファクトとして 　　　 扱われるようになった ▪ IoTの普及 　　→ 1つのシステムに必要なデバイスが増加している Docker / K8s / Serverless Microservices DevOps CD CI IoT Today 2000
14. 特徴4: どんなアーティファクトか一見してわからない 14 ▪ アーティファクトはメタデータで状態を示し、他と区 別する ◦ いつ、だれが、どの環境で作った、などビル ドにまつわる情報 ◦ 構成に含まれる依存関係の情報 ▪ メタデータを比較により差分を取る ▪ 内容を読むことができない ◦ 構成要素を捉えるのが難しい ◦ 信頼できるものかわからない ▪ 差分を取ることができない ◦ バイナリファイルの場合、そもそも不可 ◦ 複数ファイルの場合、全体比較が難しい 01010101010010100100 10010101010100101010 10101010010101010101 00101001010101010010 011101010101010010… 作成日 作成者・作成環境 依存関係 設定情報
15. システム開発におけるアーティファクト管理の必要性 15 利用するアーティファクトを 素早く特定する必要がある アーティファクト作成の背景を把 握する必要がある 利用するアーティファクトを まとめて管理する必要がある • 数多く生成されるアーティファクトの中か ら、正しいものを選択して テストやリリー スする必要がある • メタデータを検索することで、 特定できる ようになる • 一度生成されたら不変的 であり、 「いつ」「誰が」「何を」「どこで」といった情 報を保持する必要がある • 生成過程がわかることで、 信頼性向上 • 問題解決のための情報 としても活用でき る • システムの構成が複数サービスを 利用する場合、組み合わせを含めて管 理する必要がある • 依存関係で使用するもの などの外部 アーティファクトも管理が必要 • ビルド回数を減らし効率化できる • テスト確認できたものを管理することで 品質向上につながる 作成日時 作成者 設定情報 依存関係 …. 作成日時 作成者 作成環境 設定情報 …. 作成日時 作成者 設定情報 依存関係 …. 作成日時 作成者 依存関係 取得元 … アーティファクトそのものだけではなく、メタデータと合わせて管理
16. 16 アーティファクト管理の重要性
17. ソースコード管理とアーティファクト管理の違い 17 コーディング ビルド 単体テスト テストデプロイ 結合テスト 本番デプロイ 運用 アーティファクト誕生 開発 開発 開発 開発 QA 運用 運用 ソースコード管理が 必要な範囲 アーティファクト管理が 必要な範囲 ソースコード管理 ▪ コーディングを行う間に必要（可変） ▪ 開発担当間のコラボレーションを促進 ◦ バージョン管理、トラッキング、ブランチ、タグ... アーティファクト管理 ▪ ビルド後からずっと管理が必要（不変） ▪ 開発担当〜QA担当〜運用担当といった 組織・責務を横断したコラボレーションを促進 ◦ メタデータ(ビルドにまつわる情報)を中心とした情報を共有 どちらも重要
18. ある現場で行われる開発の流れ 18 VCS 開発チーム 運用担当者 ①開発チームで 　複数メンバーの 　ソースコード開発 ③CIサービスがソースコードと、 　外部で配布されている依存する 　パッケージ(外部アーティファクト )を 　取得・ビルドしてアーティファクトを 　生成する ⑤QA担当者が 　　　QA実施 ⑥開発チームが 　アーティファクトを 　所定の場所に 　保管する ⑦運用チームが 　開発チームの依頼に基いて 　アーティファクトを取得し、 　本番環境にデプロイ 　(リリース)する CIサービス テスト 環境 本番 環境 パッケージ配布元 インター ネット 外部アーティファクト アーティファクト ファイルサーバ (本番反映用) アーティファクト QA担当者 アーティファクト ②開発チームが 　開発したコードを 　VCSに保管する ④アーティファクトを 　テスト環境に 　デプロイ
19. システム開発時に起こりうる問題 19 VCS 開発チーム 運用担当者 ①開発チームで 　複数メンバーの 　ソースコード開発 ③CIサービスがソースコードと、 　外部で配布されている依存する 　パッケージ(外部アーティファクト )を 　取得・ビルドしてアーティファクトを 　生成する ⑤QA担当者が 　　　QA実施 ⑥開発チームが 　アーティファクトを 　所定の場所に 　保管する ⑦運用チームが 　開発チームの依頼に基いて 　アーティファクトを取得し、 　本番環境にデプロイ 　(リリース)する CIサービス テスト 環境 本番 環境 パッケージ配布元 インター ネット 外部アーティファクト アーティファクト ファイルサーバ (本番反映用) アーティファクト QA担当者 アーティファクト ②開発チームが 　開発したコードを 　VCSに保管する ④アーティファクトを 　テスト環境に 　デプロイ 昨今は脆弱性をつくようなセキュリティに 対する課題も多く挙がっている 自動化されている範囲が 限定的で、手作業も多い デプロイや実行時エラーの 原因究明で遅延 システム不具合で切り 戻しが発生する場合、戻 すアーティファクトも開発 側の申請ベース いずれの課題も開発側の戻ってくることが多く、DXの低減に繋がる可能性 前バージョンでビルドできたが、 新バージョンでビルドに失敗した際の原 因究明で遅延
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
21. アーティファクト管理のDX向上のための対応ポイント 21 ビルド 単体テスト テストデプロイ 結合テスト 本番デプロイ 運用 アーティファクト誕生 開発 開発 開発 QA 運用 運用 2. 優れたツール: ツールの活用と自動化 4. 毒のないチーム文化: チーム文化の醸成 1. アーキテクチャの適合 2. 優れたツール 3. すべてをバックアップするプロセス 4. 毒のないチーム文化 3. すべてをバックアップするプロセス: 各担当が責任を果たせるようなプロセスの整備
22. JFrog Platformの活用例 22 VCS 開発チーム ①開発チームで 　複数メンバーの 　ソースコード開発 ③CIサービスがソースコードと、 　外部で配布されている依存する 　パッケージ(外部アーティファクト)を 　取得・ビルドしてアーティファクトを 　生成する ⑤QA担当者が 　QA実施し、 　問題なければ 　プロモーション処理 パッケージ配布元 外部アーティファクト QA担当者 アーティファクト 外部アーティファクト アーティファクト インター ネット ⑥運用チームが 　QA結果を受けて 　本番環境にデプロイ 　(リリース)する 運用担当者 ②開発チームが 　開発したコードを 　VCSに保管する アーティファクト リモート リポジトリ ローカルリポジトリ (本番用) ローカルリポジトリ (開発用) 脆弱性などのスキャン CIサービス アーティファクト管理 ※QA担当者の 　プロモーションにより 　本番用に自動コピー 　(メタデータ含む) ※ビルドにより生成 ※キャッシュ提供 　による高速化 ④アーティファクトを 　テスト環境にデプロイ アーティファクト アーティファクト テスト 環境 本番 環境
23. JFrog Platform全体を活用したときの課題への対応 23 VCS 開発チーム ①開発チームで 　複数メンバーの 　ソースコード開発 ③CIサービスがソースコードと、 　外部で配布されている依存する 　パッケージ(外部アーティファクト)を 　取得・ビルドしてアーティファクトを 　生成する ⑤QA担当者が 　QA実施し、 　問題なければ 　プロモーション処理 パッケージ配布元 外部アーティファクト QA担当者 アーティファクト 外部アーティファクト アーティファクト インター ネット ⑥運用チームが 　QA結果を受けて 　本番環境にデプロイ 　(リリース)する 運用担当者 ②開発チームが 　開発したコードを 　VCSに保管する アーティファクト リモート リポジトリ ローカルリポジトリ (本番用) ローカルリポジトリ (開発用) 脆弱性などのスキャン CIサービス アーティファクト管理 ※QA担当者の 　プロモーションにより 　本番用に自動コピー 　(メタデータ含む) ※ビルドにより生成 ※キャッシュ提供 　による高速化 ④アーティファクトを 　テスト環境にデプロイ アーティファクト アーティファクト テスト 環境 本番 環境 メタデータ メタデータ メタデータ 全体でツール活用による 自動化への移行が可能 開発はもちろん、 運用時もスキャンし、 セキュリティに配慮 メタデータ 問題発生時、 メタデータを利用して 自 律的に調査が可能 メタデータを使って過去 情報も簡単に探せるので、 切り戻しへの初動が早い メタデータ ビルド失敗時、前バージョンのメタデータと比較 し、原因ポイントを探しやすい
24. 24 まとめ
25. アーティファクト管理によるDX向上にむけた効果 25 1. 開発に関わる全てのエンジニアの負荷軽減 ◦ 問題発生時にメタデータを活用することによる調査・対応への負荷軽減 ◦ 信頼性・品質の高い過去のアーティファクトを利用できるため、再度ビルドする必要がなくなる（＝負荷軽減） 2. システム開発におけるリスクの低減 ◦ ビルド〜本番運用で一貫したメタデータを中心としたプロセスによるトレーサビリティの確保 ◦ 外部アーティファクトを含め、一元管理されたアーティファクトを利用することで均一化と、脆弱性などの問題 に対する初動対応の迅速化 3. フェーズ間のギャップが埋められる ◦ メタデータを通じた相互理解・情報共有が容易になり、担当者の自律的な対応を支援 ◦ DevOps(DevSecOps)の一歩として、機械的な作業は自動化するとより効果が得られる
26. 次回ウェビナーのお知らせ 26 管理方法のベストプラクティスと、 導入による現場での効果について 詳しくご説明します！
27. 27 Thank you
28. 28 Q & A
29. 参考文献 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
30. 30 Appendix
31. JFrog Platformの全体像 31 監視、設定、管理者ダッシュボード インテリジェンスメトリクスの分析 すべてのソフトウェアパッケージと コンテナイメージを保存、管理 セキュリティとコンプライアンスの問題 解決 (OSS脆弱性・ライセンス問題のチェッ ク) クラウド、データセンターへ 安全なソフトウェア配布 デバイスフリートへの ソフトウェアデプロイ、運用、監視 エンドツーエンドの CI/CD自動化とオーケストレーション BUILD & TEST RELEASE DEPLOY VCS ソースコード リポジトリ On-premise and Hybrid Regional Sites Public Cloud Platforms IoT Edge 本日使用するもの
32. JFrog Artifactoryのご紹介 32 ▪ JFrogが提供するバイナリ・リポジトリマネージャ ◦ アーティファクト管理に適した機能を用意 ▪ Artifactoryの特徴 ◦ 高いユニバーサル性 ▪ 30以上のパッケージマネージャに対応 ◦ メタデータ管理が容易 ▪ ビルド情報以外にもGitのバージョンやテスト状況など、 メタデータを追加で持たせることが可能 ◦ ストレージ最適化 ▪ チェックサムを用いたファイル管理 ◦ Platform外部のツールとの統合が容易 ▪ APIや専用CLI、プラグインなどを提供
33. JFrog Xrayのご紹介 33 ▪ JFrog Artifactoryと統合されたSCAソリューション ◦ Artifactoryに保存されているアーティファクトを分析する ▪ Xrayの特徴 ◦ 高いユニバーサル性 ▪ 主要なパッケージタイプをサポート ◦ 再帰的なスキャンの実施 ▪ Dockerイメージやzipファイルでパッケージ化されたものを含めて、 ベースレイヤーだけでなく、推移的依存関係を含めて確認できる ◦ タイムリーかつ包括的な脆弱性データベースを利用 ▪ VulnDB ＋ NVD ＋ JFrog Security Research ◦ 継続的なモニタリング ▪ 本番環境デプロイ後もスキャン可能
34. JFrog Pipelinesのご紹介 34 ▪ ワンストップDevOpsのためのEnd-to-EndでCI/CDを実現 ◦ サイロ化されたDevOpsツールを一元化 ▪ Pipelinesの特徴 ◦ リアルタイム可視性 ▪ ダッシュボードでCI/CDの状況が確認可能 ◦ Pipelines-as-Code ▪ YAML構文でステップを標準化 バージョン管理、モジュール化され再利用可能 ◦ セキュリティ・ファースト ▪ パスワード情報などのシークレット管理、きめ細かなアクセス管理 ◦ エンタープライズ対応 ▪ 水平方向への拡張、HA環境サポート、集中管理型 リアルタイム可視性 Pipelines設定ファイル