ワークフローに関する詳しい手順
この章では、メインラインモデルを使用するプロジェクトでワークフローを使用する場合の例と、Swarmワークフローを作成して使用する場合の詳しい手順について説明します。
- ワークフロー機能を使用するには、Swarm管理者によってSwarmが正しく設定されている必要があります。詳細については、「グローバルワークフロールール」と「warm用のHelix Coreサーバの構成」を参照してください。
- 「ワークフローの概要」ページの説明を読んで、Swarmにおけるワークフローの仕組みを理解してください。
- Swarmのワークフロー機能を使用するメリットについては、「Swarmのワークフローを使用するメリット」を参照してください。
メインラインモデルワークフローの例
プロジェクトの所有者は、メインラインモデルで開発ブランチ、メインブランチ、リリースブランチを使用して、プロジェクトを設定することができます。これらのブランチには、各ブランチタイプに合わせて調整されたワークフロールールが適用されます。
通常、プロジェクトの内容をすばやく変更する場合は、開発ブランチを使用します。プロジェクトの内容を変更する場合は、テストを中断することができます。通常は、内容のコミット後にレビューを行います。この場合は、コミット後レビューモデルになります。多くの場合、1人のレビュー担当者のみがレビューに賛成票を入れることによってレビューを自動的に承認するというワークフローが採用されます。この必要最小限のワークフローを設定すると、開発ラインを短時間で作成することができます。
開発者が2人1組のペアになってプログラミング作業を行う場合、開発作業にかかる時間をさらに短縮するために、レビューを実行せずに変更をコミットすることを許可するケースもあります。以下に示す例では、こうした方法は使用せず、ワークフロールールに従ってレビューを行っています。
メインブランチを使用する場合、通常はコミット前レビューを行います。コミット後レビューの場合と比べて、自動承認をトリガするための賛成票を入れるレビュー担当者の数が多くなり、賛成票を入れるレビュー担当者がプロジェクトメンバーのみに制限されます。こうした仕組みにより、メインブランチの安定性が高くなります。
リリースブランチを使用する場合は、重要な変更のみをブランチにコミットできるようにすることにより、ブランチの内容をさらに保護する必要があります。これを行うには、上級プロジェクトメンバーをモデレータとしてブランチに追加します。レビューの承認と却下を行うことができるのはモデレータのみであるため、モデレータがブランチの「門番」の役割を担当することになります。
開発ブランチの例:
開発ブランチで必要になる要件は、迅速に移動できること、新しい機能、新しい資料、新しい技術をすばやく追加できること、発生する問題をその都度修正できること、などです。多くの作業を迅速に処理しながら、短期間で開発作業を進めることができますが、ブランチの安定性は低くなります。開発ブランチのワークフローは、こうした作業スタイルに合わせて設計されています。
- ブランチルールにより、必要に応じてコミット後レビューを行うことも、コミット前レビューを行うこともできます。
- 変更をコミットしてからレビューをリクエストする場合は、コミット後レビューになります。大規模な変更を行い、その変更内容をディポにコミットして確認のみするという場合は、この方法を使用すると非常に便利です。
- レビュー時に変更を保留する場合は、コミット前レビューになります。ディポにコミットする前に承認が必要なコンテンツや機能を個別に追加する場合は、この方法を使用すると便利です。
- レビューの自動認証をトリガするために必要なレビュー担当者は1人だけです。
メインブランチの例:
メインブランチの場合、リリースが近づくにつれて安定度が高くなっていくため、開発ブランチと比べてより厳格な管理が必要になります。難しい問題を解決して内容を確定し、詳細なテストを行う場合に、メインブランチを使用します。メインブランチのワークフローは、こうした作業スタイルに合わせて設計されています。
- レビュー時に、チェンジリストを保留する必要があります。これは、コミット前レビューになります。
- プロジェクトメンバーの投票のみが、レビューの賛成票としてカウントされます。
- レビューの自動認証をトリガするには、2人のプロジェクトメンバーが賛成票を入れる必要があります。
- チェンジリストの内容が承認後のレビューの内容と正確に一致している場合に限り、チェンジリストをコミットすることができます。
リリースブランチの例:
通常、リリースブランチを使用する場合は、非常に厳密な管理を行ってコードラインを保護する必要があります。製品のリリース前にレビューを承認し、プロジェクトに対してコミットするための権限を持つ限られたユーザにより、ブランチを管理する必要があります。リリースブランチでは高い安定度を保つ必要があるため、どうしても必要な場合を除き、ブランチを変更しないことが重要になります。リリースブランチのワークフローは、こうした作業スタイルに合わせて設計されています。
- レビュー時に、チェンジリストを保留する必要があります。これは、コミット前レビューになります。
- プロジェクトの上級メンバーが、賛成票を入れてレビューを承認する必要があります。
- 最終的にレビューを承認するのはモデレータですが、必須レビュー担当者が賛成票を入れた後で、そのレビューを承認するという役割になります。
- チェンジリストの内容が承認後のレビューの内容と正確に一致している場合に限り、チェンジリストをコミットすることができます。
- 特定のテストが失敗した場合、承認がブロックされます。
このように、3つのワークフローは大きく異なっていますが、各ワークフローのルールについては、つい忘れてしまうことがあります。特に、プロジェクトやチームに初めて参加した場合は、ルールを簡単に忘れてしまいます。しかし、Swarmのワークフローではルールが正しく適用されるため、ブランチを効率的に管理することができます。Swarmのワークフローを使用すれば、リリース目前でリリースビルドの変更が発生したり、コミット前レビューとコミット後レビューが混在したりするようなことはなくなります。
詳しい手順の例
これから作成するワークフローでは、プリコミットレビューモデルが適用されます。このモデルの場合、チェンジリストをディポにコミットする前に、すべてのチェンジリストをレビューして承認する必要があります。
以下に、これ以降の手順で使用される基本ワークフローとプロジェクト設定を示します。
- レビューに対する投票の要件:
- レビューに1票でも反対票が入っている場合、そのレビューを承認することはできません。
- すべての必須レビュー担当者が賛成票を入れる必要があります。
- 必須レビュー担当者を含め、3人以上のプロジェクトメンバーが賛成票を入れる必要があります。
- 投票に関するすべての要件が満たされると、Swarmによって自動的にレビューが承認されます。
- チェンジリストをサブミットする場合の制限事項:
- レビューが存在しないチェンジリストをサブミットした場合、サブミット操作が拒否されます。
- 承認されたレビューが存在しないチェンジリストをサブミットした場合、サブミット操作が拒否されます。
- レビューが[アーカイブ済み]、[却下]、[承認:コミット]の状態になっている場合、レビューを更新することはできません。
この章のセクション:
