そのプロセスは、課題追跡システムやプロジェクト管理システムのタスクから始まる：Jira、Bugzilla、Mantis、OnTime、または独自の社内ソリューション。ここで重要なのは、すべての行動には関連するタスクが必要だということだ。それが新機能の一部であろうとバグフィックスであろうと関係ない。

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

わかりやすいブランチの命名規則をお勧めします：プレフィックス（例では "task"）の後に、課題追跡のタスク番号を続けます。これは、変更の完全なトレーサビリティを維持するのに役立ちます。

タスクブランチで作業し、必要なだけチェックインを行う。各ステップをコメントで説明し、査読者に分かりやすく伝える。

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

または、課題追跡で完了としてマークすることもできます。すべては、あなたの特定のツールセットと、実際にどのようにワークフローを実装するかに依存します。

タスクに完了マークを付けると、同僚にレビューしてもらうことができます。

今度はレビュアーがあなたの変更点を見て、バグやエラー、コーディングスタイルの矛盾、デザインの変更点などを見つける番です。その場合、タスクは再開され、サイクルが再スタートする。

バリデーションはオプションのステップである。

チームによっては、タスクを「検証」する。別のチームメンバーが短い探索的テストを行い、新しい機能や変更が理にかなっているかどうかを確認するのだ。彼らはバグを探すのではなく（自動テストがその面倒を見る）、顧客の視点から変更点を調べる。ステータスは属性で "validated "に設定できる。

継続的インテグレーション(CI)システムを構成して、所定の属性セットを持つすべてのブランチを監視する。ブランチは、所定のステータス（この場合は「validated」）に達したときにのみ、CIシステムによって考慮される。

タスクがレビュー/検証されると、そのタスクブランチはmainにマージされる前に自動的にテストされる。

テスト・スイートがマージに合格すれば、それが確認され、ビルドとテストのためにCIシステムに提出される。このプロセスは、ビルドの破損を防ぐのに役立つ。失敗した場合、プロセスは再起動され、コンフリクトを解決するためにmainからリベースする必要がある。

テストがパスすれば、マージがチェックインされ、ブランチは納品できる状態になります。ステータスが "マージ "になっていることに注目してほしい。

新しいリリースをデプロイする準備ができたら、main上の新しいチェンジセットにそのようにラベルをつけ、ソフトウェアを本番環境にデプロイする。

新しいタスクがこのサイクルを通過するたびに新しいリリースを出すこともできるし、いくつかのタスクにまとめることもできる。継続的デプロイを実践する場合、すべてのタスクを本番環境にデプロイするのが最も論理的なワークフローだ。

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

このステップは、Unityバージョンコントロールのマージボット機能を使ってオーケストレーションすることもできる。mergebotはブランチをマージし、ビルドをトリガーして動作することを確認することができる。壊れたビルドを避けるため、ビルドが良好である場合にのみマージが確認される。

私たちは以下の命名規則にこだわりたい：接頭辞＋タスク番号。例えば、ブランチはtask1213、task1209、task1221と名付けられるかもしれない。接頭辞は "task "で、数字は関連する課題追跡の実際のタスク番号を表します。

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

スクラムのルールでは、タスクは16時間を超えてはならない。この実践により、プロジェクトのタイムラインはコントロール下に保たれる。

タスクの枝は素早く閉じなければならない。理想を言えば、数時間で終わらせることができる小さな仕事をたくさん抱えておくことだ。この構造は、プロジェクトのリズムを維持し、継続的なデプロイを容易にする。例えば、1週間にわたる大きな仕事は、サイクルを停止させる。

注意すべき赤信号がひとつある：ナタ切り」のタスクを作らないこと。タスクを小分けにする必要がある場合は、そのタスクが単独でも意味があり、独立して展開できることを確認する。

タスク分岐ワークフローは、チーム全体の賛同があって初めて成功する。

他のDevOpsプロセスと同様に、このワークフローには文化的な要素がある。タスクブランチは、進捗状況をオープンに伝え、サイロ化を避けるためのものだ。ワークフローや特定の仕事の進め方を強制する前に、整合性を図る必要がある。チームメンバーには、大きな仕事を長く続けるよりも、大きな仕事の一部を今日中に終わらせることのメリットを理解してもらう。

自分自身（あるいはチームメイト）に問いかける：タスク1209を開始するのに、タスク1213で完成させたコードが本当に必要なのか？

タスクは、あなたが思っているよりもずっと独立している傾向がある。たしかに同じトピックかもしれないが、まったく同じコードに触れる必要はない。単純に新しいものを追加し、マージがその仕事をするのを信じることができる。

上の例の1213と1209がタスクではなくバグフィックスだったとしよう。一方が他方に依存するのは避けたい。メインを打って、できるだけ早くリリースしてほしい。同じコードを触っていたとしても、異なる修正なのだ。

どのチェックインも、レビュアーがあなたの思考回路とプロセスをたどり、あなたがどのようにタスクに取り組んだかを理解できるようにしなければならない。

チェックインのコメント欄に詳細を残しておくと、レビュアーは支店全体を参照する必要がなくなるので便利です。その代わり、チェンジセットごとに差分を取る。そして彼らは、タスクの各段階を明確にするためにあなたが行った事前録音された説明に従うだろう。100以上の変更されたファイルの大胆なリストを見ることはない。その代わり、一歩一歩進んでいく。

どのタスクブランチも、完成したら統合できるようにしておかなければならない。変更が壊れやすかったり、製品の動作がぎこちなくなったりする場合は、そのタスクを完了に設定すべきではない。

自動化のメリットを考えれば、これは安いものだ。チームは "done "の定義、つまり "productionの準備ができた "という意味で一致しなければならない。その代わり、タスクを生産に移すのは簡単で、完全に自動化されており、夜中の2時に消火訓練が行われることもないという安心感を味わうことができる。

フィーチャートグルとは何ですか？これらは継続的なデプロイメントには欠かせない。このソフトウェア開発手法では、完成してリリースする前に機能をテストすることができる。

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

例を見てみよう。大きな機能を7つのパートに分け、それをタスクに変換し、タスクブランチを使って実装する。何も準備できていないのに、どうやってパート4を展開することが可能なのか？

パート4はメインブランチにマージすることができ、フィーチャートグルを使って隠したままデプロイすることもできる。

隠されているからといって、新しいコードがリリース前のテストを省略するわけではない。機能全体を作動させる準備ができたとき、個々の部品はすでに何度もテストされている。最後のピースの統合はビッグバンのマージの引き金にはならない。