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