Gunosy Tech Blog

Gunosy Tech Blogは株式会社Gunosyのエンジニアが知見を共有する技術ブログです。

CircleCIからGitHub Actionsへ大引越した話

こんにちは、テクノロジー本部 プロダクト開発部 SRE の koizumi です。

この記事は Gunosy Advent Calendar 2023 の 22 日目の記事です。昨日の記事は TksYamaguchi さんの「Snyk を導入してコンテナセキュリティ対策の運用を回している話」でした。

本日はこの1年を振り返り、弊社の主要なGitHubリポジトリのCIをCircleCIからGitHub Actionsへと移行した話について取り上げたいと思います。

きっかけ

GitHub Actionsへの移行を始めたきっかけは遡ること丁度1年前の出来事となります。 正月休み明け早々、CircleCIから以下のセキュリティインシデントが発表されました。

circleci.com

CircleCIが不正アクセスを受け、contextなどに保存された利用者の環境変数、キー、トークンなどの情報の一部が流出したことがわかりました。 CircleCIからは保存されているSecretのローテーションを指示されました。

弊社でも、一旦開発を止めてCircleCI上の各種SecretをRevokeし、再発行と差し替えを実施しました。

当時のSlackタイムライン

GitHub Actionsの技術コミュニティが活性化してきていることも相まって、社内においてもGitHub Actionsへの関心が徐々に高まってきていましたが、CircleCIからの移行コストを考えると、後回しになっていた状況でした。 そのようなタイミングで、このインシデントが発生したことがきっかけとなり、ようやく重い腰が上がりました。

CircleCIからの移行

弊社ではAWS環境を主に使用しており、プロビジョニングにはTerraformおよびHelmを使用しています。 このTerraformやHelmを管理しているリポジトリにて、GitHub Actionsへの移行が先行的に進んでいきました。

ただ、ご存知の様にCircleCIとGitHub Actionsではワークフローの設定方法に違いがあるため、一気に全てのワークフローを移行するのは少し大変でした。

そこで、まずは影響の少ない一部のワークフロー(git-pr-releaseやreviewdog)をGitHub Actionsに移行していきました。

これらの一部ワークフローの移行が完了した後、残りの各ワークフロー( terraform applyhelmfile apply )を順次移行していきました。

知見の横展開

移行は全てのチームで同時並行的に進んでいたわけではなく、いくつかのチームで先行的に進んでいた状況でした。 そこで、移行を進めているチームにおいて得た知見を他チームにも共有する場を作りたいと思い、Slackチャンネルを作成しました。

これにより、各チームで動いているワークフローにおける課題をどう解決したか、便利そうな機能やアクションの共有などが行われ、うまく知見の横展開ができたと思います。

Slackチャンネルの様子

共通アクションの整備

移行しているなかで、さまざまなリポジトリにおいて複数の共通したアクションがありました。 この共通したアクションを切り出すことにより、コードをシンプルに保ち、新たに移行するワークフローにおいてもその共通アクションを利用すれば良いので比較的楽に移行できます。

このアクションの共通化は Composite Action と呼ばれています。(以下の公式ドキュメントが参考になります) docs.github.com

弊社では、Composite Action を管理するリポジトリを作成し、そこに共通したアクションを整備しています。 例として、レビュワーを自動アサインするアクションや、ワークフローの結果をSlackに通知するアクションなどがあります。

使用方法としては、Stepの中で以下のようにリポジトリとアクション名、そのバージョンを指定して、設定している入力変数を渡してあげれば簡単にワークフローを実装することができます。

jobs:
  my-job:
    runs-on: ubuntu-latest
    steps:
      - uses: hoge/fuga/composite-action@composite-action_v0.1.1

移行して感じたこと

まず初めに感じたこととしては、OSSで提供されているActionsがとても便利な点です。 例えば、先日の「tfaction を導入したら便利だった話」でも紹介した tfaction は社内でも広く使われています。

その他にも様々な便利なActionsがOSSで用意されており、車輪の再発明をせずに比較的簡単にワークフローを実装できます。

また、AWSがGitHub ActionsにおいてOIDC認証を提供しているため、クレデンシャル情報をGitHub ActionsのSecretsに保存する必要がなく、CircleCIのようにGitHub Actionsへ不正アクセスが発生したとしても、クレデンシャル情報が漏洩するリスクを軽減できます。

docs.github.com

課題

ある程度主要なリポジトリにおいてはGitHub Actionsへの移行が完了しているものの、依然としてCircleCIを利用しているリポジトリも多く存在します。 これらのリポジトリをどのように移行していくかは今後の課題点だと感じています。

また、CircleCIからGitHub Actionsへの移行には GitHub Actions Importer というツールがあります。 しかし、実際に利用してみるとImport後のワークフローの修正なども発生することもあったため、移行に際しては基本的に1からワークフローを作り直していく必要があります。

OSSで提供されているActionを使用したり、共通化されたAction(Composite Action)の整備を進めていくことで移行障壁を下げていければと思っています。

まとめ

弊社におけるCircleCIからGitHub Actionsへの移行した話について紹介しました。 少しでも参考になれば幸いです。

明日は Liang さんの「CircleCI + Android UI Test スクリーンショットの確認仕組み」についてです!お楽しみに!