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

Slide 1

Slide 1 text

モバイルゲーム開発におけるJenkins 〜クラウド時代のJenkins構築と管理テクニック〜加瀬健太 (Kenta Kase) 株式会社ディー・エヌ・エーシステム本部品質統括部品質管理部 SWETグループ井口恒志 (Hisashi Iguchi) 株式会社ディー・エヌ・エーシステム本部品質統括部品質管理部 SWETグループ @ CEDEC2020 2020/09/4

Slide 2

Slide 2 text

自己紹介 2 • 氏名 • 加瀬健太（Kenta Kase）@Kesin11 • 所属 • 株式会社ディー・エヌ・エー SWET Gr. • 役割 • 自動テストの開発・導入サポート • CI/CD の活用促進や関連技術調査 • 趣味 • CI/CDサービスを触ること、自動化

Slide 3

Slide 3 text

自己紹介 • 氏名 • 井口恒志（Hisashi Iguchi）@hisa9chi • 所属 • 株式会社ディー・エヌ・エー SWET Gr. • 役割 • 自動テストの開発・導入サポート • CI/CD の活用促進や関連技術調査 • その他活動 • CircleCI Japan User Group Community Leaders 3

Slide 4

Slide 4 text

目次 4 SWETとは？ Jenkins 構築と運用のこれまで SWETの取り組み 1 4 今後の展望 2 3

Slide 5

Slide 5 text

目次 5 SWETとは？ Jenkins 構築と運用のこれまで SWETの取り組み 1 4 今後の展望 2 3

Slide 6

Slide 6 text

SoftWare Engineer in Test c.f.> Google SET「テストから見えてくるグーグルのソフトウェア開発」本を参照 6 4 3 2 1

Slide 7

Slide 7 text

7 MISSION ソフトウェアを起点とした • DeNAサービス全般の品質向上 • DeNAエンジニアの開発生産性向上により、価値ある物を素早く提供できるようにする VISION MAKE TESTING FUN, SMART, AND DELIGHTING END-USERS 4 3 2 1

Slide 8

Slide 8 text

Make Testing Fun, Smart, and Delighting End-Users • Fun • テスティングを楽しくクリエイティブなものにしたい • Smart • 定型的なテストを人の手を煩わせず実現したい • テストによるフィードバックを上手に活用 • Delighting End-Users • エンドユーザをデライトさせるための様々な品質特性をテスティングで向上させます 8 4 3 2 1

Slide 9

Slide 9 text

9 4 3 2 1 SWETの取り組みを定期的に投稿 https://swet.dena.com もしくは SWET Blog で検索

Slide 10

Slide 10 text

SWET のプロジェクトへの関わり • ソフトウェアテスト技術分野ごとのチーム • アーキテクチャ • 自動テスト • プロセス（CI/CD） • それぞれのチームが様々な技術領域の案件へサポート • QAによるテスト工程よりも前の工程で品質･生産性の向上 • デバッグの効率化･工数削減などテスト技術の蓄積 • テスト全般の実行環境･プロセスサポート･サービス化 10 4 3 2 1 開発チームに技術として蓄積してさらには運用していけるようにもサポート我々が所属するチーム開発プロセスにてCI/CDを効果的に活用できるようにゲーム開発案件への取り組みを開始

Slide 11

Slide 11 text

目次 11 SWETとは？ Jenkins 構築と運用のこれまで SWETの取り組み 1 4 今後の展望 2 3

Slide 12

Slide 12 text

CI/CD に Jenkins を利用している理由 • アプリの定期的なビルド • 特定な環境に依存していないかの早期発見 • 最新版を容易にインストール可能 • チームメンバーが容易にビルド可能 • アプリのビルドに速度が求められる • 高スペックなマシンが必要 • クラウドCI/CDサービスが提供しているマシンではスペック不足な場合あり • ネットワークの転送コスト • 膨大な量のアセットデータ • ビルド時などのデータ転送がビルド時間に影響 12 1 4 3 2 Jenkins master / agent を社内ネットワーク上に構築して利用するケースが多い

Slide 13

Slide 13 text

Jenkins 環境構築する上での前提 • 全社共通の Jenkins をサービスとして提供している部門なし • 運用コストがとてつもなく高い • master / plugin の更新 • ユーザ、権限、ジョブの管理 • 案件とは無関係な人が情報に触れられないようにする • 協力会社との取り決めにより分ける必要性 • 秘匿情報が漏れることの防止 • 権限管理よりも効果的 13 1 4 3 2 プロジェクト毎に Jenkins を構築

Slide 14

Slide 14 text

Jenkins 環境構築 • 構築タイミング • 開発開発初期 • 構成 • 初期は master のみの1台構成が多い • 物理マシン（macOS） • ジョブも master で実施 14 1 4 3 2 Jenkins master ・開発メンバーが少数・ビルドの頻度が低い

Slide 15

Slide 15 text

Jenkins 環境構築 • 構築方法 • 手動で構築 • 物理マシンの手配 • 必要なツールをインストール • Jenkins / Xcode / Unity / Android SDK,NDK など • ビルドジョブを作成して動作確認 • 担当者 • エンジニア（Jenkins 構築経験者 or 未経験者） 15 1 4 3 2 システム構成などを経験者にヒアリング or 世の中の事例を調査しつつ実施

Slide 16

Slide 16 text

Jenkins の運用 - master に関して • ホストマシンのメンテナンス • OSのアップデート • システムエラーなど発生時の調査・問題解決 • 社内用ツールのアップデートなど • 不要データの削除 • Jenkins master のメンテナンス • version update • システム設定の管理 • plugin のメンテナンス • インストールとアップデート • アップデートによるシステム設定やジョブの修正 16 1 4 3 2

Slide 17

Slide 17 text

Jenkins の運用 - agent に関して • 追加タイミング • 開発の進行状況 • 並行開発やメンバー増加 • ジョブ実行待ち時間増加 • ホストマシンの故障 • メンテナンス • 新規ツールの手動インストール • 不要データの削除 • 不要ジョブのワークスペース • Xcode の Archive ファイル 17 1 4 3 2 Jenkins master macOS agent Jenkins master 初期 macOS agent Jenkins master macOS agent macOS agent 運用

Slide 18

Slide 18 text

18 という構築・運用のため発生しうるリスクやコストがいくつか存在 1 4 3 2

Slide 19

Slide 19 text

起こりがちな問題 • マシンの運用コスト大 • オンプレの master / agent 管理 • OSのアップデート • 監視や可用性の仕組み構築して運用 • ディスクの不要データ削除 • Jenkins の成果物の保存など物理マシンではストレージに限界あり • ビルドに必要なツールのセットアップ • インストールするバージョンなども管理 19 1 4 3 2

Slide 20

Slide 20 text

macOS agent 起こりがちな問題 • agent の環境差異 • ジョブの改造やエラー解決により agent へ新規ツールのインストール • ジョブの新規追加時に特定の agent で動作させようとする 20 1 4 3 2 Jenkins master macOS agent macOS agent インストールインストール漏れ統一性が失われる特定の agent でしか動作しないジョブが複数存在して実行に偏り

Slide 21

Slide 21 text

起こりがちな問題 • agent 追加時のセットアップコスト • ドキュメント化されていても手動でセットアップは面倒 • agent に環境差異があると必要なツールを洗い出す必要あり • 余計なコスト発生 21 1 4 3 2 Jenkins master macOS agent ① 調査 macOS agent ② セットアップ ③ ジョブの動作確認 macOS agent

Slide 22

Slide 22 text

起こりがちな問題 22 1 4 3 2 • Jenkins master / agent の停止時間の発生 • 社内にマシンを持つことで法定点検などによる停電 • 社内用のツールなどのアップデート時 • 新規追加マシン調達のリードタイム • 急遽必要となった場合に対応困難 • 先を見越しての申請が必要 • マシン設置場所の問題 • 弊社で開発チームの近くに設置する場合が多いため以下の問題 • スペース問題 • 電源容量問題

Slide 23

Slide 23 text

23 SWETとしてはゲームをより面白くすることに注力してもらえるように開発生産性を向上さたい 1 4 3 2

Slide 24

Slide 24 text

目次 24 SWETとは？ Jenkins 構築と運用のこれまで SWETの取り組み 1 4 今後の展望 2 3

Slide 25

Slide 25 text

SWETの取り組み 1. パイプライン構成例 • 基本的な構成を定義 2. Jenkins の構成 • 1 を運用可能な master / agent 構成の定義 3. セットアップの自動化 • master / agent (Linux / macOS) • 監視とアラート 4. 運用のコスト削減施策 • 成果物のGCS保存 / fastlane match 25 1 2 4 3 複数のタイトルで活用可能

Slide 26

Slide 26 text

26 1. パイプライン構成例 1 2 4 3

Slide 27

Slide 27 text

ビルドパイプライン - iOS / Android クライアントビルド 27 1 2 4 3 画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/m https://github.com/logos

Slide 28

Slide 28 text

ビルドパイプライン - iOS / Android クライアントビルド 28 1 2 4 3 ・簡易的なチェック・ビルド時の失敗を極力減らすためチェック完了までの時間は極力短く画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/m https://github.com/logos

Slide 29

Slide 29 text

ビルドパイプライン - iOS / Android クライアントビルド 29 1 2 4 3 ビルドタスクは用途に応じて分類・ナイトリータスク・QAリリース用のアプリ作成などに利用・マニュアルタスク・開発者がビルド確認など利用・日中定期タスク・ビルドエラーなど早期発見に利用画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/m https://github.com/logos

Slide 30

Slide 30 text

ビルドパイプライン - iOS / Android クライアントビルド 30 1 2 4 3 ストレージ枯渇問題に対してGCSを活用画像引用: https://cloud.google.com/icons, https://www.jenkins.io/artwork/m https://github.com/logos

Slide 31

Slide 31 text

ビルドパイプライン - 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 にジョブが集中

Slide 32

Slide 32 text

ビルドパイプライン - 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

Slide 33

Slide 33 text

33 macOS だけでなく Linux も活用してジョブの実行負荷を分散させる必要あり 1 4 3 2

Slide 34

Slide 34 text

34 2. Jenkins 構成 1 2 4 3

Slide 35

Slide 35 text

Jenkins 構成の定義 • 構成 • master - agent 構成（agentは複数台） 35 1 2 4 3 macOS agent Linux agent Jenkins master macOS agent GCS GCP 社内 JNLP 成果物

Slide 36

Slide 36 text

macOS agent macOS agent 社内 Jenkins 構成の定義 • 構成 • master - agent 構成（agentは複数台） 36 1 2 4 3 ・社内事情によるダウンタイム削減・GCS利用によるストレージ枯渇問題の解決・Linux agent のスケーラビリティ確保 Linux agent Jenkins master GCS GCP JNLP 成果物

Slide 37

Slide 37 text

Jenkins 構成の定義 • 構成 • master - agent 構成（agentは複数台） 37 1 2 4 3 Linux agent Jenkins master GCS GCP 成果物 JNLP ・冗長性を確保・OSやツールの update 検証が可能 macOS agent macOS agent 社内

Slide 38

Slide 38 text

Jenkins 構成の定義 • 構成 • master - agent 構成（agentは複数台） 38 1 2 4 3 macOS agent Linux agent Jenkins master macOS agent GCS GCP 社内 JNLP 成果物

Slide 39

Slide 39 text

macOS agent Linux agent Jenkins master macOS agent GCS GCP 社内 JNLP 成果物 Jenkins 構成の定義 • 構成 • master - slave 構成（slaveは複数台） 39 1 2 4 3 手順書が整備されていたとしても手動ではかなり面倒

Slide 40

Slide 40 text

40 開発者にはゲームをより面白くすることに注力してもらえるように自動化の仕組みを提供 1 2 4 3

Slide 41

Slide 41 text

41 3. セットアップの自動化 1 2 4 3

Slide 42

Slide 42 text

42 TerraformとAnsibleによるビルドマシンの自動構築 1 2 4 3

Slide 43

Slide 43 text

自動構築する理由 1. ビルドマシンの台数が増えると手動管理に限界がある 2. 極力コードで管理することで属人化を排除したい • スクリプトのレビューが可能 • 誰が実行しても同じ構成になる • 他チームへの展開が容易になる 3. ビルドマシン構築のノウハウを会社で横展開させたい • 新規タイトルを立ち上げるときに「強くてニューゲーム」で始められるように • 構築手順書の作成だけではスケールさせることが難しい • スクリプトを共有するだけで同じ構成から始められる 43 1 2 4 3

Slide 44

Slide 44 text

44 TerraformによるJenkinsのインフラ構築 1 2 4 3

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Terraformの運用 • Terraformを実行するだけで初期の構築は完了 • 構築後の運用もTerraformで行う • スクリプトを修正して再度 terraform apply するだけ • 実際の運用事例 • GCEのディスク容量の追加 • ディスク使用量が圧迫されてきたタイミングで柔軟に増やす • GCEのインスタンスタイプの変更 • CPUやメモリのスペックが物足りなくなったらスケールアップ 46 1 2 4 3

Slide 47

Slide 47 text

Terraform運用のメリット • コード化されているため現在の構成情報をチーム全員が把握できる • コードを共有することで他チームへの展開もすぐに可能 • GCPのリソース追加に加えて変更もレビュー可能 • 実際の反映作業は terraform apply するだけなので簡単 • 全体的にインフラ構築の属人化を減らすことができる 47 1 2 4 3

Slide 48

Slide 48 text

48 Ansibleによるプロビジョニング 1 2 4 3

Slide 49

Slide 49 text

Jenkins master • Jenkins本体をインストール • Jenkinsのおすすめプラグイン一式をインストール • CLIで行うためにグループメンバー自作のOSSを使用 • https://github.com/Kuniwak/jenkins-plugin-fixator • ビルドマシン監視用ツール一式のインストール • Telegraf, InfluxDB, Chronograf, Kapacitor • 詳しくは後述 49 1 2 4 3

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

プロビジョニング詳細 • 各種ツールのインストール • 基本的にパッケージマネージャでインストール • Ubuntu • aptを使用。難しいことはほぼない • macOS • Homebrew, Homebrew Caskを使用 • XcodeはOSSのxcode-installを使用 • 各種ツールをインストールするroleは自作 • 将来はAnsible Galaxyを活用するかも • インストール中にインタラクティブが操作が求められる場合も自動化 • Ansibleのexpect機能や、yesコマンド, expectコマンドを直接使用する • 特定のファイルを配置することで回避できるツールは事前に配布しておく 51 1 2 4 3

Slide 52

Slide 52 text

ビルドマシンの構成設定ファイル • ビルドマシン毎に設定ファイルを用意する • インストールするツールのバージョンを書く • 現在のマシンの構成をコードから把握できる 52

Slide 53

Slide 53 text

どうしても手動対応が必要なもの • 開発チームから急ぎでツールのインストールを求められた場合 • 実際はこのパターンが多い • 極力aptやHomebrewでインストールしてもらい、後日Ansibleに追加する • インストール時のコマンドや手順のメモを残してもらうことが重要 • UnityはUnity Hubから手動でインストール • Unity Hubと同様のフローで自動化する方法を調査できていないため • Unityのバージョンアップはそれほど頻繁ではないので現状は問題ではない 53 1 2 4 3

Slide 54

Slide 54 text

54 Ansibleで正しくプロビジョニングできることを担保する 1 2 4 3

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

57 監視とアラート 1 2 4 3

Slide 58

Slide 58 text

Jenkins masterとビルドマシンはChronografでモニタリング • ディスク使用率 • メモリ使用率 • CPU使用率 58 1 2 4 3

Slide 59

Slide 59 text

Kapacitorで自動アラート通知 • Chronografと連携しているので設定は簡単 • ディスク、メモリ、CPU使用率 • 死活監視 59 1 2 4 3

Slide 60

Slide 60 text

実際に役に立った事例 • ビルドマシンのMac miniがまれに突然反応しなくなる • 年に何回かまれに発生。原因不明 • 死活監視アラートで早期に気がつける • sshできないことを確認したら手動で実機を再起動させる • ディスクフルの事前回避 • ディスク使用率85%でwarning、90%超えでアラート • Jenkins master、LinuxビルドマシンはGCEのディスク拡張 • Terraformの修正、適用を余裕を持って行える • Mac miniは不要ファイルの削除 • 古いXcodeのアーカイブ • 古いJenkinsジョブのディレクトリなど 60 1 2 4 3

Slide 61

Slide 61 text

61 4. 運用のコスト削減施策 1 2 4 3

Slide 62

Slide 62 text

62 Jenkinsの成果物を GCSに保存 1 2 4 3

Slide 63

Slide 63 text

成果物の容量問題 • ビルドしたバイナリなどをJenkinsの成果物として保存するのが一般的 • ビルドしたipa, apk • シンボル • Unityのログファイル • ビルド毎に数GBずつJenkins masterのディスクが消費されてしまう 63 1 2 4 3

Slide 64

Slide 64 text

成果物をGCSに保存する • Google Cloud Storageを活用 • 従量課金制 • 容量の上限がないため成果物を保存する用途に適している • JenkinsのGCSプラグインを活用 • https://plugins.jenkins.io/google-storage-plugin/ • Jenkinsfileで扱いやすいように薄くラップした関数を自作している 64 1 2 4 3

Slide 65

Slide 65 text

GCSのライフサイクルとストレージクラスについて • ライフサイクル • 一定の日数で自動削除、ストレージクラスを変更することが可能 • ストレージクラス • Standard, Nearline, Coldline, Archive • 頻繁にアクセスする場合はStandardがお得詳細は https://cloud.google.com/storage/pricing 65 Standard Nearline Coldline Archive 保存容量当たりの課金額大小アクセス時の課金額小大 1 2 4 3

Slide 66

Slide 66 text

2種類のバケットを使い分けてコスト管理 • 2つのバケットを用意して異なるポリシーで運用 • 一時保存用バケット • 手動実行のビルド、ナイトリービルドの成果物を保存 • Standard Storage • 30日経過したオブジェクトは自動削除 • 永続保存用バケット • QAやリリース提出用のビルドの成果物を保存 • Standard Storage & Coldline Storage • 最初はStandard、90日経過したオブジェクトを自動でColdlineに変更 • ライフサイクル機能を使うとGCSが自動で管理してくれる 66 1 2 4 3

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

68 その他の運用コスト削減策 1 2 4 3

Slide 69

Slide 69 text

その他の運用コスト削減策 • fastlane matchによる証明書とプロビジョニングプロファイルの管理 • 各ビルドマシンへの配布が1コマンドで完了する • 更新作業もデベロッパーサイトで作業せずにCLIから行うことが可能 • メリットが非常に多いためかなりオススメ • GCEのスナップショット機能でJenkins masterの検証環境を手軽に立ち上げる • Jenkins本体やプラグインバージョンを更新する際に検証環境で実験したい • スナップショット機能で稼働しているJenkinsと全く同じ環境を複製可能 • 数時間で検証環境の立ち上げと検証作業が完了 • ジョブ完了時にSlack通知の自動メンション • ジョブを実行したメンバーへのメンション機能をJenkinsfileとgroovyで実現 • ビルドジョブの分析基盤をBigQueryに構築 • 全体ビルド時間やステップ毎の時間などのデータを保存して可視化 69 1 2 4 3

Slide 70

Slide 70 text

目次 70 SWETとは？ Jenkins 構築と運用のこれまで SWETの取り組み 1 4 今後の展望 2 3

Slide 71

Slide 71 text

再掲：ビルドパイプライン - iOS / Android クライアントビルド 71 画像引用: https://cloud.google.com/icons https://www.jenkins.io/artwork/ https://github.com/logos 1 2 3 4

Slide 72

Slide 72 text

現在のビルドパイプラインの問題点 • Unityが必要なジョブを担えるのがmacOSしかない • 実機の調達に時間がかかる • リモートワークを進める最近の事情的にこれ以上物理マシンを増やしたくない • 故障時のリスクが高い • スケーラビリティの確保が問題 72 1 2 3 4

Slide 73

Slide 73 text

クラウドサービスの活用 • クラウドのCI/CDサービス • 特徴 • 実機、インスタンスの管理が不要 • プロビジョニングが不要 • ジョブの設定がJenkinsよりも簡単 • VMやDocker上で動作するため一般的にスペックは実機より劣る • DeNAで利用しているサービス • CircleCI • Bitrise • 実機を借りるサービス • MacStadium 73 1 2 3 4

Slide 74

Slide 74 text

• https://circleci.com/ • SaaS型のCI/CDサービス • DeNAではCircleCI Server（オンプレ）を使用 • DeNAではmacOSマシンの契約をしていない • サーバーサイド開発のCIでは既に活用 • 以下のジョブはCircleCIでの実行に変えていきたい • Unityに依存していない • macOSに依存していない • 手動で複雑なパラメータの選択が必要ではない 74 画像引用: https://brandfolder.com/circleci 1 2 3 4

Slide 75

Slide 75 text

• https://www.bitrise.io/ • モバイルアプリ開発に特化したCI/CDサービス • DeNAではゲーム以外のアプリ開発で既に積極的に活用 • Unityサポートがロードマップに含まれている • 非常に期待しています 75 画像引用: https://www.bitrise.io/presskit 1 2 3 4

Slide 76

Slide 76 text

• https://www.macstadium.com/ • Mac miniなどの実機をクラウド上で借りられるサービス • 電源のON/OFFをコンソール上から可能 • 実機を置き換える、あるいは繁忙期に臨時で追加する運用などを想定 • DeNA内で既に活用実績あり • Unityを使用するビルドマシンとして使用できるか現在検証中 76 画像引用: https://www.macstadium.com/company/media 1 2 3 4

Slide 77

Slide 77 text

将来のパイプラインの構成イメージ 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

Slide 78

Slide 78 text

将来のパイプラインの構成イメージ 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

Slide 79

Slide 79 text

将来のパイプラインの構成イメージ 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

Slide 80

Slide 80 text

80 まとめ

Slide 81

Slide 81 text

まとめ • Jenkinsの構築・運用において起こりがちな問題の紹介 • これまでの取り組み • パイプラインタスクの一部をmacOS以外のマシンに逃がす • Jenkinsのmaster – agent構成 • セットアップ自動化 • Terraform、Ansible • 監視とアラート • 成果物をGCSに保存 • 今後の展望 • クラウドサービスをさらに活用してスケーラブルな構成を目指す 81

Slide 82

Slide 82 text

82 DeNA Tech の Twitter アカウントでは、 DeNA のエンジニアリングに関する登壇資料やブログを紹介しています！ぜひ Twitter をフォローしてみてください！

Slide 83

Slide 83 text

83 4 3 2 1 SWETの取り組みを定期的に投稿 https://swet.dena.com もしくは SWET Blog で検索

Slide 84

Slide 84 text

84 End.

Slide 85

Slide 85 text

関連資料 • Jenkins 環境構築・運用に関するSWETとしての取り組み GDM vol.40 エンジニア向け勉強会「Jenkinsの構築・運用パターン」 • https://speakerdeck.com/hisa9chi/jenkinshuan-jing-yun-yong-niguan- suruswettositefalsequ-rizu-mi 85

Slide 86

Slide 86 text

macOS以外のUnityの検討について • Linux版とWindows版 • DeNAのエンジニアはmacOSを使う人が多いため、ビルドマシンはMac miniが主流 • Linux版はとても期待している • クラウドのインスタンスでビルドが可能ならば圧倒的にスケールしやすいため • 現在開発中のタイトルではタイミングの問題で検証できなかった • Apple Siliconの件もあるので来年以降にどうなるかは完全に未定 86