1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
|
ゲートキーパーを利用する
=========================
分散型の人間のゲートキーパーのワークフロー
-------------------------------------------
このワークフローでは、1人の開発者(ゲートキーパー) がメインブランチへの\
コミット権限を持つ一方で他の開発者はリードオンリーの権限のみを持ちます。
すべての開発者はタスクブランチの中で変更を行います。
.. image:: images/workflows_gatekeeper.png
開発者は彼らの作業内容をマージしたいとき、ゲートキーパーに彼らの変更を\
レビューして受け入れ可能であればマージするよう頼みます。
変更がレビューを失敗するとき、準備ができるまで関連のタスクブランチで\
さらなる開発が進みます。
このアプローチの主要な面は含まれる制御の反転です:
開発者は変更を中心ブランチに"コミット/プッシュ"するときを決めなくて済みます:
コードベースはゲートキーパーの "マージ/プル" による統制された変更方法によって発展します。
複数の中心ブランチとそれぞれ異なるゲートキーパーをを持つことはとてもよい方法で、
よく採用されている方法です。。
たとえば、現在の製品リリースと次のリリースのためにそれぞれ1つづつのブランチがあります。
この場合、たいがいはバグ修正を保持するタスクブランチは両方のゲートキーパーによって\
通知されます。
このワークフローのすばらしい点の一つはスケーラブルであることです。
大きなプロジェクトはチームになりそれぞれのチームはゲートキーパーによって管理される
*ローカルマスターブランチ* を持つことができます。
チームリーダーがリクエストするときにチームのマスターブランチからの変更を\
プライマリマスターブランチにマージするために誰かを主席ゲートキーパーに任命できます。
分散型の自動ゲートキーパーのワークフロー
-----------------------------------------
より高い品質を得るために、すべての開発者は変更を回帰テストスイートが通ったら\
変更のマージとコミットだけを行う自動ゲートキーパーに投稿できることが求められます。
このようなゲートキーパーの1つはPQMと呼ばれるソフトウェアツールです。
.. image:: images/workflows_pqm.png
PQMに関する詳細な情報に関しては、 https://launchpad.net/pqm を参照してください。
|