アジャイル ソフトウェアと DevOps ソフトウェアの開発チームにとっては、Git は事実上業界標準のバージョン管理システムであり、DevOps ツールチェーンに不可欠な部分です。サポートも十分なこのオープン ソース プロジェクトは柔軟性に富むため、あらゆるソフトウェア チームの要求に沿ったさまざまなワークフローをサポートできます。集中型ではなく分散型であるためパフォーマンス特性が優れており、開発者はローカルでテストを実施したりチームに配布するときにのみ変更を公開したりできる自由を手にします。
柔軟性と配布のメリットだけではありません。Git にはアジャイルと DevOps の各開発チームをサポートして強化する主要な機能があります。Git はアジャイル開発と DevOps 開発のコンポーネントだと考えてください。一体型のリリースと集中型のバージョン管理システムを使用している場合よりもデプロイ パイプラインで変更を迅速に配信できます。Git はアジャイルと DevOps の各チームの働き方 (または理想の働き方) に合わせて機能します。
ヒント 1: タスクを Git ブランチとして考える
フィーチャーが具体化され、製品ロードマップに追加され、開発チームの準備が整ったら、Git の出番です。しかし、ここで一歩引いてしまうと、アジャイル フィーチャー開発はあっという間に失敗してしまいます。製品、デザイン、品質保証 (QA)、エンジニアリング チームでフィーチャー キックオフ ミーティングを開催し、どのようなフィーチャーを作成するか (要件)、プロジェクトのスコープ、完了するためにフィーチャーを分割して作成すべきタスクは何かについての理解を共有します。ユーザー ストーリーとも呼ばれるこれらのタスクは、その後個々の開発者に割り当てられます。
Git はこの時点で、アジャイル ワークフローに適合し始めます。Atlassian では、すべての課題に対して新しいブランチを作成しています。新しいフィーチャーでも、バグ修正でも、既存コードにおける小さな改良でも、すべてのコード変更に独自のブランチが割り当てられます。
ブランチングはシンプルで、チームは 1 つの中心的なコード ベース内で簡単にコラボレーションできます。開発者がブランチを作成すると、実質的に分離された固有のコード ベースのバージョンができ上がり、それに変更を加えることができます。アジャイル チームにとってこれは、フィーチャーをユーザー ストーリーに、それからブランチに分割することで開発チームが個々にタスクに取り組み、同じコード上でも異なるリポジトリでより効率的に作業できるようになることを意味します。作業の重複はありません。個人が主要なリポジトリからは離れたリポジトリで、小さく分割された作業に集中できるため、開発プロセスの速度を落とすような依存性が減少します。
Git ブランチには、タスク ブランチ以外の種類もあり、相互排他的ではありません。たとえば、リリースのためのブランチも作成できます。これにより開発者は、将来のリリースに向けて作業している他の開発者の進行を妨げることなく、特定のリリースのためにスケジュールされた作業を安定化して強化できます。
リリース ブランチを作成したら、定期的にメイン ブランチにマージして機能が将来のリリースに含まれるようにします。オーバーヘッドを最小化するには、スケジュールされたリリース日時に可能な限り近いリリース ブランチを作成します。
ヒント 2: 個々にテストできる複数のブランチを活用する
ブランチが完了してコード レビューの準備ができたら、Git はアジャイル開発のワークフローにおけるもう 1 つの主要な役割であるテストを行います。成功を収めるアジャイル チームと DevOps チームは、コード レビューを実施して自動化テストを設定します (継続的なインテグレーションまたは継続的なデリバリー)。開発者はコード レビューとテストのために、ブランチ作業のレビューの準備ができたこととプル リクエストを通じてレビューする必要があることを、簡単にチームの他のメンバーに通知できます。プル リクエストをさらに掻い摘んで説明すると、ブランチの 1 つのテスト準備が整ったのでメイン ブランチにマージしてほしいと他の開発者にリクエストする方法だと言えます。
適切なツールを使用すれば、継続的なインテグレーション サーバーを構築してマージする前にプル リクエストをテストできます。それによって、マージが問題を起こさないと確信できます。この確信こそが、一般的にバグ修正や競合の再ターゲットを簡単にします。これは、ブランチが分岐してからのブランチとメイン コード ベースの違いを Git が把握しているためです。
メイン ブランチにマージされていない長期のフィーチャー ブランチは、アジャイルと反復性であるという機能の妨げとなる可能性があります。長期のフィーチャー ブランチがある場合は、2 つの異なるバージョンのコード ベースを存在させられますが、さらに多くのバグ修正や競合が発生することを忘れないでください。最適な解決策は、短期のフィーチャー ブランチを持つことです。これは、ユーザー ストーリーをさらに小さなタスクに分割すること、慎重なスプリント計画、ダーク フィーチャーとして早めに出荷するためのコードのマージによって達成できます。
ヒント 3: Git はアジャイル開発に透明性と品質を提供する
Git やアジャイルのストーリーは、効率性、テスト、自動化、全体的なアジリティに関するものです。ブランチをメイン ブランチにマージすれば、アジャイル ワークフローは完了です。また、プル リクエストを通じてコードをマージするということは、コードが完了したときに、作業に問題がなく、他のチーム メンバーもコードを終了してリリースの準備ができていると自信を持って把握するための文書があるということです。これが、アジャイル チームをスピーディーに動かして、頻繁にリリースする自信に繋がります。そう、優れたアジャイル チームの印です。
アジャイル開発にとっては、定期的なリリース サイクルを採用することが重要です。アジャイル ワークフローで Git を動かすには、メインが常にゴーサインであることを確認する必要があります。つまり、フィーチャーの準備が整っていなければ次のリリースまで待たなければなりません。より短いリリース サイクルを採用している場合、これは大きな問題にはならないはずです。
