Bitbucket Cloud の使用を開始する
Bitbucket Cloud を初めてお使いですか? 新規ユーザー用のガイドをご利用ください。
デプロイを設定、監視する
デプロイを設定する
このガイドでは、デプロイ環境の一般的なセットアップについて説明します。プラットフォーム固有の情報が必要な場合は、デプロイ ガイドを参照してください。
まず、Bitbucket 設定で環境が定義されます。
以下を設定することができます。
名前
環境のタイプ
ダッシュボードでの表示順
その環境に固有の任意の変数
Premium プランの場合は、それぞれにデプロイするユーザー
次に、bitbucket-pipelines.yml ファイルでそれらを参照して、デプロイメント ダッシュボードに表示します。
ステップ 1: 環境を定義する
まずに、環境の詳細情報が追加されます。
パイプラインを有効にすると、"Test" と呼ばれるテスト環境、"Staging" と呼ばれるステージング環境、および "Production" と呼ばれる本番環境の 3 つの基本的な環境が既定で作成されます。
環境のタイプは一般に、環境を論理的に並べるために使用されます。そのため、使用する機能と一致していない場合も問題ありません。
リポジトリ設定に移動します。
Pipelines セクションで、[デプロイメント] を選択します。
任意の環境をクリックして次の操作を行います。
名前を変更
環境に固有のデプロイメント変数を設定
デプロイ変数はチーム変数とリポジトリ変数の両方を上書きします。また、同じ名前の変数を各デプロイ環境に対して別の値で設定できます。たとえば、環境ごとに異なる $DEPLOYMENT_SECRET_KEY を設定できます。その後に環境の制限も行い、管理者のみが秘密鍵を使用するようにできます。
デプロイ機能を管理者、または特定のブランチに制限できます。
環境を追加したい場合、もっとも適切な環境タイプ (Test、Staging、または Production) を決定し、そのセクションで [環境を追加] をクリックします。
また、環境の左側の端をクリックしてドラッグすることで、タイプ内で環境を移動させることもできます。
ステップ 2: デプロイ手順を構成する
deployment キーワードを step または stage に追加し、その後に環境の名前を追加します。Pipelines の既定のデプロイ環境は test、staging、または production です。
例:
1
2
3
4
5
6
7
pipelines:
default:
- step:
name: Deploy to production
deployment: production
script:
- python deployscript.py prodbitbucket-pipelines.yml ファイルに対する変更をコミットし、デプロイ パイプラインを実行します。デプロイ ステップまたはステージがデプロイ ダッシュボードに表示されるようになります。
Bitbucket Pipelines で複数のデプロイ環境を追加する場合は、bitbucket-pipelines.yml ファイル内でデプロイを次のように順序付ける必要があります。
テスト環境
ステージング環境
本番環境
Pipelines では、3 つの環境タイプすべてが必要になるわけではなく、各タイプのステップとステージの順序は任意です。
たとえば、デプロイ設定ページで次のデプロイ環境が設定されているものとします。
テスト環境 — testbed
ステージング環境 — staging1 および staging2
本番環境 — production-east
関連するステップやステージをパイプラインに追加する際には、ステージング環境 (staging1 および staging2) がテスト環境よりも後、本番環境よりも前にグループ化されていることを確認してください。
次に例を示します。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
pipelines:
default:
- step:
name: Build and push to S3
script:
- apt-get update
- apt-get install -y python-dev
- curl -O https://bootstrap.pypa.io/get-pip.py
- python get-pip.py
- pip install awscli
- aws deploy push --application-name $APPLICATION_NAME --s3-location s3://$S3_BUCKET/test_app_$BITBUCKET_BUILD_NUMBER --ignore-hidden-files
- step:
name: Deploy to testing
image: amazon/aws-cli:latest
deployment: testbed # Test environment
script:
- python deploy.py test
- step:
name: Deploy to staging
image: amazon/aws-cli:latest
deployment: staging2 # Staging environment
trigger: manual
script:
- python deploy.py staging
- step:
name: Deploy to QA staging
image: amazon/aws-cli:latest
deployment: staging1 # Staging environment
trigger: manual
script:
- python deploy.py staging
- step:
name: Deploy to production
image: amazon/aws-cli:latest
deployment: production-east # Production environment
trigger: manual
script:
- python deploy.py prodステップ 3: デプロイを追跡する
デプロイメント ステップが実行されたら、[Deployments] ダッシュボードでデプロイメントを追跡できます。
デプロイメント ダッシュボードを理解する
デプロイメント ダッシュボードを使用して、すべてのデプロイ環境の情報をひと目で確認できます。また、権限を持つデプロイ変数を使用して、特定のブランチやユーザーでのみデプロイを行えるようにできます。
デプロイメントのレビューとプロモーション
デプロイメント ステップを手動で実施している場合、[Deployments] ダッシュボードに [Promote] ボタンが表示されます。[Promote] ボタンをクリックするとデプロイメントのプレビュー画面が開き、デプロイされるコミットとファイル変更のレビューを行うことができます。問題がないように見受けられる場合、[Deploy] をクリックして手動のデプロイメント ステップをトリガーします。
注: 各環境では進行中のデプロイメントを 1 つのみ持つことができます。同じ環境にデプロイするそれ以降のパイプラインは、自動的に一時停止されます。進行中のデプロイメントが完了すると、一時停止しているデプロイ ステップを手動で再開できます。
デプロイメント情報
環境カードからさまざまな情報にアクセスできます。
1. デプロイメント履歴
環境名をクリックすると、環境への過去のすべてのデプロイメントの履歴を表示できます。いずれかをクリックすると、デプロイメントの要約が表示されます。
2. パイプラインの表示
パイプライン番号をクリックすると、パイプラインのその実行の要約に移動し、そこからログなどを表示できます。
3. デプロイメントの要約
環境カードまたは履歴の一覧でデプロイメントをクリックして、デプロイメントの要約にアクセスします。要約には、以下を含む、デプロイメントについての情報が表示されます。
デプロイ先の環境
環境での過去のデプロイメント
デプロイメントのステータス
デプロイメントのトリガー実施者 (デプロイメントが手動ステップだった場合)
デプロイメントが発生した日付
デプロイメントのコミットの完全な一覧
新しいデプロイメントと環境内の過去のデプロイメントのファイル差分
コミット メッセージでメンションしたリンクされている任意の Jira 課題
どの環境でもデプロイされた最初のビルドには、そのビルドに関連付けられたコミットのみが表示されます。ビルドを再実行しても、これらのビルド間で違いはありません。そのため、そのビルドの差分は表示されません。
Jira を使用して作業を追跡している場合、Jira と Bitbucket をリンクすることでさらにメリットを実現できます。
これらをリンクすると、デプロイメントに関連する課題がデプロイメントの概要とデプロイメントのプレビュー画面に表示され、デプロイメントが関連する Jira 課題に表示されます。コミット メッセージに課題キーまたはキーを追加すると、残りの処理は自動で行われます。
例
1
git commit -m "PT-323 Add created workers to container cluster"
Bitbucket では、これは次の画像のように表示されます。
Jira では、次のように表示されます。
成功したデプロイメントを再実行すると、Jira は再実行の結果ではなく、最初に成功したデプロイメントの詳細を引き続き表示します。
デプロイメントのロールバック
Bitbucket Pipelines では、パイプライン全体を実行することなく、1 つのデプロイメント ステップをロールバックできます。デプロイメントに失敗したら、最後に成功したデプロイメントを数クリックで復元できます。
はじめる前に
[再デプロイ] ボタンを有効化するには、以下が必要です。
パイプラインの最初のデプロイメント ステップが正常に完了していること。
デプロイメント権限で、ステップの再デプロイが許可されていること (Premium プランのみ)。
アーティファクトが失効していないこと。
デプロイメントのロールバック
デプロイメント ステップをロールバックするには、次の手順を実行します。
再デプロイするデプロイメントを選択し、[再デプロイ] ボタンをクリックします。
[再デプロイ] 画面で、変更内容を確認して [再デプロイ] をクリックします。
または、[Deployments ダッシュボード]で[再デプロイ] をクリックすることもできます。
この内容はお役に立ちましたか?
さらにヘルプが必要ですか?
アトラシアン コミュニティをご利用ください。