こんにちは、YOUTRUST Webエンジニアの寺井(YOUTRUST/X)です。

YOUTRUSTでは、PR(Pull Request)の作成時やPRへのコメント時のSlack通知や、Asanaチケットに該当PRのURLを貼り付けるプロセスなどがGitHub Actionsによって自動化されています。

私はこれまでGitHub Actionsを使ったワークフロー構築の経験はなかったのですが、YOUTRUSTに入社してからこの半年間で、上記のプロセスに加えていくつかの開発プロセスの自動化に取り組んできました。

今回は、私が自動化に取り組んだプロセスをスクリプトと共に紹介したいと思います。

① PRのAssigneeの選択
② PRに対するLabelの付与
③ リリースPRの作成

①PRのAssigneeの選択

1.1 何をやったか

PRを作成したときに自動でAssigneeが選択されるようにしました。

1.2 どうやったか

assign-authorを使いました。

workflows/assign_author.yml

on:
  pull_request:
    types: [opened]
name: Assign author
jobs:
  assignAuthor:
    name: Assign author to PR
    runs-on: ubuntu-latest
    steps:
      - name: Assign author to PR
        uses: technote-space/assign-author@v1

1.3 なぜやったか

1つ目の理由は、チームメンバー全員が毎回行っているAssignee選択の手間をなくすためです。

2つ目の理由は、PR作成時にAssigneeの選択が漏れてしまっていたことが原因で、Assigneeによる検索でヒットしなくなることを防ぐためです。

私自身、誰が実装したかの記憶を元にしてAssigneeで検索することが少なくないので、Assigneeの選択漏れによってPRが埋もれてしまう問題を解決できると助かるなと感じていました。

1.4 どうなったか

dependabotによって作成されたPRなどの例外を除いて、Assigneeが選択されていないPRがなくなりました。

実装者の記憶を元にしてAssigneeで検索したときに、Assigneeの選択漏れが原因でPRがヒットしない問題もなくなりました。

②PRに対するLabelの付与

2.1 何をやったか

PRを作成したときにbranch名があらかじめ決められたものと一致する場合、対応するLabelを自動で付与するようにしました。

2.2 どうやったか

pr-branch-labelerを使いました。

こちらはすでにYOUTRUSTのアプリチームでも運用されていたので、今回そちらを参考にして取り入れました。

workflows/pr-branch-labeler.yml

name: PR Branch Labeler

on: pull_request

jobs:
  label_prs:
    runs-on: ubuntu-latest
    steps:
    - name: Label PRs
      if: github.event.action == 'opened'
      uses: ffittschen/pr-branch-labeler@v1
      with:
        repo-token: ${{ secrets.GITHUB_TOKEN }}

pr-branch-labeler.yml

SNS:
  head: "sns/*"

CLW:
  head: "client-web/*"

Admin:
  head: "admin/*"

2.3 なぜやったか

YOUTRUSTというプロダクトは、プロフィールやフィードなどで構成されるSNS画面と、タレントピックや候補者管理などで構成されており、主に企業の人事の方が触るClient Web画面、そしてAdmin画面の3つに大きく区別することができます。

Web開発チームでは厳密なルールは定めていませんが、開発する機能によってbranch名をsns/hogehoge、client-web/hogehoge、admin/hogehogeとすることが多かったため、branch名の先頭がこの3つと一致している場合は、PR一覧画面でどの画面に関するPRであるかが一目で分かるように、PRに自動でLabelを付与するようにしました。

2.4 どうなったか

付与されたLabelのおかげで、PR一覧画面でどの画面に関するPRであるかが一目で分かるようになりました。

③リリースPRの作成

3.1 何をやったか

リリースPRを自動で作成し、そのリリースPRにmergeしたPRが自動で追記されていくようにしました。

3.2 どうやったか

git-pr-releaseを使いました。

workflows/git-pr-release.yml

name: git-pr-release
on:
  push:
    branches:
      - "release/**"
jobs:
  git-pr-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Set up Ruby 3.1
        uses: actions/setup-ruby@v1
        with:
          ruby-version: 3.1
      - name: Set up Branch Name
        id: vars
        run: echo "::set-output name=branch_name::${GITHUB_REF#refs/heads/}"
      - run: gem install --no-document git-pr-release
      - run: git-pr-release
        env:
          GIT_PR_RELEASE_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          GIT_PR_RELEASE_BRANCH_PRODUCTION: master
          GIT_PR_RELEASE_BRANCH_STAGING: ${{ steps.vars.outputs.branch_name }}
          GIT_PR_RELEASE_LABELS: リリース用
          GIT_PR_RELEASE_TEMPLATE: .github/RELEASE_PULL_REQUEST_TEMPLATE.erb

RELEASE_PULL_REQUEST_TEMPLATE.erb

[<%= pull_requests.reverse.find{ |pr| pr.title.match(/\[(.*?)\]/) }&.title&.match(/\[(.*?)\]/)&.captures&.first || '' %>] リリースPR
## 📝 概要

## 📌 リリース予定のPR一覧
<% pull_requests.each do |pr| -%>
- #<%=  pr.number %> <%= pr.mention %>
<% end -%>

## マイルストーンや仕様書などのURL

3.3 工夫した点

リリースPRのテンプレートでは、1行目がPRのタイトルとみなされます。

デフォルトではRelease <%= Time.now %>となっているため、このようなリリースPRとなります。

週に一度まとめてリリースを行うような、git-flowに沿って開発を行うような組織であれば、このようなPRタイトルで問題ありませんでしたが、YOUTRUSTのように機能ごとでリリースPRを作成したい場合には適したPRタイトルではありませんでした。

PRのタイトルはCIが実行されるたびにテンプレートの1行目で上書きされてしまうため、最初から手動でPRタイトルを設定する前提の運用もうまくいきませんでした。

そこで、すべてのPRのタイトルの先頭に[ ]で機能名を入れる運用を試しに始めて、リリースPRではmergeされたPRのタイトルの[ ]の中の文字列を抽出して使うことにしました。

さらに、この運用を始めたことによって、PR一覧画面で各PRがどの機能のPRなのかが一目で分かりやすくなったり、後から検索したときにヒットしやすくなるなどのメリットもありました。

3.4 なぜやったか

現在YOUTRUSTのWeb開発チームでは、GitHub Flowに沿って開発を進めています。

つまり、main(master)ブランチからトピックブランチを切って開発を行い、mainブランチに向けてPRを作成してmergeする流れとなっています。

しかし、中には1つの機能でまとめてリリースしたいような場面も存在していました。

そのようなとき、これまでは手動でリリース用のPRを作成していましたが、リリースPRを見てもmergeされたPRがすぐには分からないという問題がありました。

その問題を解決するために「リリースPRにmergeしたときはそのPRをリリースPRに追記する」というルールの運用を考えました。

しかし、毎回追記するのは手間がかかる上に、いずれ追記漏れが発生してしまうことが予想されました。

そこで、mergeされたPRを自動で追記していくようなリリースPRの作成をGitHub Actionsを使って作成することを考えました。

3.5 どうなったか

リリースPRが自動で作成されるようになったことで、作成するための手間がなくなりました。

また、リリースPRを見れば、mergeされたPRを抜け漏れなく一目で確認できるようになりました。

終わりに

今回は、GitHub Actionsを使って自動化したプロセスを3つ紹介しました。

他にもPRのReviewerの自動選択など、自動化するとメリットがありそうなプロセスがいくつか思い浮かんでいるので、引き続き開発プロセスの効率化を図って組織の生産性を高めていきたいと思っています。

私はバックエンドの開発だけではなく、フロントエンドやインフラ、そして今回挙げたような開発プロセスの改善など、とにかく自分の領域にフタをせずに挑戦していきたいと思っています。

私と同じようなことを求めている人にとっては、今のYOUTRUSTは本当にぴったりの環境だと思うので、ぜひご応募お待ちしております！

herp.careers

YOUTRUST Tech Blog

GitHub ActionsによってPRのAssignee選択・Label付与・リリースPR作成を自動化した話