ゲートキーパーを利用する

分散型の人間のゲートキーパーのワークフロー

このワークフローでは、1人の開発者(ゲートキーパー) がメインブランチへのコミット権限を持つ一方で他の開発者はリードオンリーの権限のみを持ちます。 すべての開発者はタスクブランチの中で変更を行います。

../_images/workflows_gatekeeper.png

開発者は彼らの作業内容をマージしたいとき、ゲートキーパーに彼らの変更をレビューして受け入れ可能であればマージするよう頼みます。 変更がレビューを失敗するとき、準備ができるまで関連のタスクブランチでさらなる開発が進みます。

このアプローチの主要な面は含まれる制御の反転です: 開発者は変更を中心ブランチに”コミット/プッシュ”するときを決めなくて済みます: コードベースはゲートキーパーの “マージ/プル” による統制された変更方法によって発展します。 複数の中心ブランチとそれぞれ異なるゲートキーパーをを持つことはとてもよい方法で、 よく採用されている方法です。。 たとえば、現在の製品リリースと次のリリースのためにそれぞれ1つづつのブランチがあります。 この場合、たいがいはバグ修正を保持するタスクブランチは両方のゲートキーパーによって通知されます。

このワークフローのすばらしい点の一つはスケーラブルであることです。 大きなプロジェクトはチームになりそれぞれのチームはゲートキーパーによって管理される ローカルマスターブランチ を持つことができます。 チームリーダーがリクエストするときにチームのマスターブランチからの変更をプライマリマスターブランチにマージするために誰かを主席ゲートキーパーに任命できます。

分散型の自動ゲートキーパーのワークフロー

より高い品質を得るために、すべての開発者は変更を回帰テストスイートが通ったら変更のマージとコミットだけを行う自動ゲートキーパーに投稿できることが求められます。 このようなゲートキーパーの1つはPQMと呼ばれるソフトウェアツールです。

../_images/workflows_pqm.png

PQMに関する詳細な情報に関しては、 https://launchpad.net/pqm を参照してください。

目次

前のトピックへ

ブランチを編成する

次のトピックへ

変更を送信する

このページ