目次
背景
最近インフラを触り始めた人と一緒に働くことが多くなってきた。みんなに効率よく経験を積んでもらいつつ、インフラチームをうまく回すための施策を細々考えている。この記事はその中の一つについてのメモ。 私は「こういう内容が良いのではないか」と思って作ったものなので今後チーム内外の意見をもらって内容が書き換わる可能性は大いにある。
GitHubのテンプレート機能はどう使うか
レポジトリのルートディレクトリに PULL_REQUEST_TEMPLATE.md という名前でファイルを置くと、プルリクを作るときに自動的にその内容が書かれる。 詳しい置き方や仕様についてはググれば出てくるのでここには書かない。
テンプレートを作るにあたり気をつけたこと
- 後からプルリクを見直したときに、何をやっているか分かるか。後から新人が入ってきたときにプルリクをトレースして学ぶことができるようにしたい。
- 開発環境や本番環境に全て(半)自動反映になっていれば最高だが、今のところそうなっていない。 反映漏れ事故をなくしたい。
- コードだけ書いて本番に反映せず満足してしまう人もたまに居るので、きちんとデリバリーしようという意識を持ってもらうために、それを促す記述を入れたい。
- プルリクを出した後のネクストステップを意識するとスムーズに仕事が回るので、それを考えてもらいたい。
- 時間は無限ではないので緊急度や重要度を意識して、やらなくて良い仕事はやらない。ネクストステップがない場合もある。
- よく分からないことをプルリク出してもレビュアが気がつかなければプルリクが通ることがある。事故の元なので曖昧なことは表明してもらってみんなで解決したい。
テンプレート内容
# 概要 ### 経緯 issueやconflenceリンクがある場合にはそれを張っても良い。 ### このprの目的 課題は何か ### 変更点概要 この変更によりどう解決されるのか # 本番/開発環境更新 ### 反映タイミング 開発環境と本番環境への反映を行うタイミングを記述する。以下の選択肢から1つ選択して詳細を記述する。 * 開発環境に反映済み * 対象サーバを記述する * マージ後開発環境にのみすぐ反映する * しばらく開発環境で動作を確認したい場合に選択。もしくは緊急度が低く、本番へは次のサーバリプレイス時に入れば良いという場合 * 反映すべきサーバを書いておく * マージ後すぐに本番に反映する * 緊急度が高い場合 * 本番更新チケットを作成して、リリースタグを切って反映する。参考: http://hogehoge.jp * 反映すべきサーバを書いておく ### 動作確認手順 更新後に行う動作確認の手順を記述する。すでに開発環境で動作確認を行っている場合にはその内容を書く。 できるだけprを出した本人以外でも動作確認ができるように書く。自明な場合には記述しなくてもよいが、レビュアーはレビューをする段階で分からなかったら確認するのが望ましい。 # 関連issue/pr/外部リンク # その他 ### 今後の課題 次に解決すべき課題があれば書く。 ### 実装に関する留意点 困ったことやイマイチな点など。