Bitbucket のデプロイ ガイドライン

開発ツールは、柔軟性を提供することで強力な機能を実現するだけでなく、チームを成功に導きます。Bitbucket Deployments は、何千人ものお客様と問題に取り組んできた Atlassian の経験を活かし、第一線のチームに役立つプラクティスを推奨および強化するために設計されています。

このページでは、Bitbucket Deployments の背後にあるいくつかの考え方について説明しています。これは、この話題についてのブログ投稿の背景としてもお読みいただけます。

継続的デリバリーのために構築

Bitbucket Deployments は、継続的デリバリーを行うチーム (一般的には、週に 1 回以上 SaaS/Web 環境へのデプロイを行うチーム) 用に作られています。Atlassian では、これはソフトウェア開発の将来の姿であり、できるだけ多くのチームがこれを実現することを支援したいと考えています。

継続的なデリバリーの基本的な信条は、コードを常にリリース可能な状態に保つということです。Bitbucket において、これはブランチ ベースの検証 (自動/手動テスト、コード レビュー) を使用して feature ブランチを扱った後、自動または手動でデプロイされる、リリースの準備が整ったコードを既定の main ブランチにマージするということになります。

main ブランチを常にリリース可能にしている場合、これは次のことを意味します。

• 他のブランチでビルドされたホットフィックスを環境にデプロイするのではなく、main ブランチで問題を修正して再デプロイする必要があります。

• 変更の影響範囲の確認作業の一部としてデプロイメントの前にテストを実行できるよう、ビルド パイプラインが十分に高速化されている必要がある。

• 環境を通じたビルドのプロモーションが通常のプロセスの一部であった場合、それを緊急時にも実行する必要があり、標準プロセスを最適化して処理できるようにする必要がある。

もう 1 つの一般的な前提条件は、機能の切り替えまたは機能フラグを使用して、新しいコードと独立して新しい機能を利用できるようにすることです。

推奨されるワークフロー

Atlassian の開発ツールは一般的に使用される、3 つの環境を持つワークフローに焦点を当てています。正確な名前は異なる場合がありますが、次のプロセスが非常に一般的です。

• フィーチャー ブランチは、コード レビューに合格し、Pipelines の自動テストを経て、main にマージされる。

• Pipelines は、main ブランチの各コミットで Test への自動デプロイを行う。

• Pipelines にはステージングにデプロイする手動ステップがあり、これは連携機能がテスト環境で手動テストされるとトリガーされます。

  • ステージング アップグレードでは、デプロイメント前のスクリプト、データベース スキーマの変更などが本番環境で正常に機能するかを検証します。

• Pipeline には本番環境にデプロイする手動ステップがあり、これはステージング環境での検証が完了するとトリガーされます。

チームによってはこのフローのステップをスキップしたり (例: テスト/ステージング環境) 、手動ステップのいくつかを自動化する場合がありますが、ほとんどのチームがこのようなステップを基本的に実行していることを想定しています。

また、コード デプロイメントによって機能を直接リリースするのではなく、ユーザーが機能を使用する準備が整ったときに機能フラグを経由してリリースできるようにすることが重要です。

環境の数の制限について

Bitbucket Deployments は共有環境の履歴を追跡するように設計されているため、ユーザーが想定する可能性のあるいくつかの機能が除外されています。

• 機能または開発固有の環境は、共有環境として長期的な追跡を行うことのメリットが小さいため、現在含まれません。

• ブルーグリーンやカナリア デプロイメントなどの本番ロールアウト戦略は、Bitbucket では 2 つの異なるデプロイメントや環境ではなく、1 つの本番環境とみなされます。Atlassian では、本番環境を、より長い時間枠でコードの変更を追跡できる 1 つの単位としてモデル化することを決定しました。これは、この方法がチームにとって最も有益と判断したためです。詳細なデプロイメント ロールアウト情報の導入は曖昧で複雑になり、ご利用のロールアウト オーケストレーション ツールが提供する情報を複製してしまう可能性があります。

• リージョン機能は現在提供していませんが、将来の改善で含めることも検討しています。これを Bitbucket Deployments にうまく適合させる方法について、提案がありましたらお知らせください。

アトラシアンでは 3 つ以上の共有環境が最適となるユースケースを否定しているわけではありませんが、このようなモデルで運用しているほとんどのチームは複雑性に悩まされており、コードを本番環境に送る際のパイプラインが不明確になっていると考えています。4 つまたは 5 つの環境を持つモデルでの各環境のメリットと目的についてより深く理解できるまでは、このような環境の推奨は行いません。

注: 4 つ以上の環境がある場合、引き続き Bitbucket Pipelines を使用してコードをデプロイできますが、実際にデプロイを追跡することはできません (つまり、(ステップに deployment 属性を配置しないでください)。環境名が提供された名前と一致しなくなります。

ブランチではなくアーティファクトベースのデプロイメントを使用

Pipelines はブランチベースのデプロイメントも完全にサポートしていますが、同じアーティファクトを複数の環境へデプロイできる安全な方法として、アーティファクト プロモーションを使用した手動ステップを使用することをお勧めします。各デプロイメントのブランチを再ビルドすると、環境間でコードがわずかに異なる結果になることがあります (例: 依存関係のバージョン)。

デプロイメントのベスト プラクティスについて

pipelines-feedback@atlassian.com にアイデアや提案をお知らせください。