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

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

Laura Daly Laura Daly
トピック一覧

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

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

プロからのヒント:

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

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

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

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

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

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

プロからのヒント:

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

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

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

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

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

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

プロからのヒント:

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

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

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

プロからのヒント:

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

次の記事
Branching