タスクブランチのワークフローを実装する方法

このプロセスは、課題追跡システムまたはプロジェクト管理システムのタスクから始まります。Jira、Bugzilla、Mantis、OnTime、または独自の社内ソリューション。ここで重要なのは、すべてのアクションにタスクが関連付けられていることです。新機能の一部であるかバグ修正の一部であるかは重要ではありません。そのためのタスクを作成します。

次に、そのタスクのブランチを作成します。

わかりやすいブランチの命名規則を推奨します。プレフィックス（この例では「タスク」）とそれに続く課題トラッカーのタスク番号。これにより、変更の完全なトレーサビリティを保つことができます。

タスクブランチで作業し、必要なだけチェックインします。コメントの各ステップを説明し、レビューアーにわかりやすく説明してください。

タスクが完了したら、ブランチの「status」属性を「resolved」に設定します。

または、課題トラッカーで完了とマークすることもできます。すべては、特定のツールセットと、ワークフローを実際にどのように実装するかによって異なります。

タスクを完了とマークすると、同僚がレビューできるようになります。

次は、レビュアーが変更箇所を確認し、コードスタイルのバグ、エラー、不整合、または変更すべきデザインの側面を見つけ出す番です。その場合、タスクが再度開かれ、サイクルが再開されます。

検証はオプションの手順です。

チームによってはタスクを「検証」します。別のチームメンバーが短い探索テストを行い、新機能や変更点が適切であることを確認します。彼らはバグを探すのではなく（自動テストがそれを解決します）、顧客の観点から変更を検討します。ステータスは属性で「validated」に設定できます。

特定の属性セットを持つすべてのブランチを監視するように継続的インテグレーション（CI）システムを設定します。ブランチは、特定のステータス（この場合は「検証済み」）に達した場合にのみ CI システムによって考慮されます。

タスクがレビュー/検証されると、メインにマージされる前にタスクブランチが自動的にテストされます。

テストスイートがマージに合格すると、ビルドとテストのために確認され、CI システムに送信されます。このプロセスは、ビルドの破損を防ぐのに役立ちます。失敗した場合はプロセスが再起動され、競合を解決するために main からリベースする必要があります。

テストに合格すると、マージがチェックインされ、ブランチをデリバリする準備が整います。ステータスが「merged」に設定されます。

新しいリリースをデプロイする準備ができたら、メインの新しい変更セットはそのようにラベル付けされ、ソフトウェアは本番環境にデプロイされます。

新しいタスクがこのサイクルを経過した後に新しいリリースを入手することも、いくつかのタスクをグループ化することもできます。継続的デプロイを実践する場合、すべてのタスクを実制作にデプロイするのが最も論理的なワークフローです。

Unity Version Control を使用すると、Jenkins、Bamboo、Unity Cloud Build など、選択した CI ツールのプラグインを使用して、テストとマージの自動化ステップを設定できます

このステップは、Unity Version Control のマージボット機能を使用して調整することもできます。マージボットはブランチをマージし、ビルドをトリガーして動作を確認できます。マージは、ビルドが良好である場合にのみ確認され、壊れたビルドを回避します。

私たちは、プレフィックス + タスク番号という命名規則に従うようにしています。たとえば、ブランチの名前は task1213、task1209、task1221 です。プレフィックスは「task」で、番号は関連する課題トラッカーの実際のタスク番号を表します。

また、ブランチエクスプローラーが課題トラッカーから番号を取得するので、このスクリーンショットには各ブランチの説明と番号も表示されています。「display branch task info」を選択すると、ブランチの説明も表示されます。

タスクは 16 時間を超えてはいけません。このプラクティスにより、プロジェクトのタイムラインを管理できます。

タスクブランチは素早く閉じる必要があります。わずか数時間で完了できる小さなタスクがたくさんあるのが理想です。この構造により、プロジェクトのリズムを維持し、継続的なデプロイを容易にします。例えば、1 週間にわたる大きなタスクでは、サイクルが停止してしまいます 。

注意すべき危険信号：「鉈切り」のタスクを作成しない。タスクをより細かく分割する必要がある場合は、タスクが独立しても意味があり、独立してデプロイできることを確認してください。

タスクブランチのワークフローは、チーム全体の賛同がなければ成功しません。

他の DevOps プロセスと同様に、このワークフローにも文化的な要素があります。タスクブランチとは、進捗をオープンに伝達し、サイロ化を避けることです。ワークフローやタスクの特定の作業方法を義務付ける前に、調整を進める必要があります。チームメンバーが、大きなタスクに長時間悩むのではなく、小さなタスクを今すぐ終わらせるメリットを理解できるようにします。

自分自身（またはチームメイト）に尋ねてみましょう。タスク 1209 を開始するには、タスク 1213 で終了したコードが本当に必要ですか？

タスクは思ったより独立している傾向があります。はい、同じトピックにあるかもしれませんが、まったく同じコードに触れる必要はありません。新しいものを追加するだけで、マージを信頼して実行できます。

上の例の 1213 と 1209 がタスクではなくバグ修正だったとします。一方がもう一方に依存することは望ましくありません。メインキーを押して、できるだけ早く解放する必要があります。同じコードに触れたとしても、修正は異なります。

すべてのチェックインは、レビュアーがあなたの一連の思考とプロセスに従って、あなたがタスクにどのように対処したかを理解するのに役立つ必要があります。

チェックインのコメントに詳細を残すと、ブランチ全体を差分表示する必要がなくなるため、レビュー担当者に役立ちます。代わりに、変更セットごとに差分を取ります。また、タスクの各段階を明確にするために、事前に記録された説明に従って進めます。100 以上の変更されたファイルの大胆なリストを見ることはありません。その代わりに、段階的に進めていきます。

すべてのタスクブランチは、完了したら統合する準備ができている必要があります。変更が壊れやすい、または製品がぎこちない動作をするようなら、タスクは完了に設定すべきではありません。

これは、自動化のメリットを享受するには小さな価格です。チームは「完成」の定義（「本番環境への準備ができている」という意味）に沿って行動しなければなりません。その代わりに、タスクを実制作への移行は簡単で、完全に自動化されており、午前 2 時に火災訓練が発生することはないため、安心して作業を進めることができます。

機能トグルとは何ですか？これらは、継続的な導入に不可欠です。このソフトウェア開発手法により、機能が完成し、リリース準備が整う前にテストを行うことができます。

機能トグルは、ランタイム中に機能を非表示、有効、または無効にできます。この機能を有効にするのは、開発チーム、少数のアーリーアダプター、またはすべてのユーザーのみです。例えば、開発者はテストのために機能を有効にし、開発中に他のユーザーに対して無効にすることができます。

例を見てみましょう。7 つのパーツに分割された大きな機能がタスクに変換され、タスクブランチを使用して実装されます。パート 4 は他に準備できるものがないにもかかわらず、どのように導入できるのでしょうか。

パート 4 は、機能トグルを使用してメインブランチにマージしたり、非表示のまま展開したりすることもできます。

非表示にしても、新しいコードがリリース前のテストをスキップするわけではありません。機能全体がアクティベートされる準備ができたら、個々のパーツはすでに数回テストされています。最後の部分を統合しても、ビッグバンマージは発生しません。メインの部分にマージされる小さな部分です。