← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/ja/user-guide/using_gatekeepers.txt

  • Committer: Vincent Ladeuil
  • Date: 2010-02-05 10:27:33 UTC
  • mto: (5008.1.1 integration)
  • mto: This revision was merged to the branch mainline in revision 5009.
  • Revision ID: v.ladeuil+lp@free.fr-20100205102733-8wpjnqz6g4nvrbfu
All Conflict action method names start with 'action_' to avoid potential namespace collisions

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/ja/user-guide/using_gatekeepers.txt
 
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 を参照してください。