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

We believe development tools are more powerful when they provide flexibility but also steer teams towards the practices that help them succeed. In the design of Bitbucket Deployments, we're using our experience working with thousands of customers to recommend and reinforce the practices we see working for teams in the trenches.

このページでは、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 つの本番環境とみなされます。アトラシアンでは、本番環境を、より長い時間枠でコードの変更を追跡できる 1 つの単位としてモデル化することを決定しました。これは、この方法がチームにとって最も有益と判断したためです。詳細なデプロイ ロールアウト情報を導入すると、状況がわかりにくくなり複雑になり、ロールアウト オーケストレーション ツールから提供される情報が複製されることになります。

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

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

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

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

Although Pipelines fully supports branch-based deployment as well, we recommend using manual steps with artifact promotion as a safer method of deploying the same artifact to multiple environments. Rebuilding the branch for each deployment can result in slight differences of code (e.g. dependency versions) between environments.

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

Please share your ideas and suggestions with us at pipelines-feedback@atlassian.com!