~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

Rework test_script a little bit.


Don't allow someone to request a stdin request to echo.
Echo never reads from stdin, it just echos its arguments.
You use 'cat' if you want to read from stdin.

A few other fixes because the tests were using filenames
that are actually illegal on Windows, rather than just
nonexistant.


Change the exception handling for commands so that
unknown errors don't get silently squashed and then
turn into hard-to-debug errors later.

test_script now passes on Windows.

Show diffs side-by-side

added added

removed removed

Lines of Context:
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 を参照してください。