【DeNATechCon2024】CI/CD の課題解消！ GitHub Actions への移行で可能になったこと

CI/CD の課題解消！ GitHub Actions への移行で可能になったこと 古屋 姫美愛 © DeNA Co., Ltd.

⾃⼰紹介 古屋 姫美愛 エンターテインメント開発事業本部オープンプラット フォーム事業部ゲームプラットフォーム部サーバーグ ループ 2016年8⽉から DeNA の⼀員としてサーバーサイドエンジ ニアとして Join。 2020年、2022年に産休‧育休を取得、2023年より復帰し ました。現在はMobageプラットフォームの開発運⽤に加 えて、全社⽤セルフホストランナーの運⽤改善も。 kimikimi714 kimikimi714 © DeNA Co., Ltd. 2

⽬次 1. GitHub Actions とは 2. 直⾯していた課題 3. 移⾏によって解消した課題 ○ 困まったこと ○ よかったこと 4. 今後やっていきたいこと © DeNA Co., Ltd. 3

GitHub Actions とは © DeNA Co., Ltd. 4

GitHub Actions とは ● GitHub ⾃体が提供している継続的インテグレーション(CI)と継続的デリバリー (CD) の プラットフォーム。 ○ ● 現在弊社で利⽤中の GitHub Enterprise Server ではバージョン3.0からGA。 GitHub で発⽣する各種イベント(push, pull_request, issues など)で発⽕するワークフ ローと呼ばれる⼀連の処理をおこなわせることが可能。 ○ ● 処理を実際におこなうのはランナーと呼ばれるデーモン。 GitHub Enterprise Server では GitHub Enterprise Cloud と異なり、セルフホストラン ナーを⽤意する必要がある。 © DeNA Co., Ltd. 5

• https://docs.github.com/en/enterprise-server@3.0/admin/release-notes#github-actions

GitHub Actions とは © DeNA Co., Ltd. 6

すでに⾃分のチームでは Jenkins® と CircleCI® でCI/CDしていた。 ※1 Jenkins®は、LF Charities Incの登録商標です。 ※2 CircleCI®は、Circle Internet Services, Incの商標または登録商標です。 © DeNA Co., Ltd. 7

直⾯していた課題 © DeNA Co., Ltd. 8

直⾯していた課題 1. CircleCIのジョブ管理者が実質⾃分のみ 2. Jenkins のジョブが GUI ベースでコード管理されてない 3. Jenkins で利⽤しているプラグインのアップデートが困難 4. 新しいプロジェクトのCI/CDは Jenkins / CircleCI 以外にしたい © DeNA Co., Ltd. 9

CircleCIのジョブ管理者が実質⾃ 分のみ ● メンバーの異動で残ったのが⾃分 だった。増やすにはユーザーの追 加購⼊が必要。 ● 外部協⼒者の⽅が落としたテスト を代わりに⾒に⾏って伝える運⽤ があった。 ● 引⽤: オンプレミスの CI/CD - CircleCI さすがにユーザーを追加したもの の、メンバーの異動で同じ問題が また起こる。 © DeNA Co., Ltd. 10

• https://circleci.com/ja/pricing/server/

Jenkins のジョブが GUI ベースで コード管理されてない ● 歴史的事情から Jenkinsfile など で管理できてない。 ● ジョブやパイプラインの変更差分 が追えない。レビューできない。 ● プロジェクトごとに処理がほとん ど共通のパイプラインであっても コピーで増やしてる状態。 © DeNA Co., Ltd. Jenkinsで実⾏されているパイプラインの例 11

Jenkins で利⽤しているプラグイ ンのアップデートが困難 ● 他のチームも利⽤しており、⾃ チームの判断だけでアップデート ができない。 ● Jenkins ⾃体の知識が⾜りない… ⼀部のJenkinsプラグインの状態 © DeNA Co., Ltd. 12

新しいプロジェクトのCI/CDは Jenkins / CircleCI 以外にしたい ● すでに運⽤課題があるところに新規追加はおこないたくない。 ● CI/CDプラットフォームの⼀本化を図りたい。 © DeNA Co., Ltd. 13

求める要件 1. GitHub のアカウントさえあれば使える。 2. 利⽤にあたって追加費⽤がかからない or 安い。 3. ワークフロー⾃体がコードで管理可能。 4. 学習コストが低めでメンテしやすい。 これらの条件を GitHub Actions は満たしている！ © DeNA Co., Ltd. 14

GitHub のアカウントさえあれば 使える ● 基本的にリポジトリ、組織ごとに 利⽤するかどうかを決められる。 引⽤: Managing GitHub Actions settings for a repository - GitHub Enterprise Server 3.10 Docs © DeNA Co., Ltd. 15

• https://docs.github.com/en/enterprise-server@3.10/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#about-github-actions-permissions-for-your-repository

利⽤にあたって追加費⽤がかから ない or 安い ● セルフホストランナーを運⽤する料 ⾦は⾃分たちで持つことになるが、 それ以外に追加費⽤はかからない。 ● セルフホストランナーを⽴てるイン スタンスの運⽤次第で料⾦が変わっ てくる(GitHub Actions ⾃体の問題 ではない)。 ● セルフホストランナーが⽴てられる 要件を満たしたEC2インスタンスを ⾃チームですでに持っていた。 © DeNA Co., Ltd. 引⽤: About billing for GitHub Actions 16

• https://docs.github.com/en/enterprise-server@3.10/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#requirements-for-self-hosted-runner-machines
• https://docs.github.com/en/billing/managing-billing-for-github-actions/about-billing-for-github-actions#about-billing-for-github-actions

ワークフロー⾃体がコードで管理可能 / 学習コストが低めでメンテしやすい ● ワークフローは YAML 形式。 name: hello on: push ● 詳しい書き⽅などは Understanding GitHub Actions を参照。 pushイベントで発⽕する defaults: run: shell: bash jobs: hello: runs-on: [self-hosted] 実⾏したい処理を書く steps: - name: "echo Hello" run: echo "::notice ::Hello, DeNA TechCon!" © DeNA Co., Ltd. 17

• https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions#understanding-the-workflow-file

GitHub Actions 移⾏によって解消した課題 © DeNA Co., Ltd. 18

(再掲)直⾯していた課題 1. Circle CIのジョブ管理者が実質⾃分のみ 2. Jenkins のジョブが GUI ベースでコード管理されてない 3. Jenkins で利⽤しているプラグインのアップデートが困難 4. 新しいプロジェクトのCI/CDは Jenkins / Circle CI 以外にしたい © DeNA Co., Ltd. 19

課題の解消 1. Circle CIのジョブ管理者が実質⾃分のみ ○ 2. Jenkins のジョブが GUI ベースでコード管理されてない ○ 3. © DeNA Co., Ltd. → YAMLで書ける！ Jenkins で利⽤しているプラグインのアップデートが困難 ○ 4. → チーム全員で管理できる！ → アップデートをしなくてよくなった！ 新しいプロジェクトのCI/CDは Jenkins / Circle CI 以外にしたい ○ → GitHub Actions が新たな選択肢になった！ ○ (ものによっては AWS CodePipelineを使っているものもある。) 20

移⾏にあたって困ったこと © DeNA Co., Ltd. 21

Jenkins のパイプラインをGUIか ら読み解くことが難しかった ● Job A→Job B→Job C→…みたい に次々にジョブが⾛るものなどが 難しい。 ● Job A→Job B程度のものから移 ⾏していく。 ● そのまま移⾏ではなく、あるべき 姿で移⾏していく。 © DeNA Co., Ltd. Jenkinsで実⾏されているパイプラインの例(再掲載) 22

セルフホストランナーが⽴ってい るOSが古く Node.js v18以上が動 かなかった ● Node.js v18以上で動かすアク ションが軒並み動かない。 ● 全社⽤セルフホストランナーであ れば使える。ジョブごとにラン ナーを切り替えて対応。 ● ⾃チームのOSのバージョンアッ Node.js v18+ で必要なライブラリが⾒つからなかった プは別途進⾏中。 © DeNA Co., Ltd. 23

本番環境で実⾏できるワークフ ローを制限する⼿段が導⼊した当 初はまだなかった ● 本番環境で実⾏可能なワークフ ローはプルリクもちゃんと通した ものだけにしたかった。 ● 現在は指定したワークフローだけ が本番環境にあるセルフホストラ ンナーで動かせる。 ● github.com では enterprise アカ ウントなどで利⽤可能(リンク)。 © DeNA Co., Ltd. ワークフローを指定する例 24

• https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/managing-access-to-self-hosted-runners-using-groups

導⼊当初はワークフローの共通化 ができなかった ● 現在は Reusable workflow とい うもので共通ワークフローを定義 できる。 jobs: ReuseableMatrixJobForDeployment: strategy: matrix: 共通ワークフローを呼び出す target: [dev, stage, prod] uses: octocat/octo-repo/.github/workflows/deployment.yml@main with: target: ${{ matrix.target }} 引用: Reusing workflows - GitHub Enterprise Server 3.10 Docs © DeNA Co., Ltd. 25

• https://docs.github.com/en/enterprise-server@3.10/actions/using-workflows/reusing-workflows#using-a-matrix-strategy-with-a-reusable-workflow

移⾏にあたってよかったこと © DeNA Co., Ltd. 26

CircleCI から GitHub Actions の ワークフロー読み替えは簡単 ● ⽤語や概念に違いはあるものの、 読み替えるのは難しくなかった。 ● 公式が移⾏ガイドを⽤意している (移⾏当時知らなかった)。 ● 移⾏ガイド⾒なくても移⾏でき た。 © DeNA Co., Ltd. 引用: Migrating from CircleCI to GitHub Actions 27

• https://docs.github.com/ja/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-circleci-to-github-actions
• https://docs.github.com/en/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-circleci-to-github-actions

シェルスクリプトの呼び出しがで
きる
●

Jenkins で動かしていたシェルス

DEPLOY_COMMAND="source ${HOME}/.bashrc &&
source ${HOME}/perl5/perlbrew/etc/bashrc &&
perlbrew use infra &&

クリプトをほぼそのまま GitHub
Actions で流⽤できた。
●

メンテできなくなってた Slack
bot の移植もできた。

cd ${HOME}/example_js &&
-

git checkout ${branch} &&

-

git reset --hard origin/${branch} &&

-

git pull origin ${branch} &&

+

git reset --hard &&

+

git fetch origin -P &&

+

git checkout ${RELEASE_COMMIT} &&
releaseCommand -c ${HOME}/etc/release/example_js.perl

${COMPONENT} deploy:all -s service=dev_sandbox &&
releaseCommand -c ${HOME}/etc/release/example_js.perl
${COMPONENT} deploy:all -s service=dev_service
"

JenkinsからGitHub Actions へ移行する時の修正差分例
© DeNA Co., Ltd.

ランナーのインストールは簡単 ● インストール⽅法はランナー追加 # フォルダを作る $ mkdir actions-runner && cd actions-runner 時に右のコードのように表⽰され る。 ● # ダウンロードする $ curl -o actions-runner-osx-x64-2.304.0.tar.gz -L -H 'Authorization: Bearer hoge' 表⽰されたコマンドを素直に叩く https://github.com/_services/pipelines/_apis/distributedtask/package だけでいい。 # 解凍する download/agent/osx-x64/2.304.0 $ tar xzf ./actions-runner-osx-x64-2.304.0.tar.gz ● インストールでつまずくことはな # インストールする $ ./config.sh --url https://github.com/kimikimi714/example --token かった。 XXXX # ランナーを起動する $ ./run.sh © DeNA Co., Ltd. 29

• https://github.com/_services/pipelines/_apis/distributedtask/package
• https://github.com/kimikimi714/example

今後やっていきたいこと © DeNA Co., Ltd. 30

今後やっていきたいこと 1. 2. 3. 脱 Jenkins ○ Jenkins のパイプラインの数が多い。 ○ Reusable workflow で共通化しつつ移⾏していく予定。 本番デプロイの⾃動化 ○ 現在はあたたかみのある⼿動運⽤。 ○ チームメンバーと協⼒して進⾏中。 GitHub マシンユーザーの排除 ○ マシンユーザーのパスワード管理が⼀部メンバーに依存している。 ○ リポジトリのチェックアウトなど GitHub Apps で可能。 ○ すでに⼀部リポジトリではマシンユーザーを使わずにチェックアウトしてテストを回せてい る。 © DeNA Co., Ltd. 31

ご清聴ありがとうございました © DeNA Co., Ltd. 32

Appendix © DeNA Co., Ltd. 33

FAQ ● 全社⽤セルフホストランナーがあるのに⾃チーム⽤にセルフホストランナーを⽴てたの はなぜ? ○ 全社⽤セルフホストランナーと⾃チームの開発環境のネットワークが隔離されて いて、CDが全社⽤セルフホストランナーでは動かせない。 ○ また GitHub Actions が全社に導⼊された当初はまだ全社⽤セルフホストランナー がなく、⾃前で⽴てるしかなかった。 ○ 今は⽤途に応じて全社⽤セルフホストランナーと⾃チームのセルフホストラン ナーを使い分けている。 © DeNA Co., Ltd. 34

FAQ ● Jenkins プラグインのアップデートが困難だというが、actions のアップデートも必 要。困難さに変わりはないのでは? ○ Dependabot や Renovate のようにactionsの更新をおこなうツールが今は充実し ている。 ○ テストが通れば⾃動マージも設定次第で組むことが可能なので Jenkins プラグイ ンのアップデートよりも運⽤しやすい。 © DeNA Co., Ltd. 35

• https://docs.github.com/ja/enterprise-server@3.10/code-security/dependabot/working-with-dependabot
• https://docs.renovatebot.com/

FAQ ● CircleCIからの移⾏って本当に簡単だったの?困ったことはなかった? ○ .circlrci/config.yml から .github/workflow/ci.yml に書き換えること⾃体は本当に 簡単だった。 ○ 難しかったのは CircleCI の CI で利⽤していた独⾃ Docker image からの脱却。 ○ あるプロジェクトでは Dockerfile に compass のインストールが記述されてるもの があった。 ○ © DeNA Co., Ltd. 先に脱 compass してから脱 CircleCI の順に進めた。 36

• https://github.com/Compass/compass

FAQ ● 「ジョブごとにランナーを切り替えて対応」と⾔ってたが、どんなことをしてるのか? ○ Node.js v18+ が必要なフロントエンドのビルドは全社⽤セルフホストランナー で、デプロイは⾃チーム運⽤のランナーでおこなっている。 ○ ビルドしたJSは全社⽤セルフホストランナー上に⽣成されるので actions/upload-artifact でアーティファクトとして⼀時保存し、デプロイ時に actions/download-artifact でデプロイ⽤ディレクトリにダウンロードしてくる構 成になっている。 © DeNA Co., Ltd. 37

• https://github.com/actions/upload-artifact
• https://github.com/actions/download-artifact