ファインディでのGitHub Actions自動化の事例

ファインディ株式会社でフロントエンドのリードをしております新福(@puku0x)です。

GitHub Actionsは、CI/CD以外にも様々な業務の効率化に役立ちます。

この記事では、弊社で実施しているGitHub Actionsを使った自動化について紹介します。

自動化
まとめ

自動化

担当者アサイン

開発フローの中では、Pull requestを作ってからレビューに出すまでにいくつかのタスクを行うことがあります。

弊社では、Pull requestの作成者がAssignee（担当者）となる場合が多いため、↓こちらのActionを用いてアサインの自動化をしています。

github.com

- uses: kentaro-m/auto-assign-action@v2.0.0
  with:
    repo-token: ${{ secrets.GITHUB_TOKEN }}

addAssignees: author
runOnDraft: true

Assigneeのみ自動化しているのは、レビューに出すタイミングをPull requestの作成者側で制御したかったためです。

レビュアーについては、GitHubの標準機能でレビュー用のGitHubチームを作ってランダムアサインするようにしています。

ラベル設定

弊社では、Pull requestをラベルを用いて管理しているチームもあります。

付与するラベルについては、セマンティックバージョニングと相性の良いものが用いられることが多いです。

GitHub - azu/github-label-setup: 📦 Setup GitHub label without configuration.

ラベル設定の自動化は、公式のActionがありますので比較的導入しやすいでしょう。

github.com

actions/labelerは、最近の更新でブランチ名を基にラベルを設定する機能が追加されました。

この例では、ブランチ名の先頭が feat や fix 等であった場合に対応するラベルを付与するようにしています。

'Type: Feature':
  - head-branch: ['^feat']

'Type: Bug':
  - head-branch: ['^fix', '^bug']

モノレポの場合、ファイルのパスに対応するラベルを設定すると、どのプロジェクトに影響するか判断しやすくなります。

'Scope: App1':
  - changed-files:
    - any-glob-to-any-file:
      - apps/app1/**/*
      - libs/app1/**/*

'Scope: App2':
  - changed-files:
    - any-glob-to-any-file:
      - apps/app2/**/*
      - libs/app2/**/*

actions/labelerは、Pull requestのタイトルを基にしたラベル設定には、2024年9月現在だと対応していないようです。

その場合は、手動でGitHubのAPIを呼ぶシェルを組む必要があります。

run: |
  pr_title=$(curl -s -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" \  -H "Accept: application/vnd.github.v3+json" \
  "https://api.github.com/repos/Findy/***/pulls/${{ github.event.pull_request.number }}" \  | jq -r '.title')
  if [[ $pr_title =~ ^feat ]]; then
    pr_type='Feature'
  fi
  curl -X POST -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" \
  -H "Accept: application/vnd.github.v3+json" -d '{"labels": ["Type: '"$pr_type"'"]}' \
  "https://api.github.com/repos/Findy/***/issues/${{ github.event.pull_request.number }}/labels"

いつか公式のActionにも欲しいですね！

リリース

手順の多いリリース作業も、弊社では自動化を取り入れて負担を減らしています。

ここではフロントエンド系のリポジトリに採用されているものを紹介します。

バージョニング用ワークフローを実行
バージョニング用Pull requestが自動生成される
バージョニング用Pull requestをマージ
バージョニング用Pull requestのマージを起点にリリース用Pull requestが自動生成される
（プロダクトによってはここでStaging環境へのデプロイも実行されます）
リリース用Pull requestをレビュー後、マージ
リリース用Pull requestのマージを起点に本番デプロイ

開発者は「ワークフローの起動」と「自動生成されるPull requestのマージ×2」というシンプルな手順で本番デプロイまでできるようになります。

また、Conventional Commits に準拠したコミットメッセージを採用しており、自動バージョニングやリリースノートの自動生成といった恩恵も得られています。

デプロイ頻度はFour Keysの指標にも入っていることから、チームの健康状態を知る手掛かりになります。可能な限り高い頻度でデプロイできるよう、仕組みはしっかりと整備していきましょう💪

参考: https://dev.to/puku0x/github-actions-1mi5

QAチェック項目の抽出

リリースの際に、QA担当者がチェックすべき項目をPull requestの履歴から自動抽出しているチームもあります。

まず、.github/PULL_REQUEST_TEMPLATE.md に次のような項目を設定しておきます。

次に、リリース時に起動するGitHub Actionsから、チェック済みの項目を抽出するスクリプトを起動します。

def category_by_pull(pull)
  return :planner_qa_pr if body.include? "- [x] 企画側QA"
  return :developer_qa_pr if body.include? "- [x] 開発側QA"
  return :other_pr
end

リリース用のPull requestの本文に反映されるため、QA担当者が何を見るべきかがわかりやすくなります。

定期実行

cron が使えるのもGitHub Actionsの良いところです。

on:
  schedule:
    - cron: '30 0 * * 1-5' # 平日09:30 (JST)

休日・祝日の考慮が必要な場合は、次のように前段に判定用のジョブを仕込んで needs で繋ぎます。

check:
  outputs:
    is_holiday: ${{ steps.check_holiday.outputs.result }}
  steps:
    - run: npm install @holiday-jp/holiday_jp
    - uses: actions/github-script@v7
       id: check_holiday
       env:
         TZ: 'Asia/Tokyo' # タイムゾーン固定必須
       with:
         script: |
           const holidayJp = require('@holiday-jp/holiday_jp');
           return holidayJp.isHoliday(new Date());

some_job:
  needs: check
  if: needs.check.outputs.is_holiday == 'false'