summaryrefslogtreecommitdiff
path: root/doc/ja/user-guide/using_gatekeepers.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/ja/user-guide/using_gatekeepers.txt')
-rw-r--r--doc/ja/user-guide/using_gatekeepers.txt42
1 files changed, 42 insertions, 0 deletions
diff --git a/doc/ja/user-guide/using_gatekeepers.txt b/doc/ja/user-guide/using_gatekeepers.txt
new file mode 100644
index 0000000..ff089df
--- /dev/null
+++ b/doc/ja/user-guide/using_gatekeepers.txt
@@ -0,0 +1,42 @@
+ゲートキーパーを利用する
+=========================
+
+分散型の人間のゲートキーパーのワークフロー
+-------------------------------------------
+
+このワークフローでは、1人の開発者(ゲートキーパー) がメインブランチへの\
+コミット権限を持つ一方で他の開発者はリードオンリーの権限のみを持ちます。
+すべての開発者はタスクブランチの中で変更を行います。
+
+.. image:: images/workflows_gatekeeper.png
+
+開発者は彼らの作業内容をマージしたいとき、ゲートキーパーに彼らの変更を\
+レビューして受け入れ可能であればマージするよう頼みます。
+変更がレビューを失敗するとき、準備ができるまで関連のタスクブランチで\
+さらなる開発が進みます。
+
+このアプローチの主要な面は含まれる制御の反転です:
+開発者は変更を中心ブランチに"コミット/プッシュ"するときを決めなくて済みます:
+コードベースはゲートキーパーの "マージ/プル" による統制された変更方法によって発展します。
+複数の中心ブランチとそれぞれ異なるゲートキーパーをを持つことはとてもよい方法で、
+よく採用されている方法です。。
+たとえば、現在の製品リリースと次のリリースのためにそれぞれ1つづつのブランチがあります。
+この場合、たいがいはバグ修正を保持するタスクブランチは両方のゲートキーパーによって\
+通知されます。
+
+このワークフローのすばらしい点の一つはスケーラブルであることです。
+大きなプロジェクトはチームになりそれぞれのチームはゲートキーパーによって管理される
+*ローカルマスターブランチ* を持つことができます。
+チームリーダーがリクエストするときにチームのマスターブランチからの変更を\
+プライマリマスターブランチにマージするために誰かを主席ゲートキーパーに任命できます。
+
+分散型の自動ゲートキーパーのワークフロー
+-----------------------------------------
+
+より高い品質を得るために、すべての開発者は変更を回帰テストスイートが通ったら\
+変更のマージとコミットだけを行う自動ゲートキーパーに投稿できることが求められます。
+このようなゲートキーパーの1つはPQMと呼ばれるソフトウェアツールです。
+
+.. image:: images/workflows_pqm.png
+
+PQMに関する詳細な情報に関しては、 https://launchpad.net/pqm を参照してください。