継続的デリバリーのパイプラインでブランチベースのデプロイを使用する

私たちが困惑せざるを得ない質問の 1 つは、どこへの継続的なデリバリーですか?そして、さらに言えばどこからでしょうか?

Sarah Goff-Dupont Sarah Goff-Dupont

リポジトリからユーザーへのコードの継続的な流れを説明するために、「パイプライン」などの用語をよく使用します。しかし、紙にマッピングしてみると、特にブランチとマージのワークフローを使用している場合 (強く推奨します)、そのパイプラインはネットワークのように見えます。

ブランチで開発している場合は、そのブランチに独自のデプロイ パスを設定して、main にマージする前に変更を徹底的にテストしたり、顧客に直接リリースしたりできるようにすることが重要です。おわかりのように、Atlassian 開発ツールのサポート ブランチは非常にうまくデプロイされます。

まず、3 つの主要なユース ケースを取り上げてから、実践的な Jira Software、Bitbucket、Bamboo 間の統合について説明します。

ブランチベースのデプロイの場合

本質的に、ブランチのネットワークを継続的なデリバリー パイプラインに統合する場合は便利です。テスト環境を他のチームメイトと共有する場合は、テストにデプロイする前にすべてのストリームをマージして、さらに変更が (必然的に) 必要になったときにそれらのストリームを整理する必要があるよりも、個々の作業ストリームを表すデプロイの期間を調整する方が簡単です。

運良く複数のテスト環境を利用できるなら、さらに簡単です。顧客へのリリースでも同様に、一部のチームはブランチから直接リリースして、その後、ブランチから main に更新をマージすることを好みます。

フィーチャー ブランチからのデプロイの自動トリガー

ユーザー ストーリーとバグ修正にフィーチャー ブランチを使用することは、作業の進行中にチームの他のメンバーが失敗したビルドとテストの失敗に晒されることなく、Bitbucket のリポジトリに変更をプッシュする (したがって、CI が変更に対して実行できるようにする) ための優れた方法です。

チームが main からリリースすることを好む場合は、探索的な受け入れテストのために、そのコードを内部環境にデプロイすることになります。これはチームがデプロイできるテスト環境がほんのわずかである場合に最適であるため、単一の共有環境を使用する順番を待つ必要はありません。

Bamboo でのブランチ デプロイでは、任意の環境のデプロイ トリガーを設定して、スケジュールされた間隔で、またはそのブランチの CI ビルドが成功するたびに、特定のブランチ上に構築されたアーティファクトを自動的にデプロイできます。2 つのトリガー タイプを組み合わせて使用することさえ可能です。

テスト環境のスクリーンショット

全員が共有する単一のパフォーマンス テスト環境があるとします。1 日を通じて、main が正常に構築されるたびにそこに main をデプロイします。ブランチを本当に気に入っているほとんどのチームにとって、main の構築は通常、新しい作業がマージされた結果であるため、すぐにパフォーマンスをチェックする必要があります。

その後、リポジトリがアイドル状態の夜間に、各開発者のブランチから適切な間隔でデプロイをスケジュールすることで、全員が少なくとも 1 日に 1 回は作業に関するパフォーマンス フィードバックを取得するようにします (Bamboo のデプロイ ジョブは、パフォーマンス テストをキックオフするスクリプト、Ant、または Maven タスクで終了できます)。開発者はその間、フィーチャー ブランチが正常に構築されるたびに、自動デプロイ トリガーを使用してビルドを個々のテスト環境に送信できます。

これをすべて設定するために、開発ブランチ用に Bamboo で個別のデプロイ プロジェクトを作成するか、環境へのデプロイのトリガー方法をカスタマイズして、ブランチをデプロイ プロジェクト内の環境に関連付けられます。

デプロイ プロジェクトの作成のスクリーンショット

デプロイ プロジェクトとブランチの関連付けデプロイ トリガーのカスタマイズのステップバイステップの手順については、Bamboo のドキュメントを確認してください。

リリース ブランチからのリリース

メインのコード行で直接作業を進行させることを好むチームにとっては、ブランチからのリリースがより魅力的です。main またはトランクがテスト環境にデプロイされる間、リリース ブランチはステージング、最終的には本番環境にデプロイするブランチです。リリース ブランチは Gitflow アプローチの一部としても使用できます。

Gitflow のスクリーンショット

リリース ブランチは定期的にカットされて、変更はそこからリリースされます。また、ほとんどのチームは自動化されたトリガーではなく、リリース ブランチをいつどこにデプロイするかについて判断したいと考えています。問題ありません。

Bamboo には、この「リリース」の概念があります。これは、特定のブランチから構築された最新のアーティファクトに加えて、前回リリースが作成されてからそのブランチのすべてのビルドに関連するすべてのコミット、テスト結果、Jira 課題をカプセル化する、Bamboo 内のエンティティです。したがって内部では、リリースは基本的にパッケージ化されたアーティファクトと大量のメタデータです。

それらの豊かなデータがアーティファクトとともに継続的なデリバリー パイプラインを流れることで、最初のコミットやすべての始まりであるユーザー ストーリーまでのトレース バックが可能になることが求められます(「すべての道は Jira Software に通ず」と最初に言ったのは Geoffrey Chaucer でしたでしょうか)。つまり概念的には、環境を通じて推進しているのはリリースであり、ビルドだけではありません。これは Bamboo の UI にも反映されます。

Bamboo 環境のステージング リリースのスクリーンショット

さて、トリガーに戻りましょう。上記の場合のように、デプロイが自動的にトリガーされると、Bamboo は自動的にリリースを作成します。

しかし、プッシュ ボタンのデプロイは異なります。この場合、リリースを作成して (ビルド結果画面やデプロイ プロジェクト内から実行できます) 名前を付け、そこからアーティファクトをプルするビルドを選択します。このリリースが手元にあると、あらゆる環境にデプロイできます。本番環境へのデプロイが本当に必要であれば、本番環境にもデプロイできます。このアプローチを使用するチームは通常、複数のリリース (実際にはリリース候補) を作成してから、最終的に 1 つのリリースに承認のスタンプを与えて、パイプラインを介してさらにそれを送信します。

リリースを次の環境にプロモートするときは、[all deployment projects (すべてのデプロイ プロジェクト)] 画面に移動します。この画面には、すべてのデプロイ プロジェクト (今更ですが) と各プロジェクトに関連付けられているすべての環境が表示されます。ターゲット環境の横にあるデプロイ アイコンをクリックして、デプロイ プレビュー ウィザードの指示に従って、既存のリリースをデプロイするオプションを選択します (詳細はリンクで参照)。

アップデートをサポート対象バージョンにリリースする

SaaS の世界に住んでいない場合は、おそらくソフトウェアの複数のバージョンを同時にサポートする必要があります。さらに、重要な修正やバックポートのセキュリティ アップデートなどをリリースすることがあります。これは、安定したバージョンのブランチを非常に長い間 (多くの場合、数年間) 維持することを意味します。これらのブランチからのビルドは通常、Web サイトや外部リポジトリなどの共通の場所にデプロイされます。そこでは、顧客は使用しているバージョンへのアップデートをプルできます。

複数バージョンのワークフローのスクリーンショット

これらのブランチの場合、ビルドをリリースに変換する最も簡単な方法は、リリースしているビルドのビルド結果画面にある [リリースを作成] ボタンを使用することです。もちろん、上記のようにすべてのデプロイ プロジェクト画面から開始できます。ただし、リリースする特定のビルドに焦点を合わせているため、これは必ずしもそのブランチの最新のビルドではありません。ビルド結果画面から開始することで、これがリリースするビルドであるという多少の保証が得られると思います。

すべてをまとめる (一度に 1 つの継続的なデリバリー パイプライン)

ブランチベースのデプロイは Bamboo のプラン ブランチの自然な拡張であり、さらに Bitbucket でチーム用に設定したブランチ スキームの自然な拡張です。ここに示し、さらに他の記事で詳細に検討しているように、

CD フレンドリーなモデルをいくつか選択できます。

ブランチ スキームでは、チームがどのように作業に取り込んで作業を提供するかを反映する必要があります。

それでは、ここで説明されているさまざまな部分を確認しましょう。

  • Jira 課題課題キーは魔法であることを覚えておいてください。ブランチとコミット メッセージの名前に課題キーを含めることで、すべてのコミット、ビルド、デプロイ (プル リクエストさえも) が課題にリンクするようにします。
  • ブランチ – Bitbucket を Jira Software に接続すると、各課題に便利なブランチを作成リンクが用意されることを知っていましたか?そして、そのリンクを使用すると、課題キーが自動的にブランチの名前に追加されることも? このように、取り組んでいる課題ごとにブランチを作成することを私たちは強く信じています。面白半分でいいので、次のスプリントで試してみてください。
  • プラン ブランチ自動ブランチ管理を有効にすると、Bamboo は Git、Mercurial、Subversion の各リポジトリの新しいブランチを自動的に検出します。最初のコミットを行うまでに、Bamboo はすでにそのブランチをテストに配置しています。
  • デプロイ プロジェクト – 継続的なデリバリー パイプラインの「デリバリー」フェーズ。リポジトリと 1 つ以上の環境を、各デプロイ プロジェクトに関連付けます。
  • 環境 — Bamboo の場合は、ネットワーク上の環境を表したものです。各環境はさまざまなブランチに関連付けられてさまざまなデプロイ トリガーを使用し、さまざまなステップ (タスクと呼ばれる) を使用してデプロイを正常に実行できます。
  • リリース – パッケージ化されたアーティファクト + メタデータ。Bamboo で特定のリリースを見ると、すべての Jira 課題 (課題キーは魔法であるため)、コミット、テスト結果、それに関連付けられたアーティファクトを確認できます。デプロイされている環境を確認して、パイプラインを通じてプロモーションに承認または拒否のフラグを設定することすらできます。

こちらで紹介したすべてのユースケースは、アトラシアン内の少なくとも 1 つの開発チームで使用されています。一部のチームではさらにこれらを組み合わせて使用しています。また事実として、1 つの継続的デリバリーのパイプライン (または何もないところ) からブランチベースのパイプラインに移行するのは予想以上に時間がかかります。さらに現在のプロセスで最適となっていないいくつかの側面に気づけば、それにも対処しなければなりません。

しかし、特に問題はありません。始めるだけです。ご感想をお待ちしています。@Atlassian でツイートするか、Atlassian ブログをフォローして、さらにアジャイル、Git、開発ツールの良さをご覧ください。