見出し画像

Zaim でやっている GitHub のカスタマイズと運用ポリシーを大公開

たかやま

Zaim で開発部署のマネージャーをしております高山です。最近は Rive というサービスを使ってアニメーションを作るのが楽しくてハマってます。アプリに組み込むのが簡単なのがいいですね。自分はデザイナーじゃないので細かい調整が難しいですけど、個人開発レベルならプログラマーでもなんとかなるかなって感じでおすすめです。

・・・

さて、Zaim での開発は GitHub が中心です。GitHub には大変お世話になっています。GitHub はリポジトリ毎に権限や利用する機能の設定なんかができますよね。みなさんどんな設定にしていますか？ Zaim では、開発に関する運用ポリシーを定めているので、それにあわせてできるだけ設定を統一化しています。

というわけで、Zaim でどんな設定をしているのか紹介いたします。「これから GitHub の運用ルールを決めていきたい」「他社がどんな設定にしているのか興味がある」という方の参考になれば幸いです。

GitHub 利用の共通ルール

Zaim では電子決済等代行業者に登録している関係上、問題が起きないようセキュリティや運用には厳しい面があります。たとえば開発では単独作業を禁止しているので、必ずコードレビューを通してから本番環境に反映するという流れがあります。

ブランチの運用ポリシーとして GitHub Flow に近い運用をしています。ざっくり言うと「メインとなるブランチから作業用のブランチを作成して開発、プルリクエストを作成し、レビューが通ったらマージ」です。

コードレビューでは、コードの可読性や設計、コーディングガイドに沿っているかなどはもちろん、しっかり仕様を充たせているか、といった観点も含めて総合的に見ていきます。このあたりの方針に関しては、以前書いたこちらの記事もご参照ください。

タスク管理

Zaim でのタスク管理は Asana というツールになるべく集約させていて、GitHub issues の利用は限定的です。ソフトウェアエンジニア以外の職種も多くいるため、なるべく皆が共通して触れるツールを利用したいことと、GitHub issues はタスクの期限が設定できないなどの理由があります。

しかし GitHub issues をまったく利用しないというわけではなく、開発者のみが関係するタスクに絞って活用しています。具体的には、SDK やライブラリのアップグレードにまつわるタスクや、もう確実にやることが決まった開発タスクなどを管理する場合です。Asana から GitHub issues、そしてプルリクエスト、という流れでタスクが動いていくこともあり、それぞれのタスク内に参照元のリンクがあるので、コミットから経緯を辿りやすくなっています。

継続的インテグレーション

Zaim では Bitrise、AWS CodeBuild、GitHub Actions といった CI サービスを利用しています。

CI が担っている範囲は広範囲で、コードレビュー補助としては静的解析ツールや、ユニットテスト、UI テストを実行しています。サーバーサイドのプロジェクトでは Docker のビルド、アプリのプロジェクトではストア用のバイナリのビルドやデプロイなどを実施しています。

使っているツール類の抜粋

  • Android プロジェクト：ktlint, fastlane

  • iOS プロジェクト：SwiftLint, fastlane, Quick, XCUITest

  • サーバーサイドプロジェクト：PHPStan, PHPMD, RuboCop, PHPUnit, textlint, RSpec

人間がやる必要がないことはなるべく機械に任せられるようにと、環境を構築しています。このあたりの具体的な設定内容も、いつか紹介できたらなと思います。

基本的なリポジトリ設定

次に GitHub リポジトリの Settings の内容を見ていきます。

使わない機能はオフにする

Features の機能はほぼオフにしています。

テキストコミュニケーションは、Slack や Asanaを中心にしていますので、ディスカッションする場所が増えると、過去の経緯を検索したい場合に見るべき場所が増えてしまい厄介なので、利用するツールをしぼっています。同様に、ドキュメント管理ツールには Kibela を使っているので、Wikis もオフにしています。

先述したように、開発が決まったタスクや開発者のみしか関係のないタスクは Issues で管理しているので、Issues は残しています。

プルリクエストまわりの便利機能をオンにする

Pull Requests の設定はあまりいじっていません。マージ方法も自由です。Allow auto-merge、Automatically delete head branches はデフォルトオフなのでオンに変更しています。

Allow auto-merge は「CI の動作やコードレビューなどのステータスチェックがすべてクリアになったときに自動でマージする」というボタンが使えるかどうかの設定です。利用頻度は高くありませんが、main ブランチへのマージ待ち時間を最小化できるこの機能は気に入っています。

Enable auto-merge ボタンが使えるようになる

Automatically delete head branches は、PR をマージした場合にそのときに使っていたブランチを remote 上から自動で削除してくれる機能です。マージしたブランチを残しておく意味は正直あまりないと思っているので、ここは必須かなと思っています。

ブランチの保護でレビュー必須に

Branches の設定内にある Branch protection rules でメインブランチに関してはマージ前のレビュー必須などのルールを追加しています。

main/master ブランチは保護対象に

具体的には以下の項目を必須としています。

  • マージ前にプルリクエストを作成する

  • 一人以上からコードレビューで Approve をもらう

  • Approve をもらったあとにコミットしたら、レビューをやり直し

  • マージする前に CI のステータスチェックが通っている

  • Administrator 権限を持っていても同様

これらの項目は、冒頭で挙げたとおり「単独作業」を避けるためのシステム的な制限として機能しています。

CI のステータスチェックを守ることも大事だと考えています。さきほども紹介したように、それぞれのプロジェクトで CI に静的解析やユニットテストを任せています。ローカルで開発しているときに、うっかりインデントを間違えてしまったり、テストが通らないコードを書いてしまったりして、そのままプルリクエストを作ってしまうことは誰しもあると思います。

こうした場面でステータスチェックを必須にしていないと、うっかり誰かが高速でレビューしてそのまま最速でマージしてしまうなんていう形で誤ったコードが紛れ込んでしまうことがあるかもしれません。こうしたヒューマンエラーは避けられるなら避けたいと考え、なるべく安全側に倒すための設定にしています。

終わりに

おおざっぱではありましたが、Zaim ではこのような設定で運用しているという紹介をしました。個人的には、ツールやサービスの設定をするのが大好きなのでかなり楽しくやっています。もっと細かい部分の話しなど興味があれば、以下からカジュアル面談という形でいつでも話を受け付けておりますので、ぜひぜひお声がけください。


この記事が気に入ったらサポートをしてみませんか？