プル リクエストでデプロイする

You can deploy using pull requests in two main ways: 

  1. Defining pipelines that only run on pull requests
  2. Using a specific structure for your repository

Define a pull request pipeline

For pull requests within your repository, you can define a special pipeline which only runs on pull requests. This pipeline can be configured to deploy in the same way as a regular pipeline. We recommend only using this to deploy to test environments, as you've not fully merged yet!

This type of pipeline runs a little differently to other pipelines. When it's triggered, we'll merge the destination branch into your working branch before it runs. If the merge fails we will stop the pipeline.


This only applies to pull requests initiated from within your repository; pull requests from a forked repository will not trigger the pipeline.

pipelines:
  pull-requests:
    '**': #this runs as default for any branch not elsewhere defined
      - step:
          script
            - ...
    feature/*: #any branch with a feature prefix
      - step:
          script:
            - ...
 branches:    #these will run on every push of the branch
    staging: 
      - step:
          script:
            - ...
Tip: If you already have branches in your configuration, and you want them all to only run on pull requests, you can simply replace the keyword  branches  with  pull-requests  (if you already have a pipeline for  default  you will need to move this under  pull-requests  and change the keyword from default  to '**' to run).

Pull request pipelines run in addition to any branch and default pipelines that are defined, so if the definitions overlap you may get 2 pipelines running at the same time!

Restrict pull requests to certain branches

ステップ 1: リポジトリの構造を定義する

リポジトリ ブランチ:

master: 使用している統合ブランチ

staging: このブランチを使用してステージングへのデプロイメントをトリガーします。

production: このブランチを使用して本番環境へのデプロイメントをトリガーします。

featre/xxx: すべての機能ブランチ

上記のブランチ構造に加えて、異なるブランチ用の複数のフローを含む .YML ファイルを定義できます。

bitbucket-pipelines.yml
# This is a sample build configuration for Javascript.
# Only use spaces to indent your .yml configuration.
# -----
# You can specify a custom docker image from Docker Hub as your build environment.
image: node:10.15.0

pipelines:
  default:
    - step:
        script: 
          - npm install
          - npm test
  branches:
    staging:
      - step:
          script:
            - npm install
            - npm test
            - export HEROKU_APP_NAME=$STAGING_APP
            - ./heroku_deploy.sh # Check https://bitbucket.org/rjst/heroku-deploy to understand how to deploy to Heroku
    production:
      - step:
          script:
            - npm install
            - npm test
            - export HEROKU_APP_NAME=$PROD_APP
            - ./heroku_deploy.sh  # Check https://bitbucket.org/rjst/heroku-deploy to understand how to deploy to Heroku


  • オンライン バリデーターを使用して bitbucket-pipelines.yml ファイルをチェックすることができます。
  • staging と production を除くすべてのブランチは、テストの実行のみを行う既定のパイプラインを使用します。
  • stagingdeployment ブランチは異なる構造を持ち、それぞれステージングおよび本番環境へのデプロイのためにセットアップされます。

ステップ 2: ブランチ権限を設定する

staging および production ブランチが直接プッシュされないように、ブランチ権限を使用してプル リクエスト経由でのみマージが許可されるようにすることができます。

以下の例では、全員が staging にマージできますが、production には選択された個人のみがマージできるようにブランチ権限が設定されています。


ステップ 3: プル リクエストを使用してデプロイを開始する

これで、feature ブランチで新機能や改善機能を開発し、master に統合できます。次は、staging ブランチにプル リクエストを発行し、ステージング環境に変更をデプロイします。


プル リクエストを作成すると、ステージング環境へのデプロイの前に変更をレビューできます。このプロセスを繰り返して production にデプロイします (staging ブランチから master ブランチのプル リクエスト)。

以下の画像は、staging から production にマージされるプル リクエストのビューです。


最終更新日 2019 年 3 月 15 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.