- Development (開発の進め方)
- Testing (テスト)
- Deployment (リリースの仕方)
- Releases (リリース後の記録)
- References(参考文献)
- Appendix(付録)
- History(更新履歴)
Development (開発の進め方)
GitHub Flow の利用
- masterブランチは常にデプロイ可能な状態としなければならない
- テストが失敗する状態の場合、直ちに修正するべきである
- テストが失敗する状態の場合、デプロイすることは許されない
- 「新しい何か」に取り組む際は、 pull request を用いるべきである
- ブランチは master から作成し、ブランチ名は説明的な名前とすべきである（例: new-oauth2-scopes, fix-wrong-classname）
- 作成したブランチにローカルでコミット後、ただちに GitHub に push し タイトルに [WIP] と付けた pull request を作成しなければならない
- typo fix や十分に設計が行われているもの以外は
git commit --allow-empty -m "wip"等を用いて空コミットから pull request を作り、設計について議論すべきである - pull request 作成時に完了条件をチェックボックスで書くべきである(例: テストコード、モデルの修正、ビューの文言の修正)
- pull request 作成時に「pull request が解決する内容」を書くべきである(例: クエリの最適化により、○○画面の表示速度が改善される、画像の差し替えにより広告のクリック率改善が見込める)
- 完了条件、pull request が解決する内容は、情報が記載されている issue へのリンクを貼れば記載は不要である
- 半日に一度は作業内容を push するべきである
- 終業時には push しなければならない
レビューの実施
- pull request はレビューされていなければならない
- レビューアを GitHub のメンションを用いて指定しなければならない
- レビューアにレビューしてもらいたい内容を書かなければらない(例: 変更したクエリが本番でも問題無く動くか、リニューアルした画面の配色が違和感ないか)
- レビューアがコメントを行い、レビューイが確認と反映を行う
- pull request を master へマージするには、レビューアとレビューイのお互いが納得した状態にならなければならない
- マージをして master へ push したら、デプロイを行う
- merge 後は pull request に用いたブランチは削除しなければならない
Testing (テスト)
- デベロッパーテストはプロジェクトごとに方針を決定する
- 本番リリースをする前に開発環境 (integration)、ステージング環境 (staging) の両方で動作テストを行うべきである
- 緊急時は例外的に staging のみの動作テストも許可する
- バックグラウンドジョブに変更を加えた場合は、ジョブワーカーを使用している箇所全ての動作テストを行わなければならない
Deployment (リリースの仕方)
- デプロイは pull request の作成者が行う
- デプロイ前に前回のリリースとの差分をチェックしなければならない
- 差分に自分が把握していない、意図しない変更が含まれている場合は関係者に確認しなければならない、この場合、必要に応じてデプロイ担当を変更すべきである
- デプロイは capistrano もしくは webistrano を用いるべきである
- デプロイ実行前に IRC で "何処に" "何を" デプロイするのかを宣言しなければならない
- ミドルウェアの設定変更など、インフラメンバーに関係ある変更を加える場合は、IRC でメンションを行わなければならない
- デプロイを実行するには、自分以外の開発メンバーからの返事を確認しなければならない
Releases (リリース後の記録)
- production へデプロイした際に "release-20131010-1504" のような形式で自動的にタグを作成されるようにすべきである
- 自動で作成されたタグは Releases に追加記載される
- Releases に リリースノート(変更内容を人間が読める形にしたもの)をデプロイした本人が作成すべきである
- リリース後は analytics, newrelic, kibana 等を用いて、新しい何かのリリースによって、発生した変化を確認すべきである
- 確認した内容は pull request または該当する issue に結果を記録すべきである
References(参考文献)
- OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい（もしくはコードレビューの話） - kazuhoのメモ置き場
- コードレビュー - hitode909の日記
- Code Review in Action // Speaker Deck
- pull request を利用した開発ワークフロー // Speaker Deck
Appendix(付録)
Release's notes の作成方法
- 対象のタグページを開き、右上の
Edit tagボタンをクリックする Release titleにタグと同じ名前を入力するDescribe this releaseに、このリリースでデプロイされた機能や修正を記載する(Issue や Pull Request の URL を一緒に記載するとよい)Publish releaseボタンをクリックする
History(更新履歴)
2014/03/15
- –allow-empty を用いた pull request 作成方法について追記
- Appendix を新設
- References を新設