Git はソフトウェア開発を簡単にする

Git をアジャイルワークフローに合わせる (またはアジャイルワークフローに Git を合わせる) ための 3 つのヒント

Laura Daly Laura Daly
トピック一覧

アジャイルDevOps の各開発チームにとっては、Git は事実上業界標準のバージョン管理システムです。サポートも十分なこのオープン ソース プロジェクトは柔軟性に富むため、あらゆるソフトウェア チームの要求に沿ったさまざまなワークフローをサポートできます。集中型ではなく分散型であるためパフォーマンス特性が優れており、開発者はローカルでテストを実施したりチームに配布するときにのみ変更を公開したりできる自由を手にします。

柔軟性と配布のメリットだけではありません。Git にはアジャイルと DevOps の各開発チームをサポートして強化する主要な機能があります。Git はアジャイル開発と DevOps 開発のコンポーネントだと考えてください。一体型のリリースと集中型のバージョン管理システムを使用している場合よりもデプロイ パイプラインで変更を迅速に配信できます。Git はアジャイルと DevOps の各チームの働き方 (または理想の働き方) に合わせて機能します。

プロからのヒント:

Git は分散バージョン管理システム (DVCS) です。CVS や Subversion (SVN) リポジトリとは異なり、Git を使用すると開発者はチーム リポジトリの独自のコピーを作成し、主要なコード ベースと並行してホストできます。これらのコピーはフォークと呼ばれ、フォーク上で作業が完了した場合、主要なコード ベースに簡単に変更を反映できます。

Git ブランチング|アトラシアンアジャイルコーチ

ヒント 1: タスクを Git ブランチとして考える

フィーチャーが具体化され、製品ロードマップに追加され、開発チームの準備が整ったら、Git の出番です。しかし、ここで一歩引いてしまうと、アジャイル フィーチャー開発はあっという間に失敗してしまいます。製品、デザイン、品質保証 (QA)、エンジニアリング チームでフィーチャー キックオフ ミーティングを開催し、どのようなフィーチャーを作成するか (要件)、プロジェクトのスコープ、完了するためにフィーチャーを分割して作成すべきタスクは何かについての理解を共有します。ユーザー ストーリーとも呼ばれるこれらのタスクは、その後個々の開発者に割り当てられます。

Git はこの時点で、アジャイル ワークフローに適合し始めます。Atlassian では、すべての課題に対して新しいブランチを作成しています。新しいフィーチャーでも、バグ修正でも、既存コードにおける小さな改良でも、すべてのコード変更に独自のブランチが割り当てられます。

ブランチングはシンプルで、チームは 1 つの中心的なコード ベース内で簡単にコラボレーションできます。開発者がブランチを作成すると、実質的に分離された固有のコード ベースのバージョンができ上がり、それに変更を加えることができます。アジャイル チームにとってこれは、フィーチャーをユーザー ストーリーに、それからブランチに分割することで開発チームが個々にタスクに取り組み、同じコード上でも異なるリポジトリでより効率的に作業できるようになることを意味します。作業の重複はありません。個人が主要なリポジトリからは離れたリポジトリで、小さく分割された作業に集中できるため、開発プロセスの速度を落とすような依存性が減少します。

プロからのヒント:

Git ブランチには、タスク ブランチ以外の種類もあり、相互排他的ではありません。たとえば、リリースのためのブランチも作成できます。これにより開発者は、将来のリリースに向けて作業している他の開発者の進行を妨げることなく、特定のリリースのためにスケジュールされた作業を安定化して強化できます。

リリース ブランチを作成したら、定期的に master ブランチにマージし、機能が将来のリリースに含まれるようにします。オーバーヘッドを最小化するには、スケジュールされたリリース日時に可能な限り近いリリース ブランチを作成します。

Git ブランチの詳細ビュー|アトラシアンアジャイルコーチ

ヒント 2: 個々にテストできる複数のブランチを活用する

ブランチが完了しコード レビューの準備ができたら、Git はアジャイル開発のワークフローにおけるもう 1 つの主要な役割であるテストを行います。成功を収めるアジャイルと DevOps の各チームは、コード レビューを実施して自動化テストを設定しています (継続的インテグレーションまたは継続的なデリバリー)。開発者はコード レビューとテストのために、ブランチ作業のレビューの準備ができたこととプル リクエストを通じてレビューする必要があることを、簡単にチームの他のメンバーに通知できます。プル リクエストをより掻い摘んで説明すると、ブランチの 1 つのテスト準備が整ったので master ブランチにマージしてほしいと他の開発者にリクエストする方法だと言えます。

適切なツールを使用すれば、継続的インテグレーション サーバーを構築してマージする前にプル リクエストをテストできます。そうすることによって、マージが問題を起こさないと確信できます。この確信こそが、一般的にバグ修正や競合の再ターゲットを簡単にします。これは、ブランチが分岐してからのブランチと master コード ベースの違いを Git が把握しているためです。

プロからのヒント:

Master ブランチにマージされていない長期のフィーチャーブランチは、アジャイルおよび反復性であるという機能の妨げとなります。長期のフィーチャーブランチがある場合、2 つの異なるバージョンのコードベースを存在させることは可能です。しかし、より多くのバグ修正や競合が発生することを忘れないでください。最適な解決策は、短期のフィーチャーブランチを持つことです。これは、ユーザーストーリーをより小さなタスクに分割すること、慎重なスプリント計画、コードをダークフィーチャーとして早めに出荷することで達成可能です。

ヒント 3: Git はアジャイル開発に透明性と品質を提供する

Git やアジャイルのストーリーは、効率性、テスト、自動化、全体的なアジリティに関するものです。ブランチを master ブランチにマージすれば、アジャイル ワークフローは完了です。また、プル リクエストを通じてコードをマージするということは、コードが完了したときに、作業に問題がなく、他のチーム メンバーもコードを終了しリリースの準備ができていると自信を持って把握するための文書があるということです。これが、アジャイル チームをスピーディーに動かし、頻繁にリリースする自信につながります。優れたアジャイル チームのサインです。

プロからのヒント:

アジャイル開発にとっては、定期的なリリースサイクルを採用することが重要です。アジャイルワークフローで Git を動かすには、master が常にゴーサインであることを確認する必要があります。つまり、フィーチャーの準備が整っていなければ次のリリースまで待たなければなりません。より短いリリースサイクルを採用している場合、これは大きな問題にはならないはずです。

次の記事
Branching