課題ごとのブランチモデルでの継続的デリバリーワークフロー

大量のブランチングと継続的デリバリーによってもたらされるものは? Saas にお任せください。

Sarah Goff-Dupont Sarah Goff-Dupont

Git による非常に強力で継続的なデリバリー」で詳述したとおり、継続的なデリバリー ワークフローではブランチを最大限に活用することをお勧めします。それによって最も重要なブランチをクリーンでリリース可能な状態に保つことで、開発者はチームメイトの邪魔をせずに新しいことを試せるだけではなく、ともすればプロジェクトの追跡もより簡単になります。

当社や多くのお客様は、課題ごとのブランチ ワークフローを数年にわたって利用してきました。そのサポートを Jira Software と Atlassian の各開発ツールに導入したことで、単にベスト プラクティスであるだけでなく容易なプラクティスにもなりました。そこで、課題ごとのブランチ モデル、3 つの最も一般的な継続的なデリバリー ワークフロー (SaaS 製品、インストール製品、モバイル製品) にどのように適合するか、(いずれの製品タイプにも対応できる) Gitflow についても詳しく説明します。

基本的な課題ごとのブランチ ワークフロー

まさに、その名の示すとおりです。作業する各課題 (または Jira Software で追跡する必要がある各コード変更) ごとに開発ブランチを作成します。そのブランチで、すべての実装とテスト作業を実施します。完了したら、プル リクエストを送信してマージ アップし、準備ができ次第リリースします。

基本的なワークフローのスクリーンショット | Atlassian CI/CD

Atlassian ツールを使用した段階的な手順を説明します。

ステップ 0: ツールの統合を設定する

馴染みの Atlassian 管理者と協力して、Jira Software、Bitbucket、Bamboo を統合します。Cloud と Server の各オプションを組み合わせられます。たとえば、Atlassian ではいくつかのチームが Jira Software Server、Bamboo Server、Bitbucket Cloud を使用しています。コマンド ラインではなく GUI で Git を使用する人には、SourceTree をお勧めします。無料なので是非お試しください。インストールしたら、SourceTree をリポジトリに接続します

また、作業を追跡する課題の作成、リポジトリの設定、ビルドとデプロイ ジョブの設定など、その他の明らかに必要な作業を行う必要があります。

ステップ 1: ブランチを作成する

課題を Jira Software で開いて自分に割り当て、進行中に設定することで、チームは何が起きているかを把握できます。右側にある開発パネルで、その横にあるブランチ作成リンクをクリックします。複数のリポジトリ マネージャーが接続されている場合は、ブランチを管理するリポジトリ マネージャーを選択するように求める画面が表示されます。それ以外の場合は、ブランチを設定する次の画面に直接移動します。

ブランチ ワークフロー作成のスクリーンショット | Atlassian CI/CD

Bitbucket がどのように課題キー (この場合は MKT-15886) をピックアップしてブランチ名の一部として使用しているかに注目してください。これによって、コミット、ビルド、プル リクエスト、デプロイ情報を開発パネルに送信するなど、魔法のような運用が可能になります。課題キーは、さまざまな便利なリンクと自動化を継続的なデリバリー ワークフロー全体でトリガーします。そのため、UI または cmd のどちらを使用して作業しているかに関わらず、ブランチ名には必ずそのキーを含めるようにしてください。

また、ドロップダウンリストではブランチの種類 (バグ修正、機能、リリースなど) に基づいたプレフィックスや、新しいブランチの作成元となる親ブランチまたはタグを選択できます。選択するブランチが Bamboo で構築およびテストされると仮定して、現時点でブランチがクリーンであるかを示すインジケーターが表示されます。こちらは必ず確認してください。最後に必要なものは、すでに何らかの形で壊れている新しいブランチです。

すべてをあなたの好みに合わせて設定できたら、ブランチ作成をクリックします。後は、Bitbucket にお任せください。

ステップ 2: コード、テスト、繰り返し

この部分はよくご存じでしょう。まだローカルにリポジトリのクローンを作成していなければ作成し、新しいブランチを確認してコーディングを開始します。新しいブランチに初めてプッシュするまでに、Bamboo はすでにリポジトリ内で検出して、ブランチ計画機能を使用して継続的なインテグレーションを構成しています (自動ブランチ管理が有効になっていると仮定します)。基本的に、Bamboo はリポジトリ内の新しいブランチをリッスンして、main 用に構成したすべてのビルドを適用します。

また、Bamboo による自動マージを有効にすることをお勧めします。各ビルドの開始時に、Bamboo は任意の 2 つのブランチを確認してそれらをマージします。その後、マージされたコードに対してビルドを実行します。継続的なデリバリー ワークフローのこの段階では、変更を main からフィーチャー ブランチにマージします。このようにするとブランチは main から大きく離れないため、変更が main の変更でうまく機能するかどうかについて早い段階でフィードバックが得られます。

ブランチ アップデーターのスクリーンショット | Atlassian CI/CD

自動マージが不要な場合は、main をブランチにマージ (またはリベース) してビルドを送信し、問題がないかを確認します。問題があれば修正します。実装が完了してすべてのテストに合格したら、次のステップに進めます。

ステップ 3: マージ アップ

チームの一員として、プル リクエストを実行せずに main (またはその他の重要なブランチ) に突撃してマージしてはいけません。プル リクエストはこの世界で失敗することのない唯一のコード レビューの形態です。

SourceTree を使用するかコマンド ラインからプル リクエストを作成できますが、Bitbucket UI を使用するいくつかのメリットがあります。まず、ターゲット ブランチとの差分を確認できます。差分を視認することで、すぐに取り組むべきものがいくつか見つかることはよくあります。次に、ブランチ比較画面からプル リクエスト作成ボタンを押してレビュアーを選択し、完了です。

Bitbucket ワークフロー プル リクエストのスクリーンショット | Atlassian CI/CD

Bitbucket は正直なところ、プルリクエストに関してはかなり優秀です。横並び差分やインラインコメントのような通常の機能の他に、ルールの設定もできます。アトラシアンのある開発チームでは、プルリクエストは少なくとも 2 人が承認した後でないとマージできないというルールを設定しています。他のチームはある種のゲートキーパーを指名し、ゲートキーパーのみがマージを実行できるようなターゲットブランチの権限を設定しています。また、そのブランチに対して失敗したビルドがある場合はプルリクエストをマージしないというルールをすべてのチームが適用する必要があります。

ヒント: main とあなたがリリースしたブランチについては、プッシュするたびにすぐにビルドしたいと思うでしょう。積極的なポーリング スケジュールまたは Bitbucket からのプッシュ通知を使用して、Bamboo で自動ビルド トリガーを設定します。

ステップ 4: 最適な方法でリリースする

(他に Devo ファンはいますか?「新しいコードが来たら、それをリリースする必要があります」いませんか? その気にさせてみますよ!)

Bamboo ワークフロー デプロイ ビルドのスクリーンショット | Atlassian CI/CD

ビルドがリリース ブランチで緑色になると、リリースする準備ができている可能性があります。「可能性があります」と言ったのは、実際にそれをすぐリリースするかどうかはチームの判断次第だからです (すべての承認基準を満たしていますか? アーティファクトの負荷テストは十分ですか?)。

Bamboo を使用することで、ビルドをステージングに自動でも、(徹底した継続的なデプロイの場合は) 本番環境に直接でもデプロイできます。ただし、これから説明するように、すべてのチームとすべての製品に適しているわけではありません。

次のいくつかのセクションでは、ステップ 1 ~ 4 をもう一度確認して、基本的な課題ごとのブランチ ワークフローで説明されている内容との違い (がある場合) について説明します。

SaaS 製品の継続的なデリバリー ワークフロー

作業するブランチとその間でどのようにコードが移動するかに関しては、SaaS ワークフローは基本的なワークフローと同じです。

SaaS ワークフローのスクリーンショット | Atlassian CI/CD

ステップ 1: ブランチを作成する

ここで注意すべき点は、SaaS チームは一般的に main からフィーチャー ブランチを作成することのみです。

ステップ 2: コード、テスト、繰り返し

SaaS チームは多くの場合、可能な限り継続的なデプロイに近づいて、それに適した製品に取り組む余裕を持っています。これを実行可能にするためには、プル リクエスト ステップの後まで待たずに、このステップの一部としてテスト環境またはステージング環境へのデプロイを自動化する必要があります。

幸いなことに、軽量環境は Puppet、Chef、Docker、Vagrant などの技術によって、組み立ても分解もあっという間に簡単にできるようになっています。(この点については、機会があれば別の記事で詳しく説明したいと思います) また、Bamboo はあらゆるブランチからの自動デプロイをサポートしています。そのため、一時的な環境と永続的な環境のどちらで作業しているかにかかわらず、ブランチの成功したビルドを、自動化された UI や負荷テストで検証できる環境にデプロイするように設定できます。

このビルド プランに関連付けられたデプロイ プロジェクトが Bambo で作成済みであるとします。デプロイする環境の Bamboo の設定をプル (または作成) して、成功した各ブランド ビルドを自動でデプロイするトリガーを作成します。

テスト環境のスクリーンショット | Atlassian CI/CD

チームに継続的デプロイを行う意思がなく、人間がリリース時期を決定することを望んでいるとしても、成功したブランチビルドを環境にデプロイするのはよい考えです。このことにより、自分やチームメイトはマージする前に探索的テストを実施する機会が与えられます。

ステップ 3: マージ アップ

チームが使用する本番前環境の数は、このステップに移行する厳密なポイントに影響します。通常、開発者は各ビルドを使用してブランチでインプロセス テストを実行します。合格した場合は、UI テスト、負荷テスト、さらに探索的テストのためにテスト環境にデプロイします。すべてがテスト時にリリースできる状態になったら、プル リクエストを作成してリリース元のブランチ (通常は main) にマージ アップします。

ステップ 4: リリースする

これで元の場所に戻ってきました。main にマージ アップし直して、検証テストが行われます。また、ここでは、さまざまなチームのアプローチに多様性が見られます。

main のビルドが成功するたびに自動デプロイをトリガーするチームもあれば (この場合、機能フラグは不可欠です)、重要な変更が main に反映されるまで待ってからリリースをタグ付けし、デプロイをトリガーするチームもあります。同様に、本番環境に直接デプロイするチームもあれば、本番環境に移行する前に健全性チェック テストの最終ラウンドのためにステージング環境にビルドをプロモートするチームもあります。

main から顧客にコードを提供する方法に「絶対的な正解」はありません。可能な限り自動化していれば、正しい方向に向かっています。

インストール済み製品の継続的なデリバリー ワークフロー

基本的な課題ごとのブランチ ワークフローとの主な違いは、現在サポートしている各バージョンを収容する長寿命のブランチが存在することです。Atlassian のようなエンタープライズ B2B 製品では、おそらくそのようなブランチが 6 個 (またはそれ以上) はあるでしょう。モバイル アプリの場合は、わずか 2 つ 3 つ (またはそれ以下) かもしれません。

複数バージョン ワークフローのスクリーンショット | Atlassian CI/CD

ステップ 1: ブランチを作成する

どこからブランチを作成するかは、どのような種類の変更を行うかによります。先週リリースしたばかりの製品のバグ修正でしょうか? または、次のリリース用の新しい機能でしょうか?

後者の場合は、main から分岐します。前者の場合は、変更対象の最も古いバージョン (バグが現れた最初のバージョンなど) 用のブランチから分岐したブランチをベースにします。

ステップ 2: コード、テスト、繰り返し

SaaS 製品については、すべてのインプロセステストを実行した段階で成功したビルドをブランチからテスト環境にデプロイすることをお勧めします。ただし、お勧めする理由は多少異なります。

バグ修正を使用したバージョンのアップデートはチームと顧客にとって、SaaS 製品よりもインストール済みの製品において遥かに大きな問題になります。つまり、バグの発見となるとリスクがより高くなるのです。

そのため、このワークフローでは、UI、負荷、さらに探索的テストのためのテスト環境へのデプロイは、「実質的には必須である」と考えるべきです。その点については、メリットを考えると探索的テストも必須であると言えます。余談ですが。

ステップ 3: マージする (マージアップ/マージダウン)

面白くなるのはここからです。

今後のリリースで何かに取り組んでいる場合は、基本的なワークフローと同様に、プル リクエストを行ってブランチを main にマージ アップします。ただし、安定バージョン ブランチから分岐したブランチをベースにした場合は、そのブランチにマージ ダウンしてすべてのテストに合格することを確認します。その後、同じアップデートを必要とする古いバージョンにバックポートして、その過程でそれぞれをテストします。最後に、main にマージすることで将来のすべてのバージョンに同じ変更を実行します。

複数バージョン ワークフローのスクリーンショット | Atlassian CI/CD

アトラシアンツールはいくつかの場面で役に立ちます。はじめに、Bitbucket で安定したバージョンのブランチを通じて マージを自動的にカスケードダウンできます。各ブランチが新しいコードを受信するたびに自動的にビルドするように構成されていることを確認します。

または、Bamboo の自動マージ (上述) を利用して、安定バージョン ブランチ間で変更を移動できます。ただし、この場合は Gatekeeper オプションを使用します。

ゲートキーパーのスクリーンショット | Atlassian CI/CD

たとえば、v1.2 用のブランチにバグ修正をマージするとします。そのブランチのプラン ブランチ設定に移動して、v1.1 のブランチに自動でマージ ダウンされるように設定します。

ステップ 3.5: 安定 バージョン ブランチを作成する

当然のことながら、次のバージョンのために新しいものに取り組んでいる場合は、重要な機能の準備ができたら新しい安定バージョン ブランチをカットします (準備完了 = 実装済み、テスト済み、確定済みなど)。これは通常、main からカットされて、main と同様、変更がプッシュされるたびに自動でビルドしてテストするように構成されます。

バージョンをリリースする前にさらに変更が必要であることがわかった場合は (ok: いつ)、安定バージョン ブランチからフィーチャー ブランチをカットします。変更の準備ができたら、安定バージョン ブランチにマージ ダウンして、そこでテストします。うまく行ったと仮定して、上の図のように変更を main にカスケードします。

チームがカスケード マージにプル リクエストを使用するかどうかは、あなた次第です。これは良い安全策ですが、Bitbucket と Bamboo が提供するプル リクエストと自動マージ機能は混在できません。そのため、自動化と追加コード レビューのそれぞれのメリットを比較してください。

ステップ 4: リリースする

インプロセス テストが安定バージョン ブランチで合格したときが、デプロイするべきタイミングです。どこにデプロイするかは、あなたとチームが決定します。ほとんどのチームは最初にステージング環境にリリースしますが、この時点までテストを実行できる自信があるチームは本番環境に直接リリースします。

Gitflow での継続的デリバリー

このアプローチでは 1 つの main ブランチだけではなく、プロジェクトの履歴を追跡するために 2 つのブランチを使用します。main ブランチにはプロジェクトの公式リリース履歴を記録するタグやコミットが含まれていますが、共有統合ブランチ (通常は「開発」と呼ばれます) を使用するとチームはバグや互換性のない変更を検出できます。

Gitflow のスクリーンショット | Atlassian CI/CD

ステップ 1: ブランチを作成する

ここでも、基本的なワークフローとの違いは単に分岐元です。新しい開発作業では、フィーチャー ブランチは開発に基づいています (ブランチへのクリーン コミットを選択してください!)。すでにリリースしたバージョンへのバグ修正は、安定バージョン ブランチに基づきます。上の図にはありませんが理念は把握できるでしょう。Gitflow のバリエーションとそのブランチ構造の詳細については、チュートリアルをご覧ください。Bitbucket は、すべてのバリエーションとブランチ アクセス権限をサポートします。この権限では、main ブランチまたはバージョン ブランチへのアクセスを制御するオプションを提供します。

ブランチ元に関係なく、Bamboo のブランチ アップデーター機能 (上述) を使用して、ビルドごとに親ブランチからフィーチャー ブランチに変更をプルします。統合の課題は開発のためのマージ後に発見してもすでに汚染されていますが、上記の方法によって統合の課題をすぐに発見してフィーチャー ブランチで修正できます。

Gitflow モデルでは、main または安定バージョンの各ブランチからリリースできます。実用的な観点から、リリースを Bamboo ビルドのプライマリ ブランチにすることをお勧めします。デプロイ時に実行されてプラン ブランチを可能にするために、すべてのブランチが徹底的にテストされます。

ステップ 2: コード、テスト、繰り返し

テスト ステップは Gitflow で面白くなります。Bamboo のプラン ブランチを使用して (すべての継続的なデリバリー ワークフローのように) フィーチャー ブランチをテスト環境下に置きますが、実装が完了してすべてのテストに合格すると main ではなくマージして開発する点に違いがあります。

開発はすべてのチームの変更が一緒に煮込まれる鍋のようなものです。テストの失敗のデバッグを簡単に (調べるべき各ビルド間の変更を少なく) するため、すべてのコミットに対するフィードバックが求められます。これを確実に実行する最善の方法は、Bitbucket からのプッシュ通知に基づいてビルドをトリガーするように開発を構成することです。リポジトリを定期的にポーリングすると、開発者が頻繁に変更を受信するため、1 つのビルドで複数のコミットからの変更をキャプチャする場合があります。この方法は変更の間隔が開いているブランチにより適しています。

トリガー タイプのスクリーンショット | Atlassian CI/CD

ヒント: 開発用のリポジトリ トリガー ビルドのもう 1 つのメリットは、継続的なデリバリー フレンドリーな Git リポジトリで述べたように、Bamboo の CPU を効率的に使用することです。大規模に継続的なデリバリーを行うチームにとって、これは決定的なメリットです。

基本的なワークフローと同様に、開発をフィーチャー ブランチ (またはリベース) にマージ ダウンして、開発に以降する前に最後のテストを実行する必要があります。

ステップ 3: マージ アップ

フィーチャー ブランチを開発にマージするときにプル リクエストを作成するのが一般的です。この段階でピア コード レビューを行う方が、リリースの準備が整うまで遅らせるよりも遥かに簡単です。整ってからだと、前回のリリース以降のすべての変更を一度に確認する必要があります。それはご免こうむりたいですね。

必然的に、フィーチャー ブランチを開発にマージすると、そこで単にテストが失敗します。開発に直接変更を適用するのではなく、ブランチを再確認してそこで作業を行います (Atlassian のほとんどのチームは、main で直接コミットを行わずにコミットのマージのみ行うという、「暗黙の」了解があります)

ステップ 4: リリースする

Bamboo でビルド プランのプライマリ ブランチとしてリリース ブランチを指定すると、かなり単刀直入なデプロイ プロジェクトが設定されます。ビルド プランのプライマリ ブランチが何であっても自動でデプロイ ジョブのプライマリ ブランチになりますが、フィーチャー ブランチからビルドをデプロイするようにもデプロイ プロジェクトを設定できます。

SaaS ワークフローと同様に、これらのタグから開発とデプロイに成功したビルドごとに、main でタグを自動で作成できます。また、いくつかの機能が開発に正常に追加されるまで待ってから、手動でタグを作成できます。これは単純に、継続的なデプロイに移行するのか継続的なデリバリーにこだわるのかによって異なります。Gitflow は両方に対応しています。

おめでとうございます! 4 つのワークフロー、5 つの図、約 3,200 語の記事をお読みいただきました (隅々までお読みいただき、ありがとうございます!)。

この記事によって、どのように Jira Software、Bitbucket、Bamboo が連携して、継続的なデリバリーにおける課題ごとのブランチ モデルをサポートするかについての基礎を理解していただけたなら幸いです。ご不明な点がありましたら、私宛てにツイートしてこの記事の改善点をお知らせください。皆さんのご意見は大変貴重です。

少なくとも、取り組むそれぞれの課題に対してブランチを作ることのメリットをご確認いただけたかと思います。チームメイトの作業を邪魔せずに、最も重要なブランチを常にクリーンでリリース可能な状態に保ちましょう。最後にもう一度だけ。

ワークフローからブランチングを行うのは「Good Thing™」です。

ブランチをお楽しみください!