Bitbucket Pipelines による継続的なデプロイについて学ぶ

このガイドでは、Bitbucket Pipelines で継続的なデプロイ パイプラインを実装する方法を説明します。

Sten Pittet Sten Pittet

ソフトウェア開発では、アプリケーションを開発するときにしばしば難しいトレードオフを迫られる場合があります。リリースのスピードを重視する場合は、品質を犠牲にせざるを得ないと信じられています。しかし、時間を節約してより速いリリースを実現できる開発方法があります。それが継続的デプロイです。

継続的デプロイではソフトウェアのデプロイプロセスを自動化することでストレスを取り除きます。開発チームは作業を停止してリリースのためにコンテキストを切り替える必要がなくなります。開発者が自分の作業を終了すると同時に顧客にコードがリリースされます。

このガイドでは、Bitbucket Pipelines で継続的なデプロイ パイプラインを実装する方法を説明します。

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

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

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

継続的なデプロイと継続的な開発の違いを示す図 | Atlassian CI/CD

製品要件

継続的デプロイパイプラインの設定

継続的なデプロイは、チームが開発を加速させるのに最適な方法です。これによって、リリース承認プロセスに関連する障害がなくなり、開発者は作業が完了するとすぐに顧客からフィードバックを得られます。問題は識別して修正しやすくなってリリース時間がなくなるので、コンテキストの切り替えも少なくなります。

Bitbucket Pipelines を使用した継続的なデプロイ パイプラインの構成は、非常に簡単です。本番環境に自動でリリースされる前に、ステージング環境と受け入れテストを通過する簡単な Hello World アプリケーションで構成を行う方法について説明します。

Hello World アプリのソースは、以下のリンク先のリポジトリにあります。

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

始める前に、Heroku にアプリケーションをデプロイできるように、環境変数をいくつか追加する必要があります。

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

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

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

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

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

パイプラインの設定

ワークフローは単純明快です。

  • アプリケーションをビルドする。
  • ビルドでテストを実行する。
  • ステージング環境にデプロイする。
  • ステージング環境でいくつかの受け入れテストを実施する。
  • 本番環境にデプロイする。

対応するパイプライン設定は、非常に簡単に作成できます。まず、自動デプロイをステージング環境に追加して、プッシュごとに正しく動作することを確認します。

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 

Heroku がプッシュを拒否しないようにするため、フル クローンを使用していることに気付くと思います。次に、ブランチ特有のパイプラインを使用して、main にプッシュされた変更のステージングのみをデプロイして、他のブランチにはデプロイしていないことを確認します。この設定を Bitbucket にプッシュして、動作を確認できます。

ステージング環境への自動デプロイが完了しました


この段階では、Hello World アプリケーションがステージング環境にデプロイされています。

次のステップに進んで、受け入れテストを追加できるようになりました。受け入れテストは、アプリケーションが本番環境に近い環境 (ステージング) で想定どおりに動作することを確認するためのものです。目標は、ビルドをテストするために使用される環境と本番環境の構成の違いによる不確定性を排除することです。

アプリ コードを見ると、テストはただページ内の「Hello World」という文字列を探しているだけであることが分かります。実際のアプリケーションでは、受け入れテストをさらに進めて、アプリケーション (データベース、キャッシュ、サード パーティなど) で使用されるすべての基本サービスが正しく動作していることの確認をお勧めします。

それでは、デプロイ直後のテストをステージングに追加しましょう。

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             - HEROKU_STAGING=$HEROKU_STAGING npm test acceptance-test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main             - npm test acceptance-test  

この新しい構成を Bitbucket にプッシュすると、パイプラインが正常に完了することが確認できます。

ステージング環境にデプロイされると、Bitbucket Pipelines が受け入れテストを実施します

後は、最後に本番環境を追加して継続的なデプロイ パイプラインを完成させるだけです。

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             - HEROKU_STAGING=$HEROKU_STAGING npm test acceptance-test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_PROD.git main  

Bitbucket への最後のプッシュは、すべてのパイプラインを通じてコードの変更を行って、コードをビルドしてテストし、ステージングが正常に機能することを確認した後、本番環境にデプロイします。この場合、ホームページは別のメッセージでアップデートされて、本番環境までデプロイされることを確認します。

新しいメッセージが想定どおりに本番環境に導入されました!

パイプラインをチェックして、パイプラインがすべての異なるフェーズを通過したことを確認できます。

コードがパイプラインを通過したことを確認する

独自のリポジトリに継続的デプロイを実装する前に、リアルタイム監視機能に加え、適切なテストスイートを持っていることの重要性を強調する必要があります。この先、変更はメインブランチにプッシュされると直ちに本番環境に向かうため、自動化されたテストでアプリケーションの重大な部分を必ず確認することがより重要になります。さらに、本番インスタンスにマイナスの影響 (完全な破損やサービスの低下など) を及ぼす変更を検出する監視ツールが必要になります。

以下のリンクで Bitbucket クラウドリポジトリの最終的なソースを確認できます。