ワークフローの概要

ワークフローをプロジェクト Helix Swarmにおいて、特定のコードベースで共同作業を行い、1つ以上のコードのブランチで定義され、ジョブフィルタ、テスト反映の自動化、展開の自動化のオプションを持つHelixサーバユーザのグループのことです。やプロジェクトブランチに適用することにより、そのワークフロー内で指定されているルールを、プロジェクトやブランチ内のチェンジリストとレビューに適用することができます。「ワークフローの基礎」セクションでは、グローバルワークフロールールとワークフロールールに関する概要と、これらのルールの相互関係について説明します。

この章のセクション:

• ワークフロールール
• ワークフローの基礎
• ワークフローの例
• 複数のワークフローをマージする

ワークフロールール

ワークフローは、以に示す各種のワークフロールールによって構成されます。

レビューなしのコミット時:

このルールは、レビューが関連付けられていないチェンジリストがSwarmの外部でサブミットされた場合に適用されます。

以下に示すいずれかのオプションを選択します。

• 許可: チェンジリストのチェック処理は実行されず、レビューがない状態でチェンジリストがサブミットされます。
• レビューを作成: チェンジリストがサブミットされ、そのチェンジリストに対して自動的にレビューが作成されます。
• 却下: チェンジリストのサブミットが却下されます。
ヒント

チェンジリストの説明内で#reviewキーワードを指定してチェンジリストをサブミットした場合も、選択したルールが適用されます。

レビューありのコミット時: このルールは、以下の場合に適用されます。

• Swarmレビューがコミットされた場合。
• レビューが関連付けられているチェンジリストがSwarmの外部でサブミットされた場合。

以下に示すいずれかのオプションを選択します。

• 許可: チェンジリストのレビュー状態はチェックされません。関連付けられているレビューが承認されていない場合であっても、チェンジリストがコミットされます。
• 承認済みでない場合は却下: 関連するレビューが承認済みで、チェンジリストの内容がそのレビューの内容と一致している場合にのみ、チェンジリストがサブミットされます。
ヒント

#review-nnnnn、#replace-nnnnn、#append-nnnnnのうち、いずれかのキーワードをチェンジリストの説明内で指定してそのチェンジリストをサブミットした場合も、選択したルールが適用されます(「nnnnn」はレビューID)。チェンジリストの説明内にキーワードを指定してそのチェンジリストをレビューに追加する方法については、「Swarmの外部でレビューの作成と変更を行う」を参照してください。

終了状態のレビューの更新時:

特定の状態になっているレビューの内容を自動的に変更されないように保護する場合は、このルールを使用します。デフォルトの場合、[アーカイブ済み]、[却下]、[承認:コミット]の状態になっているレビューが保護されます。保護対象となるレビューの状態は、Swarmの管理者が設定します。

チェンジリストをレビューに追加すると、このルールが適用されます。

以下に示すいずれかのオプションを選択します。

• 許可: レビューはチェックされません。レビューの状態に関係なく、チェンジリストがレビューに追加されます。これが、デフォルトの設定です。
• 却下: レビューの状態が、end_state構成可能変数で指定されたいずれかの状態に一致する場合、以下のような動作になります。
  • レビューの[変更を追加]ボタンが無効になります。
  • チェンジリストの説明内で、#review-nnnnn、#replace-nnnnn、または#append-nnnnnを指定し(「nnnnn」はレビューID)、Swarmの外部でそのチェンジリストを追加すると、そのチェンジリストが却下されます。

次の賛成票をカウント:

デフォルトでは、レビューに対するすべての賛成票が、そのレビューに関連するプロジェクトまたはブランチで設定されている[最小賛成票]の値としてカウントされます。カウントする賛成票を、レビューが関連付けられているプロジェクトのメンバーだけに制限する場合は、このルールを使用します。

特定のユーザがレビューに賛成票を入れた場合に、このルールが適用されます。

以下に示すいずれかのオプションを選択します。

• すべてのユーザ: レビュー内で設定されているすべてのレビュー担当者による投票がカウントされます。これが、デフォルトの設定です。
• Members: レビューが関連付けられているプロジェクトのメンバーが投票した賛成票だけが、プロジェクトまたはブランチで設定されている[最小賛成票]の値としてカウントされます。

自動的にレビューを承認:

デフォルトでは、手動でレビューを承認する必要があります。レビューを自動的に承認する場合は、このルールを使用します。

ユーザがレビューに対して投票した場合、必須レビュー担当者がレビューに追加された場合、必須レビュー担当者が任意レビュー担当者になった場合に、このルールが適用されます。

以下に示すいずれかのオプションを選択します。

• しない: レビューが自動的に承認されることはありません。これが、デフォルトの設定です。
• 投票数ベース: 以下の場合に、レビューが自動的に承認されます。
  • レビューに対する反対票がない場合。
  • レビューのモデレータが設定されていない場合。モデレータが設定されているレビューを自動的に承認することはできません。
  • すべての必須レビュー担当者が、レビューに対して賛成票を入れた場合。
  • レビューで設定されている[最小賛成票]の値が、そのレビューに関連するすべてのプロジェクトとブランチの要件を満たしている場合。
  • 承認をブロックするように設定されているすべてのテストがパスした場合。
  重要

  モデレータが設定されているレビューを自動的に承認することはできません。モデレータの詳細については、「モデレータ」を参照してください。

  ヒント

  自動的に承認されたレビューは、手動でコミットする必要があります。

新しいワークフローを作成する方法については、「ワークフローの作成」を参照してください。

ワークフローの基礎

• ワークフローは、プロジェクトやプロジェクトブランチに関連付けることができます。
  • すべてのSwarmユーザが、ワークフローを作成することができます。
  • プロジェクトやプロジェクトブランチに関連付けられているワークフローを削除することはできません。
  • ワークフローの所有者は、自分が所有しているワークフローを他のユーザと共有することができます。
  • すべてのSwarmユーザが、共有ワークフローを表示することができます。
  • プロジェクトの編集権限を持っているすべてのSwarmユーザが、共有ワークフローをプロジェクトやプロジェクトブランチに適用することができます。
  • ワークフローの共有機能をオフにしても、そのワークフローの共有時に関連付けられていたプロジェクトやブランチは、関連付けられたままになります。
• プロジェクトとブランチ:
  • プロジェクトに関連付けられているワークフローは、そのプロジェクト内のすべてのブランチで使用されます。
  • プロジェクトブランチにワークフローが関連付けられている場合、親プロジェクトのワークフローは無視され、ブランチのワークフローが使用されます。プロジェクトのワークフローは、ブランチのワークフローによって置き換えられます。プロジェクトのワークフローとブランチのワークフローがマージされることはありません。これらのワークフローを使用する理由については、「制限の緩い開発ブランチワークフローを持つ制限付きプロジェクトワークフロー」と「制限の厳しいリリースブランチワークフローを持つプロジェクトワークフロー」を参照してください。
  • ブランチにワークフローが関連付けられていて、管理者によってグローバルワークフロールールが[強制的にオン]に設定されている場合、親プロジェクトのワークフローは無視され、グローバルワークフロールールがブランチのワークフローにマージされます。この場合、最も制限の厳しいルールが適用されます。
• ワークフローの変更:
  • [強制的にオフ]に設定されているグローバルワークフロールールを変更すると、そのルールが、ワークフローが関連付けられていないプロジェクトとブランチに適用されます。
  • [強制的にオン]に設定されているグローバルワークフロールールを変更すると、そのルールが、Helix Coreサーバ全体に適用されます。
  • 特定のプロジェクトやブランチに関連付けられているワークフローを変更すると、変更後のワークフローがそのプロジェクトやブランチで使用されます。
• グローバルワークフロールール: Swarmの管理者がワークフローのグローバルルール内で設定します。各ルールのモードとして、以下に示すいずれかのモードを指定することができます。
  • 強制的にオフ: ワークフローが関連付けられていないプロジェクトとブランチに対して、グローバルワークフロールールが適用されます。
    • ワークフローが関連付けられているプロジェクトまたはブランチの場合、グローバルルールが無視されます。
    • プロジェクトが使用されていない場合、Helix Coreサーバ全体にグローバルワークフロールールが適用されます。
  • 強制的にオン: グローバルワークフロールールがHelix Coreサーバ全体に適用されます。このモードの場合、Helixサーバに対して最小限のワークフローを設定することができます。
    • グローバルワークフロールールが、プロジェクトまたはブランチが関連付けられているワークフローにマージされます。この場合、最も制限の厳しいルールが適用されます。
• テスト:
  • テストがワークフローに関連付けられている場合、そのワークフローに関連付けられたレビューの作成時、更新時、送信時、手動実行時にそのテストが実行されるように設定することができます。
  • テストがグローバルワークフローに関連付けられている場合、レビューの作成時、更新時、送信時、手動実行時にそのテストが実行されるように設定することができます。
  • テストがワークフローまたはグルーバルワークフローに関連付けられている場合、そのテストが失敗したときに承認をブロックするように設定することができます。

ワークフローの例

このセクションでは、Swarmで設定する標準的なワークフローの例を紹介します。

プリコミットレビューワークフローの適用

プリコミットレビューワークフローを適用する場合は、以下のようにルールを設定します。

• [レビューなしのコミット時]を[却下]に設定すると、レビューが承認されていない状態でチェンジリストをサブミットすることができなくなります。
• [レビューありのコミット時]を[承認済みでない場合は却下]に設定すると、チェンジリストに関連付けられているレビューが承認済みで、チェンジリストの内容がそのレビューの内容と一致している場合に、チェンジリストがサブミットされます。

ポストコミットレビューワークフローの許可

ポストコミットレビューワークフローを許可する場合は、以下のようにルールを設定します。

• [レビューなしのコミット時]を[レビューを作成]に設定すると、チェンジリストをサブミットするたびにレビューが作成されます。
• [レビューありのコミット時]を[許可]に設定すると、レビューが関連付けられているチェンジリストをサブミットできるようになります。

制限の緩い開発ブランチワークフローを持つ制限付きプロジェクトワークフロー

コードラインを保護するには、リリースブランチとメインブランチで制限付きのワークフローを使用する必要があります。チェンジリストをサブミットする場合は、そのチェンジリストに承認済みのレビューが関連付けられていて、チェンジリストの内容が承認済みレビューの内容と一致している必要があります。

開発ブランチの場合は、すばやく機能を作成してコミットし、コミット後の機能を確認できるように、制限を緩くすることができます。その場合、承認済みのレビューが関連付けられているチェンジリスト以外はサブミットできないように設定することをお勧めします。

プロジェクトワークフロー:

• [レビューなしのコミット時]を[却下]に設定すると、レビューが承認されていない状態でチェンジリストをサブミットすることができなくなります。
• [レビューありのコミット時]を[承認済みでない場合は却下]に設定すると、チェンジリストに関連付けられているレビューが承認済みで、チェンジリストの内容がそのレビューの内容と一致している場合に、チェンジリストがサブミットされます。
• [終了状態のレビューの更新時]を[却下]に設定すると、完了状態になっているレビューが保護され、そのレビューの内容を変更できなくなります。保護対象となるレビューの状態は、Swarmの管理者が設定します。詳細については、「レビューの保護」を参照してください。
• [次の賛成票をカウント]を[メンバー]に設定すると、レビューが関連付けられているプロジェクトのメンバーが投票した賛成票だけが、プロジェクトまたはブランチで設定されている[最小賛成票]の値としてカウントされます。
• [自動的にレビューを承認]を[しない]に設定すると、レビューの自動承認が実行されなくなります。

開発ブランチワークフロー:

• [レビューなしのコミット時]を[レビューを作成]に設定すると、チェンジリストをサブミットするたびにレビューが作成されます。
• [レビューありのコミット時]を[許可]に設定すると、レビューが関連付けられているチェンジリストをサブミットできるようになります。
• [終了状態のレビューの更新時]を[却下]に設定すると、完了状態になっているレビューが保護され、そのレビューの内容を変更できなくなります。保護対象となるレビューの状態は、Swarmの管理者が設定します。詳細については、「レビューの保護」を参照してください。
• [次の賛成票をカウント]を[すべてのユーザ]に設定すると、特定のレビューで設定されているすべてのレビュー担当者による投票が、プロジェクトまたはブランチで設定されている[最小賛成票]の値としてカウントされます。
• [自動的にレビューを承認]を[投票数ベース]に設定すると、レビューに関するすべての要件が満たされた場合に、レビューが自動的に承認されます。

制限の厳しいリリースブランチワークフローを持つプロジェクトワークフロー

ポストコミットレビューが許可されるワークフローを使用してプロジェクトを設定すると、機能をすばやく作成してコミットし、コミット後の機能を確認することができます。その場合、承認済みのレビューが関連付けられているチェンジリスト以外はサブミットできないように設定することをお勧めします。

コードラインを保護するには、リリースブランチで制限の厳しいワークフローを使用する必要があります。チェンジリストをサブミットする場合は、そのチェンジリストに承認済みのレビューが関連付けられていて、チェンジリストの内容が承認済みレビューの内容と一致している必要があります。

プロジェクトワークフローで以下のルールを使用して、プロジェクトとそのブランチのワークフローを定義します。

• [レビューなしのコミット時]を[レビューを作成]に設定すると、チェンジリストをサブミットするたびにレビューが作成されます。
• [レビューありのコミット時]を[許可]に設定すると、レビューが関連付けられているチェンジリストをサブミットできるようになります。
• [終了状態のレビューの更新時]を[許可]に設定すると、完了状態になっているレビューの内容を変更できるようになります。
• [次の賛成票をカウント]を[すべてのユーザ]に設定すると、特定のレビューで設定されているすべてのレビュー担当者による投票が、プロジェクトまたはブランチで設定されている[最小賛成票]の値としてカウントされます。
• [自動的にレビューを承認]を[投票数ベース]に設定すると、レビューに関するすべての要件が満たされた場合に、レビューが自動的に承認されます。

[リリースブランチワークフロー]で以下のルールを使用して、リリースブランチのワークフローを定義します。親プロジェクトのワークフローは無視され、開発ブランチのワークフローが使用されます。

• [レビューなしのコミット時]を[却下]に設定すると、レビューが承認されていない状態でチェンジリストをサブミットすることができなくなります。
• [レビューありのコミット時]を[承認済みでない場合は却下]に設定すると、チェンジリストに関連付けられているレビューが承認済みで、チェンジリストの内容がそのレビューの内容と一致している場合に、チェンジリストがサブミットされます。
• [終了状態のレビューの更新時]を[却下]に設定すると、完了状態になっているレビューが保護され、そのレビューの内容を変更できなくなります。保護対象となるレビューの状態は、Swarmの管理者が設定します。詳細については、「レビューの保護」を参照してください。
• [次の賛成票をカウント]を[メンバー]に設定すると、レビューが関連付けられているプロジェクトのメンバーが投票した賛成票だけが、プロジェクトまたはブランチで設定されている[最小賛成票]の値としてカウントされます。
• [自動的にレビューを承認]を[しない]に設定すると、レビューの自動承認が実行されなくなります。

複数のワークフローをマージする

異なるワークフローが関連付けられている複数のプロジェクトにまたがるチェンジリストの場合、それらのワークフローがマージされ、最も制限の厳しいワークフロールールがチェンジリストに対して適用されます。マージされたワークフローに関連するすべてのテストが実行されます。重複するテストが存在する場合、それらのテストは1回だけ実行されます。

例1: プロジェクトA、プロジェクトB、プロジェクトCにチェンジリスト1234がまたがっている場合

• プロジェクトA: //depot/jam/lib/...
• プロジェクトB: //depot/jam/docs/...
• プロジェクトC: //depot/common/src/...
• チェンジリスト1234には、以下のファイルが含まれています。
  • //depot/jam/lib/tests/checkLoad.sh
  • //depot/jam/docs/basics.workflow.html
  • //depot/common/src/index.html

これらのチェンジリストファイルは3つのプロジェクトすべてにまたがっているため、各プロジェクトに適用されるワークフロールールの組み合わせにより、チェンジリストに適用されるルールは以下のようになります。この場合、最も制限の厳しいワークフローがチェンジリストで使用されます。

	レビューなしのコミット時	レビューありのコミット時	終了状態のレビューの更新時	次の賛成票をカウント	自動的にレビューを承認	ワークフローテスト
プロジェクトAのワークフロー	許可	承認済みでない場合は却下	許可	すべてのユーザ	投票数ベース	スモークテストA
プロジェクトBのワークフロー	許可	承認済みでない場合は却下	却下	メンバー	しない	スモークテストB
プロジェクトCのワークフロー	レビューを作成	許可	許可	すべてのユーザ	投票数ベース	スモークテストB スモークテストC
チェンジリスト1234のワークフロー	レビューを作成	承認済みでない場合は却下	却下	メンバー	しない	スモークテストA スモークテストB スモークテストC

例2: プロジェクトM、プロジェクトN、プロジェクトブランチN-1にチェンジリスト6789がまたがっている場合

• プロジェクトM: //depot/thirdparty/lib/...
• プロジェクトN: //depot/thirdparty/lib/tests/...
• プロジェクトブランチN-1:
  • //depot/projectN/...
  • //depot/thirdparty/lib/...
• チェンジリスト6789には、以下のファイルが含まれています。
  • //depot/thirdparty/lib/tests/checkReturns.sh
  • //depot/projectN/src/index.html
  • //depot/projectN/tests/pageLoadTest.php

これらのチェンジリストファイルは3つのプロジェクトすべてにまたがっているため、各プロジェクトに適用されるワークフロールールの組み合わせにより、チェンジリストに適用されるルールは以下のようになります。この場合、最も制限の厳しいワークフローがチェンジリストで使用されます。

	レビューなしのコミット時	レビューありのコミット時	終了状態のレビューの更新時	次の賛成票をカウント	自動的にレビューを承認	ワークフローテスト
プロジェクトMのワークフロー	レビューを作成	承認済みでない場合は却下	許可	すべてのユーザ	しない	スモークテストM
プロジェクトNのワークフロー	却下	承認済みでない場合は却下	却下	メンバー	しない	スモークテストN
プロジェクトブランチN-1のワークフロー	レビューを作成	許可	許可	すべてのユーザ	投票数ベース	スモークテストN-1
チェンジリスト6789のワークフロー	レビューを作成	承認済みでない場合は却下	許可	すべてのユーザ	しない	スモークテストM スモークテストN-1

例3: プロジェクトXとプロジェクトYにチェンジリスト3456がまたがっている場合

• プロジェクトX: //depot/main/product/...
• プロジェクトY: //depot/main/product/docs/...
• チェンジリスト3456には、以下のファイルが含まれています。
  • //depot/main/product/tests/fileSelector.sh
  • //depot/main/product/docs/admin.html

これらのチェンジリストファイルは両方のプロジェクトにまたがっているため、各プロジェクトに適用されるワークフロールールの組み合わせと、管理者が設定するグローバルワークフロールールにより、チェンジリストに適用されるルールは以下のようになります。この場合、最も制限の厳しいワークフローがチェンジリストで使用されます。

	レビューなしのコミット時	レビューありのコミット時	終了状態のレビューの更新時	次の賛成票をカウント	自動的にレビューを承認	ワークフローテスト
プロジェクトXのワークフロー	レビューを作成	許可	許可	すべてのユーザ	投票数ベース	スモークテストX
プロジェクトYのワークフロー	却下	許可	却下	すべてのユーザ	投票数ベース	スモークテストY
グローバルワークフロールール	レビューを作成(強制的にオン)	承認済みでない場合は却下(強制的にオフ)	許可(強制的にオン)	メンバー(強制的にオン)	しない(強制的にオフ)	グローバルスモークテスト グローバルフルテスト
チェンジリスト3456のワークフロー	却下	許可	却下	メンバー	投票数ベース	スモークテストX スモークテストY グローバルスモークテスト グローバルフルテスト