Githubとは？
参照元：http://siliconangle.com/blog/2012/07/09/social-network-for-developers-github-raises-monster-series-a-round-funding-100m/
Github(ギットハブ)とは、プロジェクト管理をWeb上で行うことができるサービスです。ソースファイルのバージョン管理システムにGitというものがあります。Gitはソースファイルのリポジトリ(管理保存先)として、ローカルもしくはリモートを選択してバージョンを管理します。その中でリモートにあたるものがGithubです。
Githubは利用する容量に応じて金額が変わり、無料で利用できるプランも用意されています。優れたサービスとして、プロジェクト管理サービスの中で一際注目を集めています。
プロジェクト管理の機能
参照元：http://kik.xii.jp/archives/179
Githubにはプロジェクトを管理するために様々な機能が用意されています。公開されているプロジェクトを自分のリポジトリにコピーを行い、カスタマイズするFork(フォーク)と呼ばれる機能や、そのカスタマイズしたソースファイルを元の開発者に対して送信するPull Request(プルリクエスト)と呼ばれる機能などがあります。プロジェクトをオープンソースとして公開することで、自分だけではなく多くの人がプロジェクトに携わることができます。また、非公開のプロジェクトを特定のユーザーで共有し、複数人でプロジェクトの開発をすすめることもできます。
プロジェクト開発に当たっての注意事項
参照元：http://blog.xproda.com/2011/07/blog-post.html
Githubの利用
- masterブランチは常にデプロイ可能な状態としなければならない
- テストが失敗する状態の場合、直ちに修正するべきである
- テストが失敗する状態の場合、デプロイすることは許されない
- 「新しい何か」に取り組む際は、 pull request を用いるべきである
- ブランチは master から作成し、ブランチ名は説明的な名前とすべきである（例: new-oauth2-scopes, fix-wrong-classname）
- 作成したブランチにローカルでコミット後、ただちに github に push し タイトルに [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 に結果を記録すべきである
0 件のコメント:
コメントを投稿