モバイルゲーム開発におけるJenkinsクラウド時代のJenkins構築と管理テクニック.pdf

CEDEC2020 DAY3 09/04
https://cedec.cesa.or.jp/2020/session/detail/s5e831cb604422
昨今のソフトウェア開発ではCI/CD専門のクラウドサービスを利用することが
一般的になってきています。しかし、一般的なソフトウェア開発と比較して特殊な要件
が多いゲーム開発の現場においては、様々な理由からCI/CD環境として
Jenkinsを自前で構築することが多いと思います。
本発表では、Jenkins運用で起こりがちな問題、私達が提案するJenkins
構成のメリット、Terraform・AnsibleによるJenkinsと
ビルドマシンの構築など中心に紹介します。さらに、クラウドのmacOSや一般的な
クラウドCI/CDサービスとの併用など、さらにクラウドを活用していく未来の展望
についてもご紹介いたします。

Transcript

1. モバイルゲーム開発におけるJenkins 〜クラウド時代のJenkins構築と管理テクニック〜 加瀬 健太 (Kenta Kase) 株式会社ディー・エヌ・エー システム本部 品質統括部 品質管理部 SWETグループ 井口 恒志 (Hisashi Iguchi) 株式会社ディー・エヌ・エー システム本部 品質統括部 品質管理部 SWETグループ @ CEDEC2020 2020/09/4
2. 自己紹介 2 • 氏名 • 加瀬 健太（Kenta Kase）@Kesin11 • 所属 • 株式会社ディー・エヌ・エー SWET Gr. • 役割 • 自動テストの開発・導入サポート • CI/CD の活用促進や関連技術調査 • 趣味 • CI/CDサービスを触ること、自動化
3. 自己紹介 • 氏名 • 井口 恒志（Hisashi Iguchi）@hisa9chi • 所属 • 株式会社ディー・エヌ・エー SWET Gr. • 役割 • 自動テストの開発・導入サポート • CI/CD の活用促進や関連技術調査 • その他活動 • CircleCI Japan User Group Community Leaders 3
4. 目次 4 SWETとは？ Jenkins 構築と運用のこれまで SWETの取り組み 1 4 今後の展望 2 3
5. 目次 5 SWETとは？ Jenkins 構築と運用のこれまで SWETの取り組み 1 4 今後の展望 2 3
6. SoftWare Engineer in Test c.f.> Google SET「テストから見えてくるグーグルのソフトウェア開発」本を参照 6 4 3 2 1
7. 7 MISSION ソフトウェアを起点とした • DeNAサービス全般の品質向上 • DeNAエンジニアの開発生産性向上 により、価値ある物を素早く提供できるようにする VISION MAKE TESTING FUN, SMART, AND DELIGHTING END-USERS 4 3 2 1
8. Make Testing Fun, Smart, and Delighting End-Users • Fun • テスティングを楽しくクリエイティブなものにしたい • Smart • 定型的なテストを人の手を煩わせず実現したい • テストによるフィードバックを上手に活用 • Delighting End-Users • エンドユーザをデライトさせるための様々な品質特性をテスティングで向上 させます 8 4 3 2 1
9. 9 4 3 2 1 SWETの取り組みを 定期的に投稿 https://swet.dena.com もしくは SWET Blog で検索
10. SWET のプロジェクトへの関わり • ソフトウェアテスト技術分野ごとのチーム • アーキテクチャ • 自動テスト • プロセス（CI/CD） • それぞれのチームが様々な技術領域の案件へサポート • QAによるテスト工程よりも前の工程で品質･生産性の向上 • デバッグの効率化･工数削減などテスト技術の蓄積 • テスト全般の実行環境･プロセスサポート･サービス化 10 4 3 2 1 開発チームに技術として蓄積してさらには運用していけるようにもサポート 我々が所属するチーム 開発プロセスにてCI/CDを効果的に活用できるように ゲーム開発案件への取り組みを開始
11. 目次 11 SWETとは？ Jenkins 構築と運用のこれまで SWETの取り組み 1 4 今後の展望 2 3
12. CI/CD に Jenkins を利用している理由 • アプリの定期的なビルド • 特定な環境に依存していないかの早期発見 • 最新版を容易にインストール可能 • チームメンバーが容易にビルド可能 • アプリのビルドに速度が求められる • 高スペックなマシンが必要 • クラウドCI/CDサービスが提供しているマシンではスペック不足な場合あり • ネットワークの転送コスト • 膨大な量のアセットデータ • ビルド時などのデータ転送がビルド時間に影響 12 1 4 3 2 Jenkins master / agent を社内ネットワーク上に構築して利用するケースが多い
13. Jenkins 環境構築する上での前提 • 全社共通の Jenkins をサービスとして提供している部門なし • 運用コストがとてつもなく高い • master / plugin の更新 • ユーザ、権限、ジョブの管理 • 案件とは無関係な人が情報に触れられないようにする • 協力会社との取り決めにより分ける必要性 • 秘匿情報が漏れることの防止 • 権限管理よりも効果的 13 1 4 3 2 プロジェクト毎に Jenkins を構築
14. Jenkins 環境構築 • 構築タイミング • 開発開発初期 • 構成 • 初期は master のみの1台構成が多い • 物理マシン（macOS） • ジョブも master で実施 14 1 4 3 2 Jenkins master ・開発メンバーが少数 ・ビルドの頻度が低い
15. Jenkins 環境構築 • 構築方法 • 手動で構築 • 物理マシンの手配 • 必要なツールをインストール • Jenkins / Xcode / Unity / Android SDK,NDK など • ビルドジョブを作成して動作確認 • 担当者 • エンジニア（Jenkins 構築経験者 or 未経験者） 15 1 4 3 2 システム構成などを経験者にヒアリング or 世の中の事例を調査しつつ実施
16. Jenkins の運用 - master に関して • ホストマシンのメンテナンス • OSのアップデート • システムエラーなど発生時の調査・問題解決 • 社内用ツールのアップデートなど • 不要データの削除 • Jenkins master のメンテナンス • version update • システム設定の管理 • plugin の メンテナンス • インストールとアップデート • アップデートによるシステム設定やジョブの修正 16 1 4 3 2
17. Jenkins の運用 - agent に関して • 追加タイミング • 開発の進行状況 • 並行開発やメンバー増加 • ジョブ実行待ち時間増加 • ホストマシンの故障 • メンテナンス • 新規ツールの手動インストール • 不要データの削除 • 不要ジョブのワークスペース • Xcode の Archive ファイル 17 1 4 3 2 Jenkins master macOS agent Jenkins master 初期 macOS agent Jenkins master macOS agent macOS agent 運用
18. 18 という構築・運用のため 発生しうるリスクやコストが いくつか存在 1 4 3 2
19. 起こりがちな問題 • マシンの運用コスト大 • オンプレの master / agent 管理 • OSのアップデート • 監視や可用性の仕組み構築して運用 • ディスクの不要データ削除 • Jenkins の成果物の保存など物理マシンではストレージに限界あり • ビルドに必要なツールのセットアップ • インストールするバージョンなども管理 19 1 4 3 2
20. macOS agent 起こりがちな問題 • agent の環境差異 • ジョブの改造やエラー解決により agent へ新規ツールのインストール • ジョブの新規追加時に特定の agent で動作させようとする 20 1 4 3 2 Jenkins master macOS agent macOS agent インストール インストール漏れ 統一性が失われる 特定の agent でしか動作しないジョブが複数存在して実行に偏り
21. 起こりがちな問題 • agent 追加時のセットアップコスト • ドキュメント化されていても手動でセットアップは面倒 • agent に環境差異があると必要なツールを洗い出す必要あり • 余計なコスト発生 21 1 4 3 2 Jenkins master macOS agent ① 調査 macOS agent ② セットアップ ③ ジョブの動作確認 macOS agent
22. 起こりがちな問題 22 1 4 3 2 • Jenkins master / agent の停止時間の発生 • 社内にマシンを持つことで法定点検などによる停電 • 社内用のツールなどのアップデート時 • 新規追加マシン調達のリードタイム • 急遽必要となった場合に対応困難 • 先を見越しての申請が必要 • マシン設置場所の問題 • 弊社で開発チームの近くに設置する場合が多いため以下の問題 • スペース問題 • 電源容量問題
23. 23 SWETとしては ゲームをより面白くすることに 注力してもらえるように 開発生産性を向上さたい 1 4 3 2
24. 目次 24 SWETとは？ Jenkins 構築と運用のこれまで SWETの取り組み 1 4 今後の展望 2 3
25. SWETの取り組み 1. パイプライン構成例 • 基本的な構成を定義 2. Jenkins の構成 • 1 を運用可能な master / agent 構成の定義 3. セットアップの自動化 • master / agent (Linux / macOS) • 監視とアラート 4. 運用のコスト削減施策 • 成果物のGCS保存 / fastlane match 25 1 2 4 3 複数のタイトルで 活用可能
26. 26 1. パイプライン構成例 1 2 4 3
27. ビルドパイプライン - iOS / Android クライアントビルド 27 1 2 4 3 画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/m https://github.com/logos
28. ビルドパイプライン - iOS / Android クライアントビルド 28 1 2 4 3 ・簡易的なチェック ・ビルド時の失敗を極力減らすため チェック完了までの時間は極力短く 画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/m https://github.com/logos
29. ビルドパイプライン - iOS / Android クライアントビルド 29 1 2 4 3 ビルドタスクは用途に応じて分類 ・ナイトリータスク ・QAリリース用のアプリ作成などに利用 ・マニュアルタスク ・開発者がビルド確認など利用 ・日中定期タスク ・ビルドエラーなど早期発見に利用 画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/m https://github.com/logos
30. ビルドパイプライン - iOS / Android クライアントビルド 30 1 2 4 3 ストレージ枯渇問題に対してGCSを活用 画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/m https://github.com/logos
31. ビルドパイプライン - iOS / Android クライアントビルド 31 1 2 4 3 画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/m https://github.com/logos 1つの問題 これらジョブは Unity を利用するジョブが多い Unityがインストールされている macOS にジョブが集中
32. ビルドパイプライン - iOS / Android クライアントビルド 32 1 2 4 3 macOSを利用したジョブが詰まりやすい なるべくLinux での実行に寄せていく • Unityを利用したクライアントビルドプロセスを完全分割 • iOS / Android プロジェクトのエクスポート : macOS • クライアントビルド • iOS : macOS / Android : Linux • マージ前の簡易チェックも可能な限り Linux • クライアントビルド完了までに数時間がかかる • キュー待ち後にビルドが始まり失敗などの可能性もある • 確認サイクル鈍化 • ビルドジョブの改善が困難 • 開発者が利用していないタイミング実施する必要あり • macOS agent はスケールが容易でない 画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/m https://github.com/logos
33. 33 macOS だけでなく Linux も活用して ジョブの実行負荷を分散させる必要あり 1 4 3 2
34. 34 2. Jenkins 構成 1 2 4 3
35. Jenkins 構成の定義 • 構成 • master - agent 構成（agentは複数台） 35 1 2 4 3 macOS agent Linux agent Jenkins master macOS agent GCS GCP 社内 JNLP 成果物
36. macOS agent macOS agent 社内 Jenkins 構成の定義 • 構成 • master - agent 構成（agentは複数台） 36 1 2 4 3 ・社内事情によるダウンタイム削減 ・GCS利用によるストレージ枯渇問題の解決 ・Linux agent のスケーラビリティ確保 Linux agent Jenkins master GCS GCP JNLP 成果物
37. Jenkins 構成の定義 • 構成 • master - agent 構成（agentは複数台） 37 1 2 4 3 Linux agent Jenkins master GCS GCP 成果物 JNLP ・冗長性を確保 ・OSやツールの update 検証が可能 macOS agent macOS agent 社内
38. Jenkins 構成の定義 • 構成 • master - agent 構成（agentは複数台） 38 1 2 4 3 macOS agent Linux agent Jenkins master macOS agent GCS GCP 社内 JNLP 成果物
39. macOS agent Linux agent Jenkins master macOS agent GCS GCP 社内 JNLP 成果物 Jenkins 構成の定義 • 構成 • master - slave 構成（slaveは複数台） 39 1 2 4 3 手順書が整備されていたとしても手動ではかなり面倒
40. 40 開発者には ゲームをより面白くすることに 注力してもらえるように 自動化の仕組みを提供 1 2 4 3
41. 41 3. セットアップの自動化 1 2 4 3
42. 42 TerraformとAnsibleによる ビルドマシンの自動構築 1 2 4 3
43. 自動構築する理由 1. ビルドマシンの台数が増えると手動管理に限界がある 2. 極力コードで管理することで属人化を排除したい • スクリプトのレビューが可能 • 誰が実行しても同じ構成になる • 他チームへの展開が容易になる 3. ビルドマシン構築のノウハウを会社で横展開させたい • 新規タイトルを立ち上げるときに「強くてニューゲーム」で始められるように • 構築手順書の作成だけではスケールさせることが難しい • スクリプトを共有するだけで同じ構成から始められる 43 1 2 4 3
44. 44 TerraformによるJenkinsのインフラ構築 1 2 4 3
45. TerraformによるJenkinsのインフラ構築 • Jenkins周りで使用するGCPの各リソースの管理 • Jenkins master • GCE n1-standard-1 ubuntu • Linuxビルドマシン • GCE n1-standard-2 ubuntu • Jenkinsの成果物用ストレージ • GCSのバケット2種類 • 詳細は後述 45 Compute Engine Cloud Storage Cloud Storage Compute Engine 画像引用: https://cloud.google.com/icons https://www.jenkins.io/artwork/ 1 2 4 3
46. Terraformの運用 • Terraformを実行するだけで初期の構築は完了 • 構築後の運用もTerraformで行う • スクリプトを修正して再度 terraform apply するだけ • 実際の運用事例 • GCEのディスク容量の追加 • ディスク使用量が圧迫されてきたタイミングで柔軟に増やす • GCEのインスタンスタイプの変更 • CPUやメモリのスペックが物足りなくなったらスケールアップ 46 1 2 4 3
47. Terraform運用のメリット • コード化されているため現在の構成情報をチーム全員が把握できる • コードを共有することで他チームへの展開もすぐに可能 • GCPのリソース追加に加えて変更もレビュー可能 • 実際の反映作業は terraform apply するだけなので簡単 • 全体的にインフラ構築の属人化を減らすことができる 47 1 2 4 3
48. 48 Ansibleによるプロビジョニング 1 2 4 3
49. Jenkins master • Jenkins本体をインストール • Jenkinsのおすすめプラグイン一式をインストール • CLIで行うためにグループメンバー自作のOSSを使用 • https://github.com/Kuniwak/jenkins-plugin-fixator • ビルドマシン監視用ツール一式のインストール • Telegraf, InfluxDB, Chronograf, Kapacitor • 詳しくは後述 49 1 2 4 3
50. Macビルドマシン • 役割 • UnityやmacOSが必要なジョブ • UnityからXcode、Gradleのエクスポート • iOSアプリのビルド • インストールするツール • Unity • Xcode • Android SDK, NDK • 監視用agent（Telegraf） • Jenkinsに接続するためのagent.jar 50 Linuxビルドマシン • 役割 • UnityやmacOSを使う必要がないジョブ • AndroidアプリのGradleビルド • Dockerを使うジョブ • その他雑用 • インストールするツール • Docker • .NET • Android SDK, NDK • 監視用agent（Telegraf） • Jenkinsに接続するためのagent.jar 1 2 4 3
51. プロビジョニング詳細 • 各種ツールのインストール • 基本的にパッケージマネージャでインストール • Ubuntu • aptを使用。難しいことはほぼない • macOS • Homebrew, Homebrew Caskを使用 • XcodeはOSSのxcode-installを使用 • 各種ツールをインストールするroleは自作 • 将来はAnsible Galaxyを活用するかも • インストール中にインタラクティブが操作が求められる場合も自動化 • Ansibleのexpect機能や、yesコマンド, expectコマンドを直接使用する • 特定のファイルを配置することで回避できるツールは事前に配布しておく 51 1 2 4 3
52. ビルドマシンの構成設定ファイル • ビルドマシン毎に設定ファイルを用意する • インストールするツールのバージョンを書く • 現在のマシンの構成をコードから把握できる 52
53. どうしても手動対応が必要なもの • 開発チームから急ぎでツールのインストールを求められた場合 • 実際はこのパターンが多い • 極力aptやHomebrewでインストールしてもらい、後日Ansibleに追加する • インストール時のコマンドや手順のメモを残してもらうことが重要 • UnityはUnity Hubから手動でインストール • Unity Hubと同様のフローで自動化する方法を調査できていないため • Unityのバージョンアップはそれほど頻繁ではないので現状は問題ではない 53 1 2 4 3
54. 54 Ansibleで正しくプロビジョニング できることを担保する 1 2 4 3
55. Ansible PlaybookのCI（pull-request） • 正しくプロビジョニングできるかをPlaybook修正のpull-requestで必ずテストする • Test Kitchen + Vagrant • 実機を”汚さずに”毎回クリーンなVMを使用するため開発しやすく、再現性がある • ”自分の環境では動いた”問題の解消 • UbuntuはVagrant Cloudに用意されているイメージを使用して検証 • macOSは自前でイメージを作成して検証 55 create converge verify destroy VM作成 Ansible実行 検証スクリプト VM破棄 $ kitchen test macos-1015 1 2 4 3
56. Ansible PlaybookのCI（定期実行） • Ansibleは外部環境に強く依存するため”何もしていないのに壊れた”が普通に起こる • Pull-requestに加えて週1回の頻度でmasterブランチをテスト • 特にHomebrewとxcode-installで問題が起こりやすい • 何かエラーが起きたらまずはGitHubのIssueを見に行く • 最近起きた事例 • HomebrewでJava8のパッケージが廃止 • →AdoptOpenJDKに移行 • HomebrewでPython2系が廃止 • →Python3に完全移行 • Xcode11登場時にXcode10系がxcode-installでインストール不可能に • 自前で修正してxcode-installにパッチを送った 56 その都度Playbookを修正して対応していくしかない 1 2 4 3
57. 57 監視とアラート 1 2 4 3
58. Jenkins masterとビルドマシンはChronografでモニタリング • ディスク使用率 • メモリ使用率 • CPU使用率 58 1 2 4 3
59. Kapacitorで自動アラート通知 • Chronografと連携しているので設定は簡単 • ディスク、メモリ、CPU使用率 • 死活監視 59 1 2 4 3
60. 実際に役に立った事例 • ビルドマシンのMac miniがまれに突然反応しなくなる • 年に何回かまれに発生。原因不明 • 死活監視アラートで早期に気がつける • sshできないことを確認したら手動で実機を再起動させる • ディスクフルの事前回避 • ディスク使用率85%でwarning、90%超えでアラート • Jenkins master、LinuxビルドマシンはGCEのディスク拡張 • Terraformの修正、適用を余裕を持って行える • Mac miniは不要ファイルの削除 • 古いXcodeのアーカイブ • 古いJenkinsジョブのディレクトリなど 60 1 2 4 3
61. 61 4. 運用のコスト削減施策 1 2 4 3
62. 62 Jenkinsの成果物を GCSに保存 1 2 4 3
63. 成果物の容量問題 • ビルドしたバイナリなどをJenkinsの成果物として保存するのが一般的 • ビルドしたipa, apk • シンボル • Unityのログファイル • ビルド毎に数GBずつJenkins masterのディスクが消費されてしまう 63 1 2 4 3
64. 成果物をGCSに保存する • Google Cloud Storageを活用 • 従量課金制 • 容量の上限がないため成果物を保存する用途に適している • JenkinsのGCSプラグインを活用 • https://plugins.jenkins.io/google-storage-plugin/ • Jenkinsfileで扱いやすいように薄くラップした関数を自作している 64 1 2 4 3
65. GCSのライフサイクルとストレージクラスについて • ライフサイクル • 一定の日数で自動削除、ストレージクラスを変更することが可能 • ストレージクラス • Standard, Nearline, Coldline, Archive • 頻繁にアクセスする場合はStandardがお得 詳細は https://cloud.google.com/storage/pricing 65 Standard Nearline Coldline Archive 保存容量当たりの課金額 大 小 アクセス時の課金額 小 大 1 2 4 3
66. 2種類のバケットを使い分けてコスト管理 • 2つのバケットを用意して異なるポリシーで運用 • 一時保存用バケット • 手動実行のビルド、ナイトリービルドの成果物を保存 • Standard Storage • 30日経過したオブジェクトは自動削除 • 永続保存用バケット • QAやリリース提出用のビルドの成果物を保存 • Standard Storage & Coldline Storage • 最初はStandard、90日経過したオブジェクトを自動でColdlineに変更 • ライフサイクル機能を使うとGCSが自動で管理してくれる 66 1 2 4 3
67. GCSの費用について • Jenkins masterに成果物として保存し、PD-SSDの容量を増やしていく 運用と比較 • 簡略化のために単に1TBを保存する場合で計算 • 全てをStandard Storageで保存したとしても約1/10 • 永続保存用バケットはColdline Storageに自動で切り替わるのでさらに若干安くなる 67 1TBあたりの費用 GCE PD-SSD USD 221.0 GCS Regional Standard Storage USD 23.00 GCS Regional Coldline Storage USD 6.0 リージョンは東京（asia-northeast1） GCEはネットワーク、GCSはオペレーション毎に別途費用がかかりますが計算には含めていません 1 2 4 3
68. 68 その他の運用コスト削減策 1 2 4 3
69. その他の運用コスト削減策 • fastlane matchによる証明書とプロビジョニングプロファイルの管理 • 各ビルドマシンへの配布が1コマンドで完了する • 更新作業もデベロッパーサイトで作業せずにCLIから行うことが可能 • メリットが非常に多いためかなりオススメ • GCEのスナップショット機能でJenkins masterの検証環境を手軽に立ち上げる • Jenkins本体やプラグインバージョンを更新する際に検証環境で実験したい • スナップショット機能で稼働しているJenkinsと全く同じ環境を複製可能 • 数時間で検証環境の立ち上げと検証作業が完了 • ジョブ完了時にSlack通知の自動メンション • ジョブを実行したメンバーへのメンション機能をJenkinsfileとgroovyで実現 • ビルドジョブの分析基盤をBigQueryに構築 • 全体ビルド時間やステップ毎の時間などのデータを保存して可視化 69 1 2 4 3
70. 目次 70 SWETとは？ Jenkins 構築と運用のこれまで SWETの取り組み 1 4 今後の展望 2 3
71. 再掲：ビルドパイプライン - iOS / Android クライアントビルド 71 画像引用: https://cloud.google.com/icons https://www.jenkins.io/artwork/ https://github.com/logos 1 2 3 4
72. 現在のビルドパイプラインの問題点 • Unityが必要なジョブを担えるのがmacOSしかない • 実機の調達に時間がかかる • リモートワークを進める最近の事情的にこれ以上物理マシンを増やしたくない • 故障時のリスクが高い • スケーラビリティの確保が問題 72 1 2 3 4
73. クラウドサービスの活用 • クラウドのCI/CDサービス • 特徴 • 実機、インスタンスの管理が不要 • プロビジョニングが不要 • ジョブの設定がJenkinsよりも簡単 • VMやDocker上で動作するため一般的にスペックは実機より劣る • DeNAで利用しているサービス • CircleCI • Bitrise • 実機を借りるサービス • MacStadium 73 1 2 3 4
74. • https://circleci.com/ • SaaS型のCI/CDサービス • DeNAではCircleCI Server（オンプレ）を使用 • DeNAではmacOSマシンの契約をしていない • サーバーサイド開発のCIでは既に活用 • 以下のジョブはCircleCIでの実行に変えていきたい • Unityに依存していない • macOSに依存していない • 手動で複雑なパラメータの選択が必要ではない 74 画像引用: https://brandfolder.com/circleci 1 2 3 4
75. • https://www.bitrise.io/ • モバイルアプリ開発に特化したCI/CDサービス • DeNAではゲーム以外のアプリ開発で既に積極的に活用 • Unityサポートがロードマップに含まれている • 非常に期待しています 75 画像引用: https://www.bitrise.io/presskit 1 2 3 4
76. • https://www.macstadium.com/ • Mac miniなどの実機をクラウド上で借りられるサービス • 電源のON/OFFをコンソール上から可能 • 実機を置き換える、あるいは繁忙期に臨時で追加する運用などを想定 • DeNA内で既に活用実績あり • Unityを使用するビルドマシンとして使用できるか現在検証中 76 画像引用: https://www.macstadium.com/company/media 1 2 3 4
77. 将来のパイプラインの構成イメージ 77 画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/, https://github.com/logos https://brandfolder.com/circleci, https://www.bitrise.io/presskit, https://www.macstadium.com/company/media 1 2 3 4
78. 将来のパイプラインの構成イメージ 78 • Unityが必要だがマシンパワーや優先度が 高くないジョブをBitrise • Unityが不要なジョブはCircleCI 画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/, https://github.com/logos https://brandfolder.com/circleci, https://www.bitrise.io/presskit, https://www.macstadium.com/company/media 1 2 3 4
79. 将来のパイプラインの構成イメージ 79 • マシンパワーが必要なビルドジョブは 実機Mac & MacStadium • MacStadiumはネットワークの 転送コストがどうしても発生する • 若干軽い or 優先度が低いタスクを 任せるかもしれない 画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/, https://github.com/logos https://brandfolder.com/circleci, https://www.bitrise.io/presskit, https://www.macstadium.com/company/media 1 2 3 4
80. 80 まとめ
81. まとめ • Jenkinsの構築・運用において起こりがちな問題の紹介 • これまでの取り組み • パイプラインタスクの一部をmacOS以外のマシンに逃がす • Jenkinsのmaster – agent構成 • セットアップ自動化 • Terraform、Ansible • 監視とアラート • 成果物をGCSに保存 • 今後の展望 • クラウドサービスをさらに活用してスケーラブルな構成を目指す 81
82. 82 DeNA Tech の Twitter アカウントでは、 DeNA のエンジニアリングに関する 登壇資料やブログを紹介しています！ ぜひ Twitter をフォローしてみてください！
83. 83 4 3 2 1 SWETの取り組みを 定期的に投稿 https://swet.dena.com もしくは SWET Blog で検索
84. 84 End.
85. 関連資料 • Jenkins 環境構築・運用に関するSWETとしての取り組み GDM vol.40 エンジニア向け勉強会「Jenkinsの構築・運用パターン」 • https://speakerdeck.com/hisa9chi/jenkinshuan-jing-yun-yong-niguan- suruswettositefalsequ-rizu-mi 85
86. macOS以外のUnityの検討について • Linux版とWindows版 • DeNAのエンジニアはmacOSを使う人が多いため、ビルドマシンはMac miniが主流 • Linux版はとても期待している • クラウドのインスタンスでビルドが可能ならば圧倒的にスケールしやすいため • 現在開発中のタイトルではタイミングの問題で検証できなかった • Apple Siliconの件もあるので来年以降にどうなるかは完全に未定 86