Bitbucket Pipelines を使用したフィーチャー ブランチの実行

Gitflow またはフィーチャー ブランチ ワークフローを使用して継続的なデリバリーをご確認ください。

Sten Pittet Sten Pittet

Gitflow を使用している場合でも main ブランチがあるフィーチャー ブランチを単に使用する場合でも、Bitbucket Pipelines で継続的なデリバリー (CD) を簡単に導入できます。複雑な継続的インテグレーション (CI) サーバーを構成する必要はありません。必要なのは、Pipelines を有効にしてブランチでテストとデプロイを実行できるようにワークフローを定義するだけです。

Bitbucket Pipelines

このチュートリアルでは、単にさまざまなブランチ用にさまざまなパイプラインを実行するように Bitbucket Pipelines を設定する方法だけでなく、不正なマージからブランチを保護する方法についても説明します。

ステップ 1: フィーチャー ブランチで実行するデフォルトのパイプラインから開始する

フィーチャー ブランチの使用は、main の頻繁な破損を防ぐのに優れた方法です。開発者は別のブランチで特定の改善に取り組んで、ビルドが緑色になったときに変更をマージできます。ただし、この状況はフィーチャー ブランチを安定した状態に保つことがそれほど重要ではないことを意味しません。優れたコラボレーションを実現するには、フィーチャー ブランチを緑色の状態に保つことも同様に重要です。フィーチャー ブランチの使用は、特定の課題を解決するためにどのような変更が行われたかを理解しやすくするための手段であって、品質を遅らせる機会として捉えるべきではありません。

したがって、Bitbucket Pipelines を有効にするときに最初に行うことは、すべてのブランチに対してテストを実行するデフォルトのパイプラインを作成することです。そしてこれは、使用可能なデフォルトのテンプレートの 1 つを選択することで簡単に実行できます。

デフォルトの Javascript パイプライン構成

すべての言語別テンプレートは、新しいブランチがプッシュされるたびに実行される [default keyword (デフォルトのキーワード)] にあるデフォルトのパイプラインを使用しています。bitbucket-pipelines.yml 構成ファイルをリポジトリにコミットするだけで、main ブランチで最初のパイプラインを実行できます。

master に実行された最初のパイプライン

変更を加えた新しいブランチをプッシュするだけで、同じパイプラインが別のブランチで実行されることを確認できます。

ステップ 2: main ブランチに新しいパイプラインを追加する

継続的デリバリーを実践している場合、main にプッシュされた変更を自動的にステージング環境にデプロイしたいと考えるのではないでしょうか。それを実現するため、テストを実行した後にコードをデプロイし、main でのみ実行される新しいブランチ パイプラインを追加します。

image: node:4.6.0
   pipelines:
   default:
     - step:
         script:
           - npm install
           - npm test
   branches:
     main:
       - step:
           script:
             - npm install
             - npm test
             - ./deploy.sh  

上記の YML 構成の branches セクションは、変更が main にプッシュされたときに実行するパイプラインを定義する場所です。

今後、main へのプッシュによって、アプリケーションをビルドしてテストした後にデプロイがトリガーされます。リポジトリのその他のブランチは、新しい変更をビルドしてテストするだけです。

ステップ 3: リリース ブランチを保護する

ステップ 2 の完了後、すべての開発者は変更を main にマージするだけで本番環境へのリリースをトリガーできます。誰かが誤ってまだレビューされていない変更をデプロイする可能性があるため、危険な状況です。幸い、Bitbucket のブランチに権限を追加することで簡単に防げます。

リポジトリの [設定] > [権限] の順に移動します。

ブランチ<br> パーミッション

[書き込みアクセス権限] を空白のままにする main の新しいブランチ権限を追加して、開発者が main に直接プッシュできないようにします。次に、[Merge via pull request permission (プル リクエスト経由でのマージ権限)] に自分自身を追加します。

ブランチ権限の追加

新しいブランチ権限を保存する前に、マージ チェックを追加して、少なくとも 1 つの緑色のビルドがない限りはマージが許可されていないことを確認します。マージ チェック セクションを展開するだけで、対応する機能が有効になります。

ブランチ権限の追加

保存後、ブランチが適切に保護されていることを確認できます。ユーザーまたはグループに書き込みアクセス権限を付与したり、信頼できるチーム メンバーにプル リクエストによるマージを許可したりしないでください。

ステップ 4: プル リクエストを使用して本番環境への変更を促進する

main に直接プッシュできなくなったため、プル リクエストを使用して本番環境にデプロイする必要があります。プル リクエストが作成されたら、変更を main にマージしてデプロイ パイプラインをトリガーするだけです。

Bitbucket のプルリクエスト

マージ後、リポジトリの [Pipelines] セクションに移動して実行中のデプロイを確認できます。

Bitbucket pipelines ログ

Bitbucket Pipelines を使用したフィーチャー ブランチの実行の基本事項について説明しました。この例を独自のニーズに適応させて、独自の継続的なデリバリー パイプラインを作成できます。また、継続的なデリバリー継続的デプロイに関するガイドで詳細を確認できます。