Bitbucket Pipelines による継続的なデリバリーについて学ぶ

このガイドでは、Bitbucket Pipelines を使用して継続的なデリバリー ワークフローを導入する方法を説明します。続けてお読みください。

Sten Pittet Sten Pittet

製品要件

所要時間:

30 分

対象者:

継続的なデリバリーや Bitbucket Pipelines を初めて使用する場合

前提条件:

無料トライアル

新機能を顧客に提供しようとしているとき、新機能をリリースするのは常にエキサイティングな瞬間です。しかし、それはまた、多くの準備が必要で、チームとして頻繁にやることをためらうようなリスクの高い行動になる可能性があります。待てば待つほど、本番環境へのデプロイはより難しくなります。変更が積み重なって変更の範囲が理解し難くなり、本番環境で問題が発生した場合に根本原因を特定することが難しくなります。

ソフトウェアのデプロイに伴う恐怖とコストを取り除く簡単な方法は、ソフトウェアを自動化して小さな変更をより頻繁にリリースすることです。第一に、リリースの準備にかかる膨大な時間を節約できます。さらに、各リリースのスコープがはるかに小さくなるため、環境の監視や問題のトラブルシューティングが容易になり、ソフトウェアのデプロイに伴うリスクを削減できます。

このデプロイの自動化は、今日では Bitbucket Cloud で簡単にできることです。リポジトリごとに、プッシュのたびにコードを自動で構築、テスト、環境へデプロイするパイプラインを設定できます。このガイドでは、Bitbucket Pipelines を使用して継続的なデリバリー ワークフローを導入する方法を説明します。

継続的デリバリーと継続的デプロイ

継続的なデリバリーとは、すべての変更を本番環境にデプロイしていない場合でも、コードを常にリリースする準備ができている状態にするためのプラクティスです。変更の範囲を小さく保つために、できるだけ頻繁に本番環境をアップデートすることをお勧めします。ただし、最終的にはリリースのリズムを制御できます。

継続的なデプロイでは、リポジトリにプッシュされた新しい変更は、テストに合格すると本番環境に自動でデプロイされます。これによって、テスト文化がより重視されます (プレッシャーがかかります) が、顧客とのフィードバック ループを促進する優れた方法です。

継続的なデリバリーと継続的なインテグレーション (CI と CD) を示す図 | Atlassian CI/CD

継続的なデリバリー パイプラインの導入

この例では、ビルドがテストに合格したときに自動でステージングにデプロイする、単純な継続的なデリバリー パイプラインを構築します。本稼働デプロイメントには、ブランチとプル リクエストを使用する方法と、カスタム パイプラインと手動トリガーを使用する方法の 2 つの異なる戦略が表示されます。

どちらの例でも、ブラウザで「Hello World」メッセージを表示する単純な Node.js アプリケーションを使用します。以下で説明する「Hello World!」アプリケーションのコードのクローンを作成して、このチュートリアルを進める際に使用できます。

両方の方法を使用して、このアプリケーションを Heroku でホストされたステージングおよび本番環境にデプロイします。

基本的な Hello World アプリケーション | Atlassian CI/CD

最も基本的な Hello World アプリケーション

Heroku へのデプロイを準備する

まず、Heroku にデプロイできるように Bitbucket Pipelines に環境変数をいくつか追加する必要があります

  • HEROKU_API_KEY: あなたの Heroku アカウントであなたの API キーを見つけられます。
  • HEROKU_STAGING: ステージング環境の名前
  • HEROKU_PROD: 本番環境の名前

リポジトリ設定の [パイプライン] > [環境変数] の順に移動して、これらすべての変数を追加します。

Bitbucket で Heroku を設定するスクリーンショット | Atlassian CI/CD

Heroku にデプロイする環境変数の設定

このガイドでは Heroku を使用しています。この例は他のホスティング サービスに確実に適用できます。このマニュアルには、他のデプロイ ガイドがあります。

ブランチを本番環境への扉とした継続的なデリバリー

この設定は、デプロイにマッピングできる特別なリリース ブランチを持つチームに適しています。また、プル リクエストの変更を本番環境にデプロイする前に確認できます。

この設定では、デプロイをトリガーするために 2 種類の異なるブランチを使用します。

  • main: any push to main will deploy the code to a staging environment after running the tests.
  • production: 本番環境ブランチへマージしたコードは、本番環境に自動でリリースされます。

First, we'll configure the deployment to staging. To do that, we use the branch-specific pipelines and create a pipeline that gets executed for every push on the main branch.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     # When code is pushed to the main branch it is deployed automatically to the staging environment.     main:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main

We have now created a pipeline that will deploy every push to main to Heroku after building and testing our application. The clone section at the beginning of the configuration ensures we do a full clone (otherwise Heroku might reject the git push). Just push this configuration to Bitbucket to see your first automated deployment to staging happening.

正常なパイプライン デプロイのスクリーンショット | Atlassian CI/CD

アプリケーションをステージングにデプロイする、成功したパイプライン

ご想像のとおり、変更が本番環境にマージされると、本番環境ブランチの別のブランチ パイプラインを追加して、本番環境を自動でリリースする必要があります。

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     # When code is pushed to the main branch it is deployed automatically to the staging environment.     main:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main     # When code is pushed to the main branch it is deployed automatically to the production environment.     production:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_PROD.git production:main  

アプリケーションをリリースする前に、本番環境ブランチでテストを再実行してビルドに影響がないことを確認します。

これでパイプラインが構成され、本番ブランチがプルリクエストを介してのみマージを受け入れるように制限できます。リポジトリ設定で [ワークフロー] > [ブランチ権限] へと進み、本番ブランチを制限します。人々がローカルマシンから直接本番環境にプッシュするのを防ぐ上で、これは重要な手順です。

本番環境のブランチの権限を設定する | Atlassian CI/CD

本番環境ブランチの権限を設定する

上のスクリーンショットでは、次の権限を確認できます。

  • 誰も書き込みアクセス権を持っていない
  • ブランチにマージできる開発者は 1 人だけ

また、コードをマージする前に、ソース ブランチに少なくとも 1 つの緑のビルドがあることを確認するために、マージ チェックを追加しました。これによって、ビルド時間を節約して開発者が不良コードを本番環境ブランチにマージするのを防げます。

When that's done, you can create a pull request to merge the code from main to production and subsequently release the new changes to your production environment.

プル リクエスト作成の Bitbucket スクリーンショット | Atlassian CI/CD

プル リクエストを作成して、変更を本番環境にマージする

プルリクエストをマージすると、すぐに新しいパイプラインが本番ブランチでトリガーされるのを確認できます。

プル リクエストによってパイプラインが正常にトリガーされました | Atlassian CI/CD

完了すると、新しい変更は本番環境に正常にデプロイされます。

本番環境は最新です!

Bitbucket Pipelines を使用した継続的なデリバリー ワークフローが設定されました。プル リクエストを安全に使用してコードを顧客にリリースできます。

この例の最終的なソースは、以下のリンク先のリポジトリにあります。

リリースの手動トリガーによる継続的なデリバリー

この設定は、トランクベース開発を練習しているチームに最適です。

With Bitbucket Pipelines it is possible to configure custom pipelines that can be triggered manually. They can be used for various purposes: long-running tests that you do not want to run on every push, or specific actions that you want to control yourself. We will use a custom pipeline to set up a continuous delivery workflow where pushes to the main branch get automatically deployed to a staging environment, and commits can be manually deployed to production.

First, we need to configure the automatic deployment to staging. You simply need to add a branch-specific pipeline for main that will deploy the staging environment.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     main:       - step:           script: # Modify the commands below to build your repository.             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main  

この設定をリポジトリにプッシュして、実施中のステージングへの最初のデプロイを確認できます。

ステージングへの最初の自動デプロイ

ステージング デプロイが設定されたら、bitbucket-pipelines.yml 設定にカスタム パイプラインを追加するだけで、リリースを手動で本番環境にトリガーできます。

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     main:       - step:           script: # Modify the commands below to build your repository.             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main   custom:     prod-deployment:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_PROD.git main  

新しい設定を Bitbucket リポジトリにプッシュしたら、コミットに移動してコミット情報の下にある [パイプラインの実行] リンクをクリックし、本番環境へのデプロイをトリガーできます。

[パイプラインの実行] アクションには、使用可能なカスタム パイプラインが一覧表示されます。

[実行] ボタンを押すだけで、ログを監視できる本番環境デプロイ パイプラインにリダイレクトされます。

パイプラインのコミット情報セクションには、使用されたカスタム パイプラインの名前が表示されます。これで、継続的なデリバリーの新しい Bitbucket Pipelines 設定を使用する準備ができました。Hello World を本番環境で確認して、すべてがうまくいったことを確認できます。

当社の Hello World は、手動トリガーを使用して実稼働環境にデプロイされました

この例の最終的なソースは、以下のリンク先のリポジトリにあります。