ワークフロー
=============

Bazaarはただのツール
---------------------

Bazaarは多くの異なる共同作業の方法を支援します。
このことはあるワークフローで始めて状況が変われば別のワークフローを\
採用できることを意味します。
"唯一の正しい方法"は存在しませんし今後も現れることはりません。
このセクションではBazaarによってサポートされる人気のあるいくつかの\
ワークフローの手短な概要を提供します。

これらのワークフローはBazaarの使い方の *一部* であることを念頭にお願いします。
ここに記載されていないワークフローを利用したいのであれば、\
下記に記載されているアイディアを足場にします。

ソロ
----

ソフトウェアを開発する、ドキュメントを編集するもしくは設定ファイルを\
変更するのであれ、簡単に使えるVCSは手助けになります。
投稿者が1人であるプロジェクトを複数管理するために\
単独のユーザーはこのワークフローを効率的に利用できます。

.. image:: images/workflows_single.png

まったくバージョン管理を使わない場合と比べたこのワークフローの利点は次のとおりです:

 * 古いバージョンのバックアップ
 * 前の状態へのロールバック
 * 履歴の追跡

このワークフローに適切なBazaarの主要な機能は管理作業が少ない\
(サーバーのセットアップは不要)ことと簡単に利用できることです。


パートナー
-----------

時に2人で変更を共有して共同作業をする必要があります。
これは一般的に *ソロ* のワークフロー (上記を参照) もしくは\
チーム指向のワークフロー(下記を参照)として始まります。
ある時点で、2人目の人が最初の人が行った内容(履歴も含む)を含む\
ブランチを作ります。
適切なときにマージして変更内容を交換することで並行して作業できます。

.. image:: images/workflows_peer.png

*ソロ* を上回る利点は次のとおりです:

 * 変更の共有が簡単
 * それぞれのテキストファイルのそれぞれの行は変更した人、\
   時間と理由を含む特定の変更と結びつけられています。

このワークフローを採用する場合、BazaarはCVSとSubversionに対して
次のような利点があります:

 * サーバーのセットアップが不要
 * インテリジェントなマージ機能により複数回のマージ作業が苦痛では
   なくなります。


集中型
-------

*lock-step* としても知られますが、これはCVSとSubversionによって\
推奨/強制されるワークフローと本質的に同じです。
すべての開発者が同じブランチに取り組みます。
最新の内容をチェックアウトするために ``bzr update`` を実行し、\
変更内容を中心位置にコミットするために ``bzr commit`` を実行します。

.. image:: images/workflows_centralized.png

このワークフローを導入するのであればSubversionとCVSも簡単なのでよい選択肢です。
Bazaarはこのワークフローも直接サポートしていて、CVSとSubversionを上回る利点を\
いくつかもちます:

 * よりよいブランチとマージ
 * よりよいリネームのサポート


ローカルなコミットで集中型
---------------------------

このワークフローは、開発者が ``commit --local`` もしくはチェックアウトをunbind\
して一連の変更を行うこと以外は、 *集中型* モデルと基本的に同じです。
こういった一連の変更が完了するとき、開発者は作業内容を共用のメインラインに\
コミットします。

.. image:: images/workflows_localcommit.png

*集中型* を越える利点:

 * 旅行の間にネットに接続していないなどのオフラインで作業できます
 * 誰かの作業を妨げる良くないコミットをする機会が少なくなります

SubversionとCVSはこのモデルをサポートしません。
他の分散型VCSツールはこれをサポートしますが、Bazaarよりも直接的ではありません。


共用のメインラインで分散型
-----------------------------

このワークフローにおいて、それぞれの開発者は独自のブランチを持ち、\
加えてメインブランチにコミットする権限があります。
開発者は個人のブランチに取り組み、準備ができたらそれをメインラインに\
マージします。

.. image:: images/workflows_shared.png

*ローカルコミットつきの集中型* を越える利点は次のとおりです:

 * 作業内容の編成が簡単になる - それぞれのブランチで個別の変更を開発できます。
 * 開発者は共同作業に取り組むときに別の人の個人ブランチをマージできます。

SubversionとCVSはこのモデルをサポートしません。\
他の分散型VCSツールはサポートします。
Bazaarの多くの機能は、簡単な利用、共用レポジトリ、統合されたマージ機能と\
リッチなメタデータ(ディレクトリのリネームの追跡を含む)を\
含めてこのワークフローに有効です。

人間のゲートキーパーで分散型
-----------------------------

このワークフローにおいて、それぞれの開発者は独自のブランチを持ち、\
それに加えてメインのブランチに対してリードオンリーのアクセス権限を持ちます。
1人の開発者(ゲートキーパー)はメインのブランチにコミットする権限を持ちます。
1人の開発者が彼らの作業をマージしたい場合、ゲートキーパーに\
マージしてくれるように頼みます。
ゲートキーパーはコードのレビューを行い、必須の基準を満たすのであれば\
作業内容をメインブランチにマージします。

.. image:: images/workflows_gatekeeper.png

*共用のメインラインによる分散型* に対する利点は次のとおりです:

 * 常にコードはメインラインに入る前にレビューされます。
 * 変更をメインラインに組み込むときに厳格なコントロールができます

Bundle Buggyと呼ばれるBazaarのコンパニオンツールはどんな変更が\
レビュー待ちになっているのか、その変更のステータスとレビューアの\
コメントを追跡するのにとても便利です。


自動的なゲートキーパーで分散型
-------------------------------

このワークフローにおいて、それぞれの開発者は独自のブランチを持つのに加えて、\
メインストリームにリードオンリーのアクセス権限を持ちます。
ソフトウエアのゲートキーパーはメインのブランチにコミットする権限を持ちます。
開発者が作業内容をマージしたいとき、開発者は別の人にレビューを頼みます。
レビューに合格したら、チームの方針によって、オリジナルの著者もしくは
レビューワがゲートキーパーソフトウェアにマージするように頼み、
ゲートキーパーソフトウェアはマージし、コンパイルし、テストスィートを実行します。コードがパスする場合のみ、メインラインにマージされます。

注: 代替として、レビューのステップをスキップして著者は変更を自動化された\
ゲートキーパーに投稿できます。
(これはコードのレビューを別のステップとしてではなくジャストインタイムの\
レビューを効果的に推進するペアプログラミングといった習慣を利用している\
ときにとりわけ適切です。)

.. image:: images/workflows_pqm.png

*人間のゲートキーパーによる分散型* に対する利点は次のとおりです:

 * コードはメインラインに入る前に常にテストされます
   (メインラインの完全性が高まります)
 * チームの規模の成長に対応できます

BazaarのコンパニオンツールであるPatch Queue Manager (PQM)
は自動化ゲートキーパーの機能を提供します。


ワークフローを実施する
-----------------------

上記のそれぞれのワークフローを実施する方法を詳しく知りたいのであれば、\
このマニュアルの3章から6章までを参照してください。最初に、2章で、\
インストール方法、一般的な使い方の手引きと設定方法に関するティップス\
が説明されています。