フィーチャー ブランチと Bamboo を活用した継続的な統合での成功

ブランチによってリリースのスピードが上がりますが、それには秘密があります。

Sepideh Setayeshfar Sepideh Setayeshfar

開発者には、メイン コード行をクリーンに保ったまま変更やテストを実行する自由が必要であることは明らかです。魔法の要素であるブランチを使うと、コードの一部を別個かつ並列で修正、開発、テストできるようになります。

GitMercurial のおかげで、大量のブランチは難解な次元から実用可能な次元になりました。詳細については、「継続的な統合フレンドリーな Git リポジトリに役立つ 5 つのヒント」を参照してください。すべてのメリットを加味しても、継続的なデリバリー パイプラインでブランチを使用すると異なる 2 つの問題が発生する可能性があります。

製品要件

ビルド構成の重複と誤差

  • 開発者がブランチを作成するとき、CI サーバー上のビルド構成の一部を手動でクローンする必要があります。手動ステップであって一部の開発者は気にしないため、機能開発時にテストが実施されません。フィーチャー ブランチの CI 構成をコピーする場合でも、ほとんど微調整しないことがよくあります。次のフィーチャー ブランチ用に微調整された構成をクローンしてさらに細かく微調整すると、最終的にビルド構成は元の構成から離れて管理上の問題を引き起こします (ブランチが main にマージして戻されると問題が起きます)。

統合状態の不確定性

  • メイン ライン (これを main と呼びます) からの変更をブランチに常にマージしてテストを実行しない限り、少なくともブランチがメイン ラインにマージされるまでは変更が機能するかどうかについては常に不確定性が付き纏います。当然、変更は期待どおりに機能せず、main は壊れたコードに巻き込まれて汚染され、フィーチャー ブランチと CI のポイント全体が破壊されます!

Bamboo は、プランブランチと呼ばれる機能でこれら両方の課題に対処し、問題を解決しました。詳細についてはこちらで説明します。続きを読む

フィーチャー ブランチのプラン ブランチ

プラン ブランチは、リポジトリ内のブランチに対応する Bamboo のビルド プランの要素です。main に対してではなくブランチに対してビルドすること以外は、親プランによって定義されたすべての構成を継承します。その後、ブランチ ビルドが成功すると、変更をブランチから main に自動でマージできます。また、Bamboo のデプロイ機能を使用して、成功したブランチ ビルドをテスト環境にデプロイできます (詳細については、別の記事を参照してください)。

下のスクリーンショットからわかるとおり、「CI テスト」と呼ばれる当社のプランでは、main だけでなく統合ブランチと単一の Jira 課題専用のいくつかのブランチ (BDEV-10045-bump-tomcat-plugin-5-1 など) もビルドします。Bamboo を使用することで、ブランチ記号を表示してブランチがあるプランを簡単に見つけられるようになります。

Bamboo ビルド ダッシュボード プラン ブランチのスクリーンショット

既存のプランにこれを設定するには、以下を実行します。

  • そのプランの管理者権限を持つユーザーとしてログインします。
  • Bamboo のダッシュボードにある鉛筆アイコンをクリックするかビルド結果画面のアクションメニューを使用して、設定画面に移動します。
  • 設定画面でブランチ タブをクリックします。

ここから、Bamboo がリポジトリ内の新しいブランチを自動で検出するように設定して、対応するプラン ブランチを作成できます。現在、自動ブランチ検出は、Git、Mercurial、Subversion の各リポジトリでのみ利用可能です。ただし、TFS や Perforce などの別のバージョン管理システムを使用している場合でも、プラン ブランチを手動で作成できます。

ヒント: 必要なブランチをすべて手動でビルドする必要はありません。たとえば、テストするすべてのブランチが「feature-*」で始まる命名規則を使用している場合、Bamboo はその接頭辞に一致するプラン ブランチのみを作成するように設定できます (これらの設定では正規表現も使用できます)。

Bamboo 構成ブランチ管理のスクリーンショット

ほとんどのフィーチャー ブランチは短期間 (最長でも 3 ~ 4 日間) であるため、一定日数使用されなかった場合にブランチとビルドの結果を Bamboo から削除するようにプランを設定できます。先のステップで手動で削除する必要があるために無期限にする場合は、ブランチごとに自動削除を無効にできます。安心してください。プラン ブランチを自動で削除しても手動で削除しても、Bamboo はブランチ自体をリポジトリからは削除しません。リポジトリから削除するかどうかはあなた次第です。したがって、いくつかのブランチで自動クリーンアップを無効にすることは、プロジェクトの期間が長く「安定した」ブランチを維持する可能性がある状況では良いアイデアです。

すべてのブランチを簡単にビルドする

Git の使用を強くお勧めしますが、Bamboo がサポートするバージョン管理システムのプラン ブランチを作成できます。プラン ブランチを手動で作成するには、以下を実行します。

  • プランのビルド結果画面に移動して、[アクション] メニューから [プランの設定] を選択します。
  • [ブランチ] タブ、[ブランチの作成] ボタンの順にクリックします。
  • Git および Mercurial の場合、リポジトリにある、まだ Bamboo 内に対応するプランブランチのないすべての利用可能なブランチが記載されたダイアログが表示されます。
  • ブランチを選択して [作成] をクリックします。
  • 集中型の VCS リポジトリのユーザーは、[作成] ボタンを押す前に、名前、説明、使用するブランチ (Subversion の場合はブランチの URL) を選択するよう求められます。
プラン ブランチ作成のスクリーンショット

必要に応じて、現在のプラン ブランチの自動クリーンアップを無効にできます。DVCS リポジトリの場合はマージ戦略を構成できます。マージ戦略を使用すると、Bamboo はビルドが成功したときにブランチ間でコードを自動でマージできます (詳細は後述します)。この時点で、リポジトリ情報 (Subversion でプラン ブランチを使用している場合は、SVN URL をトランクからブランチに変更できます) やビルド変数をオーバーライドできます。たとえば、プラン ブランチに対して変更する可能性がある本番環境にデプロイするかどうかを指定する変数がある場合があります。

Bamboo 構成ブランチ構成のスクリーンショット

親プラン ビルドとプラン ブランチ ビルドのビルド ステップはまったく同じ機能であるため、トリガーや通知などの構成は親プランから継承されます。ただし、これらの設定 (とその他) は、各プラン ブランチの構成でブランチごとにオーバーライドできます。

ブランチを自動的にマージする

main に変更をマージするまではすべてが機能するかどうかはわからないので、Bamboo では DVCS リポジトリで自動で行う方法が 2 つ用意されています。これらのオプションを「ブランチ アップデーター」と「ゲートキーパー」と呼びます。どのプラン ブランチでもどちらの方法も使用できます。ビルドが実行される前に、ブランチ アップデーターを使用している場合は Bamboo は main からブランチに最新のものを、ゲートキーパーを使用している場合は main を確認してブランチから変更を、それぞれマージします (詳細については、Bamboo ドキュメントのマージ モデルの選択を参照してください)。その後、Bamboo がビルドを実行します。

ブランチのマージのスクリーンショット

ビルドが成功して成功時にプッシュ オプションを有効にした場合は、マージは自動でコミットされてリポジトリにプッシュされます。ゲートキーパー モデルを使用している場合は、ブランチの変更が main にプッシュされることを意味します。ブランチ アップデーター モードを使用している場合、フィーチャー ブランチは main 上で変更が行われた状態で最新の状態になります。

Bamboo ビルド結果統合の詳細のスクリーンショット

これが最新の継続的なインテグレーションです!

前述のとおり、プラン ブランチはデプロイ プロジェクトと関連付けられて、継続的なデリバリー サイクルのそのフェーズの一部にできます。詳細については、関連記事を参照してください。