ワークフロー

Bazaar

previous page next page

ワークフロー

Bazaarはただのツール

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

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

ソロ

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

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

古いバージョンのバックアップ

前の状態へのロールバック

履歴の追跡

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

パートナー

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

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

変更の共有が簡単

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

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

サーバーのセットアップが不要

インテリジェントなマージ機能により複数回のマージ作業が苦痛ではなくなります。

集中型

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

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

よりよいブランチとマージ

よりよいリネームのサポート

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

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

集中型 を越える利点:

旅行の間にネットに接続していないなどのオフラインで作業できます

誰かの作業を妨げる良くないコミットをする機会が少なくなります

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

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

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

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

作業内容の編成が簡単になる - それぞれのブランチで個別の変更を開発できます。

開発者は共同作業に取り組むときに別の人の個人ブランチをマージできます。

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

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

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

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

常にコードはメインラインに入る前にレビューされます。

変更をメインラインに組み込むときに厳格なコントロールができます

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

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

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

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

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

コードはメインラインに入る前に常にテストされます (メインラインの完全性が高まります)

チームの規模の成長に対応できます

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