ゲーム開発のJenkins整備から横断SREチームが誕生するまで【DeNA TechCon 2023】

youtube：https://youtu.be/nkJOEP2Hczs

概要：
近年のソフトウェア開発ではCI/CDサービスを活用することでビルドやテストを自動化して効率的に開発を行うことが一般的となっています。これはゲーム開発でも同様であり、このようなCI/CDを実現するために様々なツールを動かす基盤は重要な役割を担っています。

DeNAのゲーム開発では以前からJenkinsを利用しており、大規模なデータを扱い大人数が関わるゲーム開発現場に耐えうるJenkinsの運用を年々アップデートしてきました。

また、開発を効率化するための様々なタスクの自動化や基盤整備のニーズが年々高まり、個々の開発プロジェクト内だけでは人手が不足しがちなことが課題となりつつありました。

この問題を解決するためにプロジェクト横断したSREチームを立ち上げました。自動化などを主軸に、ゲーム開発におけるCI/CD運用や開発効率化を行っています。

今回はチームの最新ノウハウや、今後の展望をご紹介します。
・JenkinsビルドマシンとしてMacStadiumの利用
・BigQueryによるビルド情報の分析基盤の構築
・Jenkinsの代わりにGithub Actionsを活用する取り組み

登壇内でのリンク集：
p13, https://speakerdeck.com/dena_tech/mohairukemukai-fa-niokerujenkinskurautoshi-dai-falsejenkinsgou-zhu-toguan-li-tekunituku
p20, https://techcon2022.dena.dev/spring/session/lightning-talks/
p21-1, https://swet.dena.com/entry/2021/07/12/120000
p21-2, https://speakerdeck.com/dena_tech/kaorumaeda_cedec2022
p21-3, https://swet.dena.com/entry/2022/09/21/100000
p24-1, https://github.com/Kesin11/CIAnalyzer
p24-2, https://event.cloudnativedays.jp/cicd2021/talks/1152
p63, https://github.com/DeNA/setup-job-workspace-action

◆ チャンネル登録はこちら↓
https://youtube.com/c/denatech?sub_confirmation=1

◆ Twitter
https://twitter.com/DeNAxTech

◆ DeNA Engineering
https://engineering.dena.com/

◆ DeNA Engineer Blog
https://engineering.dena.com/blog/

◆ DeNA TechCon 2023 公式サイト
https://techcon2023.dena.dev/

Transcript

1. ゲーム開発のJenkins整備から 横断SREチームが誕生するまで 品質本部品質管理部SWET第二グループ 加瀬健太（Kenta Kase） ゲーム事業本部開発事業部開発二部テクノロジー推進第一グループ 白柳 隆澄（Takazumi Shirayanagi）
2. Table of Contents ゲーム開発におけるCI/CDのための安定したJenkinsクラスタ構築と発展 • Jenkins クラスタの構成と構成管理 • macOS Agent をオフィスの Mac mini から MacStadium へ • BigQuery を活用したビルド情報の可視化と分析 2 ゲーム事業部にプロジェクト横断SREチームが誕生 • ゲーム事業部における CI/CD の課題 • 横断 SRE チーム誕生までの経緯と活動 • Jenkins から GitHub Ac?ons へ
3. 自己紹介 • 加瀬健太 ◦ ＠Kesin11（Twitter) / ＠Kesin11（GitHub) • 所属 ◦ DeNA SWET 第二グループ（Software Engineer in Test) • 業務 ◦ CI/CD 関連の技術的なサポート ◦ 社内共通基盤の CircleCI Server、Bitriseの運用 3 @Kesin11
4. SWETグループ MISSION ソフトウェアを起点とした • DeNAサービス全般の品質向上 • DeNAエンジニアの開発生産性向上 により、価値あるものを素早く提供できるようにする 今回は SWET の CI/CD チームの取り組みを紹介 4
5. ゲーム開発における Jenkins と SWET • ゲーム開発におけるJenkins ◦ 効率的に品質の高いゲームを開発するための自動化の基盤 ▪ アプリの定期的なビルド ▪ マスタデータやアセットのバリデーション ▪ サーバーのデプロイ自動化 ◦ 開発規模が大きくなるほど Jenkins は業務に必要不可欠 ◦ だが・・・ 5
6. ゲーム開発における Jenkins と SWET • プロジェクトごとに独自に Jenkins を構築 ◦ Jenkins の運用は片手間になりがち ◦ Jenkins を専門に運用するチームがいない ▪ ノウハウが蓄積されない • 新規プロジェクトにおいても Jenkins が改善されない Jenkins のノウハウを持っていたSWETが大規模なゲーム開発に耐 えうる Jenkins の構築を目指すことに 6
7. 可用性と拡張性に優れた Jenkinsクラスタの構成 7
8. 8 Jenkins クラスタの構成 • 主に3種類のマシンで構成 ◦ Jenkins Controller ◦ Linux Agent ◦ macOS Agent Google Compute Engine is a trademark of Google LLC.
9. 9 Jenkins クラスタの構成 • Jenkins Controller（GCE） ◦ スケールアップが容易 ◦ ディスクのスナップショットを バックアップ用途に活用
10. 10 Jenkins クラスタの構成 • Linux Agent（GCE） ◦ 役割 ▪ macOSが必須ではないジョブ ▪ docker が必要なジョブ ◦ スケールアップ、 スケールアウトが容易 ◦ 夜間と休日は稼働台数を減らす ことでコスト削減
11. 11 Jenkins クラスタの構成 • macOS Agent ◦ オフィスに配置した Mac mini ◦ MacStadium の Mac mini （後述） ◦ 役割 ▪ Xcode など macOS が必須のジ ョブ ▪ Unity を利用するジョブ ◦ Unity を macOS で使用する プロジェクトが多い
12. Jenkins Controller や Agent の構成管理 • Google CloudのインフラはTerraform管理 ◦ GCEの台数、スペック ◦ ネットワーク構成 • Jenkins自体やAgentに必要なツールのインストールや設 定はAnsibleで管理 ▪ マシン毎にYAMLを用意する ▪ インストールするツールのバージョンを書く ▪ 現在のマシン構成をコードから把握できる 12
13. 詳しくは CEDEC 2020 の発表 • モバイルゲーム開発におけるJenkins 〜クラウド時代のJenkins構 築と管理テクニック〜 ▪ Ansibleによる構成管理 ▪ ビルドパイプラインの設計 ▪ ビルドマシンの監視とアラート ▪ 成果物をGCSに保存してディスク容量消費を抑制 ▪ Fastlane matchによるiOS開発用の証明書と プロビジョニングプロファイル管理 13
14. macOS Agent をオフィスの Mac mini から MacStadium へ 14
15. オフィスの Mac mini の不便な点 • 注文してから納品まで時間がかかる ◦ 特に近年は感染症と半導体不足の影響で数ヶ月待ちの状況で あった • マシン再起動を伴う作業は出社する必要がある ◦ OS アップデートやハングアップからの復帰など ◦ DeNA は近年ではリモートワーク主体 • 台数が増えると物理的な障壁が現れる ◦ 設置スペース ◦ 電源容量 ◦ ネットワーク容量 • ビルの法定停電対応 ◦ 停電中はビルドが行えなくなってしまう 15
16. macOS もクラウド化したい...！ 16
17. MacStadium • データセンターの Mac mini の実機を1台ずつ月ごとに借りられ るサービスを提供している • ssh もしくは VNC でのリモート操作 • 電源ON/OFFも web コンソールから制御可能 • 2020年時点で既に活用実績はあったが最近はさらに積極的に活 用 ◦ DeNA 全体としてインフラをクラウドに寄せる方針 ◦ 2020年からリモートワーク主体に変化 17
18. MacStadium のメリット • 台数をスケールさせやすい ◦ 発注してからおおよそ1日でビルドマシンとして稼働可能 ▪ 注文後に MacStadium 側の初期セットアップ完了まで約半日 ▪ ツールのセットアップは Ansible で自動化済みなので数時間 ◦ 急激なビルド負荷の増加に対応可能 ▪ リリース時期付近は1日にビルドを行う回数が増加 ▪ 繁忙期だけ台数を増やし落ち着いたら減らす運用が可能に 18
19. MacStadium のデメリット • SSDが最大でも1TB ◦ ゲーム開発におけるビルドは非常にディスク容量を必要とす る ▪ アセットデータなどが膨大 • アセットのリポジトリだけで20GBを超える プロジェクトもある ▪ Jenkinsでビルド時のブランチなどのパラメータに応じてワ ークスペースを分離したいニーズ • ビルドキャッシュの効率化のため • リリース候補となるバイナリ作成ジョブは まっさらな環境からビルドしておきたい 19
20. MacStadium の容量問題への対策 • 不要データの定期的な削除の自動化 ◦ Xcode の Archive、DerivedData ディレクトリ ◦ 利用されていない、もしくは古い Jenkins ジョブの ワークスペース ◦ 過去のブランチでビルドに使用していたワークスペース • 削除を自動化したことで台数が増えても運用工数を抑えること ができた • 詳しくはTechCon 2022のLT ◦ 「ゲーム開発のCI/CDを支えるJenkins運用 ~MacStadium 活用 とディスク容量との闘い~」 20
21. • ビルドに必要なデータだけを clone/fetch（shallow clone, partial clone） • ビルドマシンのローカルにミラーリポジトリを作成して Git の共通オブジェク トの重複を削除（reference clone） • Git LFS ローカルストレージの共有 • 同一のアセットデータは APFS の Copy on Write 機能で重複分を削除 Git や macOS のファイルシステムレベルでの容量削減 21 詳しくはCEDEC 2022の発表やブログ ◦ ブログ 大きなGitリポジトリをクローンするときの工夫を図解します ◦ CEDEC発表スライド 「大きなGitリポジトリをJenkinsで扱うコツ 〜Copy on Writeを使っ たディスク節約術〜」 ◦ ブログ macOSのCopy-on-Write機能を使ってディスクを節約した話
22. 22 BigQuery を活用したビルド情報の可視化と分析
23. • いつの間にかビルド時間が長くなっている • ランダムにたまに失敗するビルド • ビルドキューが詰まりがち ビルド・テストが失敗した際の根本原因の修正が放置されがちな 原因となる • 問題の調査が困難 ◦ Jenkins に過去のビルド情報を分析する機能が乏しい ▪ 過去のビルドログを1つ1つ調べるしかない ◦ ビルドログが長大かつ数が膨大 23 Jenkins を長く運用していると見えてくる問題
24. • CIAnalyzer ◦ https://github.com/Kesin11/CIAnalyzer • Jenkins, GitHub Actions, CircleCI, Bitriseの API からビルド情報を 整形して BigQuery に送信 • BigQuery のデータの可視化は Looker Studio （旧データポータル）を利用 • 詳しくは CI/CD Conference 2021 の発表 ◦ 「CI/CDのボトルネックを把握できていますか？BigQueryで ビルド情報ダッシュボードを構築した話」 24 ビルドに関する情報の可視化と分析
25. 1年間のビルド時間の推移 BigQuery によって膨大なデータ量でも数秒で表示が可能 25 長期トレンドでビルド時間が 右肩下がりなので健全
26. ジョブとステップ毎にかかる時間の分析 どのステップに時間がかかっているのかが分かりやすい 26 青色のステップがビルド時間の 約80%を占めている
27. キュー待ち時間の分析 12月->1月にかけて対策を講じたことで劇的に改善した様子 27 12月 キュー待ち時間が長い 1月 キュー待ち時間がほぼゼロ
28. 過去のビルド履歴の表（開始日時、Succees/Fail） ビルド番号に Jenkins のジョブ詳細画面へのリンクを埋め込んでいる 28
29. • ジョブ内で時間がかかっているコマンドが統計的に分かる ◦ ビルド時間の改善幅が大きい部分から着手しやすい • キュー待ち時間の推移が定量的に分かる ◦ 肌感ではなく数字に基づいたビルドマシン台数の調整 • いつのビルドから失敗するようになったのか正確に分かる ◦ リトライすれば直るケースは調査が後日になりやすい ◦ 問題の正確な発生日は重要な情報 ▪ 日付から修正コミットやインフラの変更などを追跡できる 29 可視化するとビルドの分析調査が効率的に
30. 30 SWET グループによる Jenkins 運用のまとめ
31. • Jenkins Controller と Agent をクラウド化 ◦ GCE ◦ MacStadium • Terraform と Ansible で構成管理 • macOS Agent の MacStadium 活用 ◦ 台数をスケールさせやすい ◦ ディスク容量問題への対策 • BigQuery を活用したビルドに関する情報の可視化と分析 ◦ ビルドの調査分析が効率的に 31 SWET グループによる Jenkins 運用のまとめ
32. 32 今後の展望
33. • SRE チームと協力して Jenkins の運用をサポート ◦ SWETのCI/CDチームはゲーム開発や Unity のノウハウが足り ていない ◦ お互いの得意分野で協力 • DeNA 全体の CI/CD のサポートにも力を入れたい ◦ GitHub Ac\onsの発展に注目 ▪ ゲーム開発以外のプロジェクトでは知名度が急上昇 ▪ ゲーム開発でも Jenkins の代替として利用できるかも ◦ SRE チームと協力して GitHub Ac\ons の利用を開始 33 今後の展望
34. ゲーム開発のJenkins整備から 横断SREチームが誕生するまで (後半) ゲーム事業部にプロジェクト横断SREチームが誕生
35. 自己紹介 • 白柳隆澄（しらやなぎ たかずみ） ◦ Facebook (takazumi.shirayanagi) ◦ Twitter/GitHub やってるけど秘密 • 所属 ◦ ゲーム事業本部開発事業部 ▪ 開発二部テクノロジー推進第一グループ • 業務 ◦ SRE ◦ ゲームエンジニアだったり、ビルドエンジニアだったり、 インフラエンジニアだったり ◦ 直近は CI/CD 関連がメイン 35
36. （後半）ゲーム事業部にプロジェクト横断SREチームが誕生 ゲーム事業部における CI/CD の課題 • 横断的なベストプラクティス議論 • プロジェクト格差とシフトレフト・共通化の必要性 SREチームの誕生と活動 • 誕生経緯 • 「ゲーム開発者のための SRE」の実践 • 主な活動と今後 • Jenkins から GitHub Actions へ 36
37. 横断的なベストプラクティス議論 • Jenkins 運用してると問題めっちゃ発生する • 各プロジェクトごとに独自運用 ◦ 一部 SWET 運用 • 車輪の再発明 ◦ 前のプロジェクトでも同じことやったな？ ◦ プロジェクトごとに Jenkinsfile の書き直し • 横断的に課題と最善策を議論する会が発足（ベスプラ会） ◦ CI/CD 編としてゲーム事業部・SWET で議論の場ができた ◦ ここが起点となり双方が互いに歩みより 37
38. プロジェクト単体での課題 • リリース前の開発フェーズとリリース後の運営フェーズで変化 • 開発フェーズではメインライン1本 ◦ 並列実行などは少なめシンプルな構成で事足りる ◦ イテレーションが優先される傾向 ◦ リリースが近づくにつれて・・ 38 Jenkins Artwork - Jenkins / CC BY-SA 3.0 Jenkins Artwork - Fire / CC BY-SA 3.0
39. プロジェクト単体での課題 • 運営フェーズでは複数ラインが同時並行で走る ◦ パイプライン完了までの時間が長くなる ◦ ビルドマシン不足（ディスク容量・速度・並列数） ◦ 複雑度が増す ◦ 安定性が大事になってくる ゲームの成長とともに CI/CD も大きく成長していく 39
40. 複数プロジェクトでの課題 • SWET 管理 Jenkins のノウハウが一部のプロジェクトのみに ◦ SWET 管理の Jenkins は開発者目線ではすごく楽でとても助かる ◦ ただし SWET が対応できるプロジェクト数は限られる ◦ ゲーム事業部側に Jenkins 運用のエキスパートが少ない ▪ SWET からの移譲が滞留しがち ◦ 恩恵を受けられないプロジェクトがガラパゴス、カオス化 40 Jenkins Artwork - JCasC by Nicolas De loof & Kseniia Nenasheva / CC BY-SA 3.0 Jenkins Artwork - Duchess France by TatoBerres Duchess France / CC BY-SA 3.0 Jenkins Artwork - Googly by Lakhan Kumawat / CC BY-SA 3.0 Jenkins Artwork - Ninja by Masanobu Imai / CC BY-SA 3.0
41. 複数プロジェクトでの課題 • プロジェクト初期の構成からの負債 ◦ プロジェクト初期にコピーされた Jenkins が開発終盤まで現役 ◦ コピー元の負債ごと持ってきてしまう ▪ 動いてるものだけコピー ▪ 改善案などは受け継がれず 41
42. 議論から実践へ プラクティスを議論していざ実践へ あとは実践する人さえいれば 42
43. ゲーム事業部横断SREチームの誕生 43
44. SRE チーム＝「ゲーム開発者のための SRE」を実践するチーム 単に SRE だと何をする組織か分かりづらい状況となっているため 「ゲーム開発者のための SRE」と命名 • SRE（Site Reliability Engineering/Engineer） ◦ 一般的には Google が実践しているやり方を指すことが多い ◦ Site の数だけ SRE がある ≒「サービスの運用/運営にあたって、価値目標に向け、 自動化（自働化）を主軸にエンジニアリングを用いて、 継続的に改善していく」人/こと、と理解 44
45. 「ゲーム開発者のための SRE」とは • ゲームの SRE ◦ ユーザー（ゲームプレイヤー）のために活動するイメージ • ゲーム開発者のための SRE ◦ ゲーム開発者のためにも活動 ゲーム開発中に必要なツールやサービス、ゲーム中のデバッグ機能、 環境構築、ワークフロー、etc... それらを「ゲーム開発者」向けのサービスと捉えて 運用と改善をするのが「ゲーム開発者のための SRE」です 45
46. SRE チーム MISSION ゲーム開発におけるプロダクト・プロジェクト上の サービスの信頼性を担保する • ゲーム開発における開発フロー・対ユーザーサービスを運用し、 信頼性の高いサービスを提供する • 50%ルールを守り、エンジニアリングによる継続的な改善を行う 46
47. なぜ CI/CD を担当しているのか • ゲーム事業部として解決した課題は山程ある ◦ ゲーム開発における CI/CD の部分をカバー できてなかった • 「ゲーム開発者のための SRE」として ◦ CI/CD はゲーム開発者向けのもっとも 利用者が多く、重要なサービスであるから ◦ 小さな改善でも大きな効果が見込める 47
48. to SRE 技術的負債 時間を借りてできた課題 ゲーム開発では締切優先で短期的な解決方法を取ることがしばしばある 「課題」として認識しているが、将来的にやりたい、手が空いたらやりたい、積んで いるだけ、など課題は先送りされてしまいがちである ゲームの運営、改善チーム • 運営チーム 機能開発、リリース業務を行いつつ、障害対応と再発防止、 業務フローの改善など、SRE と言っても過言ではない • 改善チーム 技術的負債の返済を目的とした人・チームがしばしば誕生する 私も改善チームとして活動していた スタッフロールの肩書はどうしたらいい？ → SRE 48
49. Embedded/Enabling SRE • Embedded SRE ◦ SRE がプロジェクトに参加しプロジェクトメンバーとして活動 これまで運営チームや改善チームがやってきたこと ただし、ゲームの運営・開発がメイン 改善は継続的に回っていなかった • Enableing SRE ◦ プロジェクトに SRE のプラクティスや文化を浸透させる プロジェクトメンバーに SRE になってもらう 49
50. なぜ横断組織なのか 白柳はもともと Embedded SRE として活動してきた ゲーム事業部の各プロジェクトの CI/CD 課題を解決するには プロジェクト初期から関わる必要があり プロジェクトに所属するのではなく横断組織が都合がよかった Embedded から Enabling に注力 SRE でなくても誰もが SRE の思想を実行できる ゲーム事業部にしていきたい 50
51. VISION 開発チームが「楽」してゲーム開発・運営ができる場を作る いわゆる DX (Developer eXperience）開発者体験の向上 SRE や DX というと聴こえがいいかもしれませんが 今までやってきた改善を継続的に行っていく ただそれだけです 「ゲーム開発者のための SRE」が目指すところ 51
52. SRE チームの取り組み 52
53. これまでの活動 • CI/CD ◦ 運用 ▪ ビルドマシンメンテナンス ▪ パイプライン上の失敗のハンドリング ▪ ジョブ作成、改修サポート ◦ SWET 構成の Jenkins へのリプレイス ◦ プロジェクト初期からのサポート ▪ GitHub Actions (self hosted runner) の導入 • SWET と協力 ◦ SWET とプロジェクト間の橋渡し 53
54. これまでの活動 • プロジェクト内での活動 ◦ 作業環境構築サポート ◦ クラッシュレポーター導入 ◦ 不具合調査 ◦ その他お助けマン ▪ Slack 上のヘルプに駆けつけ ▪ リアクション大事 54
55. 今後 • SRE のプラクティスをより実践していく • CI/CD 関連業務をもっと簡単に • CI/CD に限らず SRE の活動の場を増やす ◦ ゲーム事業部に SRE を増やす ◦ 「ゲーム開発者のための SRE」としてゲーム開発もこなす Embedded SRE ◦ 組織運営など開発現場以外にも自動化を推進 55
56. Jenkins から GitHub Actions へ SRE と SWET が協力して進めている脱 Jenkins の取り組みを紹介 • SWET ◦ GitHub Actions の機能や使い方の調査 ◦ runner 構築方法 ◦ インフラ、IaC（Infrastructure as Code） ◦ 汎用ワークフロー/アクション開発 • SRE ◦ プロジェクトへの導入支援 ◦ ゲーム開発向けのワークフロー/アクション開発 ◦ runner 運用 相互にフィードバックをし合う 56
57. なぜ GitHub Actions ？ • 脱 Jenkins ◦ ゲーム業界ではまだまだ現役だが他業界ではだいぶ下火 ◦ 本体・プラグインのバージョンアップが大変 ◦ 設定が煩雑 • GitHub Ac\ons ◦ GitHub Enterprise Server を使っているため相性バツグン ◦ 開発が活発 ◦ エンジニア以外でも使えるかの懸念があったがクリア ▪ 手動トリガー ▪ ジョブサマリー 57
58. 現状の Jenkins と GitHub Actions • Jenkins のみを使用 ◦ リリース済みプロジェクト • Jenkins + GitHub Actions を使用 ◦ リリース済みプロジェクト GitHub Actions が使える以前に開発始まったプロジェクト ◦ Jenkins メインで一部 GitHub Actions なハイブリッド構成 ◦ ゲームのビルドなどの高負荷なジョブは Jenkins GitHub のイベント（プルリクエストなど）に紐づく 軽量なジョブは GitHub Actions • GitHub Actions のみを使用 ◦ 新規プロジェクト 58
59. Jenkins vs GitHub Actions Jenkins GitHub Actions (self hosted runner) Controller タイトル管理 GitHub Enterprise Server Controller 設定 GUI or JCasC - Agent プロジェクト管理 プロジェクト管理 ツール類 プリインストールが基本 ansible で管理 プリインストール（ansible）と setup-XXX 系 action ジョブ設定 GUI で作成 or JobDSL YAML ジョブ処理 GUI or Jenkinsfile に記述 YAML に記述 ワークスペース ジョブごとのディレクトリに ファイルが残る リポジトリごとのディレクトリに ファイルが残る 59
60. Jenkins から GitHub Actions になって • Controller の管理分の負担がなくなった • Agent に関しては self hosted runner なのであまり変わらない ◦ ゲーム開発の場合、差分ビルドしたり、Unity セットアップ、 OS依存など、自分たちで管理のほうがむしろ好都合 ◦ マシン構築は Jenkins 時代に SWET が作ったもののを流用 • ツール類のセットアップ ◦ Jenkins ではプリインストールが基本 GitHub Actions ではジョブからでもセットアップしやすい 60
61. Jenkins から GitHub Actions になって • ジョブ ◦ ジョブの設定/処理内容どちらも GitHub Actions は as Code 共有（action/reusable workflow）の仕組みもあり プロジェクト間共有しやすい ◦ Jenkins でも JCasC や JobDSL を使ってみたが 記述量が少なく済むので GitHub Actions のほうが楽 （個人的な感想） 61
62. Jenkins から GitHub Actions になって • ワークスペース ◦ Jenkins と同様に常にクリーンな状態ではなく 利用者側でコントロール可能 ◦ ただし GitHub Ac\ons では リポジトリごとにワークスペースが共有なので注意が必要 ◦ 意図的に clean しないようにしていたジョブのキャッシュが 他のジョブの checkout で消えていた （e.g. Unity プロジェクトの Library ディレクトリ） 62
63. GitHub Actions でジョブ単位ワークスペースにする DeNA/setup-job-workspace-action ジョブ/ワークフロー単位でワークスペースを切り替える action アクション呼ぶだけでワークスペースが切り替わる • キャッシュが誤って消されることがなくなった Unity の Library などキャッシュ管理がとても簡単になった 63
64. まとめ • GitHub Actions だけでできるのか不安もあったが 思っていたよりも問題にならなかった ◦ Jenkins 時代の知見が活かせた ◦ まだ始めたばかりなのでこれが答えではない ▪ ゲームリリースや運営まで経験してない ▪ これからも継続的に改善 • ゲーム事業部と SWET の間に SRE が入ることで CI/CD のトレンドを取り込みつつ 安定的な運用と改善のサイクルが回るようになった 64
65. おわり 65