📝

GitHubをチーム開発で利用する際に行った設定などを紹介

2020/12/20に公開

Git

GitHub

GitHub Actions

idea

概要

本記事はPORT Advent Calander 2020の記事になります。
2020年を振り返ると、GitHubの機能を利用してチーム開発をちょっとだけ効率的に・便利にすることができた設定や定義がいくつかあったので、まとめてみることにしました。

本記事で紹介するのは以下の3つです。

レビュー・CI確認の標準化
- Branch Protection Ruleの利用
レビュワー・レビュイーの対応漏れ防止
- Scheduled Reminderの利用
Pull Requestの可視化・運用の標準化
- チームの運用ルールをGitHub Actionsで定義し自動化する

前提としてコードレビューをGitHubのReview Requestの機能を使ってチームメンバーとやりとりをしています。尚、上記機能の一部は有料プランでのみ利用可能です。

レビュー・CI確認の標準化

Branch protection rulesの利用

https://github.com/{{team_name}}/{{repo_name}}/settings/branches

ブランチの削除禁止指定やPull Request時のレビューやCIによる制約をかけることができる設定です。ブランチの保護機能（削除防止やForce Push禁止）は当然利用したいですが、チームとしてのコードレビューやCI確認の標準化に役に立つ機能があるので利用してみました。

具体的にはどんな設定にしたか

レビュワーの最低人数を指定する
オーナーのレビューを必須にする（masterブランチなど）
コードに変更があったときは承認されたレビューも一度却下にする
特定のCIの実行がPassするまではマージできないようにする

それぞれブランチ単位で指定できるので、リリースフロー等に合わせて制約を柔軟に変更できるのがポイントです。

（おまけ）自動ブランチ削除機能やマージ機能

https://github.com/{{team_name}}/{{repo_name}}/settingsの「Merge Button」

オートマージを許可した場合に、CIとレビュワーのチェックがPassすれば自動でマージしてくれる
PullRequestのマージ後に自動でブランチを削除する

Branch protection rulesの機能ではないのですが、これらの設定も利用しています。以前は特にマージ後ブランチを消し忘れて、気づけばマージ済みのブランチが溜まっていたので、自動で消してくれる機能はとても助かりました。

レビュワー・レビュイーの対応漏れ防止

Scheduled Reminderの利用

https://github.com/organizations/{{team_name}}/settings/reminders

Pull Requestのレビュー依頼や、Pull Request毎に誰がボールを持っているのか（レビュワー or レビュイー）をSlack通知で知ることができる機能です。毎日デイリースクラム前などの決まった時間に通知チャンネルに届くようにして、レビューし忘れや対応し忘れを確認することに役に立ちます。
以前はPull Pandaというサードパーティ製のツールを利用していましたが、GitHubに統合されました。

ポイントは、チームで利用する場合はチームメンバー各自がそれぞれの設定を行うことです。

https://github.com/settings/reminders

そうすることによって、チームで利用している通知チャンネルへのGitHubユーザー名がSlackのユーザー名に変換されメンションされます。
また、個人にもダイレクトメッセージでコメント等の通知が飛んでくるので、さらに見逃しを防ぐことができます。

Pull Requestの可視化・運用の標準化

チームの運用ルールをGitHub Actionsで定義し自動化する

GitHub Actionsにはトリガーとなるイベントが多く用意されています。

ブランチやPull Requestの作成などのトリガーイベントを利用すると、トリガーされた時に様々なアクションを起こすことができるので、チームでの運用ルールなどを自動化できます。今回は以下2点を紹介します。

masterに更新があったとき、developに向けたPRを自動作成する
マージするブランチ毎にLabelを自動付与する

1.masterに更新があったとき、developに向けたPRを自動作成する

git-flowでmasterに直接マージを行った場合やreleaseブランチで調整を行なった場合に、masterブランチの変更分をさらにdevelopブランチに反映する作業が発生しますが、該当変更分のPull Requestを作成する機能を自動化しました。

.github/workflows/pulling_into_develop.yml

name: Pulling into develop
on:
  push:
    branches:
      - master
jobs:
  pulling_into_develop:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: create-pull-request
        uses: repo-sync/pull-request@v2
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          source_branch: 'master'
          destination_branch: 'develop'
          pr_title: "Pulling ${{ github.ref }} into develop"
          pr_body: "Pulling ${{ github.ref }} into develop"

プラグインはrepo-sync/pull-requestを利用しました。

masterにpushされた時にトリガーし、Pull Requetの作成が実行されるようにしています。

2.マージするブランチ毎にLabelを自動付与する

どのブランチへマージするPull Requestなのかをわかりやすくするために、マージ先のブランチ名のラベルを付与する作業を自動化しました。
Pull Requestが作られたときのマージ先を確認し、マージ先のラベルを自動で付与しています。

当チームはgit-flowを利用しているので、以下3つを自動で振り分けします。

masterへの直接マージしたいPRか
developへマージしたいPRか
作業ブランチか

https://github.com/actions/labeler
プラグインはactions/labelerを利用しています。
基本的には修正があったPathの条件でLabelを振り分けてくれるものなので、今回のようにマージ先ブランチによってLabelを振り分けるために、以下のように定義ファイルを分割して対応しました。

master

.github/workflows/post_processing_for_master.yml

name: Add Label for master branch

on:
  pull_request:
    types: [opened, synchronize, reopened]
    branches:
      - master

jobs:
  post_processing:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@v2
        with:
          repo-token: "${{ secrets.GITHUB_TOKEN }}"
          configuration-path: '.github/labeler/master.yml'

.github/labeler/master.yml

merge_to_master:
  - "**"

develop

.github/workflows/post_processing_for_develop_branch.yml

name: Add Label for develop branch

on:
  pull_request:
    types: [opened, synchronize, reopened]
    branches:
      - develop

jobs:
  post_processing:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@v2
        with:
          repo-token: "${{ secrets.GITHUB_TOKEN }}"
          configuration-path: '.github/labeler/develop.yml'

.github/labeler/develop.yml

merge_to_develop:
  - "**"

それ以外（作業ブランチ）

.github/workflows/post_processing_for_subtask_branch.yml

name: Add Label for subtask branch

on:
  pull_request:
    types: [opened, synchronize, reopened]
    branches-ignore:
      - develop
      - master

jobs:
  post_processing:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@v2
        with:
          repo-token: "${{ secrets.GITHUB_TOKEN }}"
          configuration-path: '.github/labeler/subtask.yml'

.github/labeler/subtask.yml

subtask:
  - "**"

developとmaster以外のブランチはトリガーの条件でbranches-ignoreで除外しているのがポイントです。冗長なので、別のプラグインを使うなり自分で書いた方が良さそうな感じです・・・。

最後に

チームで行っている運用を可能な限り自動化していくと、効率化につながりますし、作業の俗人化を防げて良いのではないかと思います。
GitHubは新しい機能が日々追加されていくので、効率化のために常にキャッチアップしていきたいですね。