Bitpucket Pipeline Configuration for Gitflow Branching Model

Question

I'm following this link for the Gitflow branching model:

In this diagram, commits flow as follows:

1. Scenario-1: Feature -> Dev -> Release -> Master

2. Scenario-2: Hotfix -> Master and Hotfix -> Dev

3. Scenario-3: Release -> Master and Release -> Dev

I'm looking to implement the bitbucket pipeline. Most of the ones recommended the below pipeline configurations.

image: your-preferred-docker-image

pipelines:
  default:
    - step:
        name: Build and Test
        script:
          - echo "Build and test commands go here"

branches:
  master:
    - step:
        name: Deploy to Production
        script:
          - echo "Deployment to production goes here"

  develop:
    - step:
        name: Deploy to Staging
        script:
          - echo "Deployment to staging goes here"

  release/*:
    - step:
        name: Build and Test Release
        script:
          - echo "Build and test release branch"

It will trigger a pipeline for every merge in the respective branch. I'm looking to trigger the pipeline once and it will wait for manual trigger to merge other environments.

For example,

Scenario-1: if anyone merge feature branch to dev, it will trigger pipeline and deploy it in dev and wait for manual trigger to deploy the same in release and master.

Scenario-2: if anyone merge hotfix branch to master, it will trigger pipeline and deploy it in master and wait for manual trigger to deploy the same in dev and it won't trigger scenario 1 again.

Scenario-3: if anyone commit directly to release, it will trigger pipeline and deploy it in release and wait for manual trigger to deploy the same in master and dev and it won't trigger scenario-1 and scenario-2 again.

Any guidance is much appreciated. Thanks in advance.

Answer 1

To implement the Bitbucket pipeline according to the Gitflow branching model, we need to define specific pipeline steps for each scenario, including manual triggers.
For Bitbucket pipelines, you can use manual steps to control when deployments should occur:

image: your-preferred-docker-image

pipelines:
  default:
    - step:
        name: Build and Test
        script:
          - echo "Build and test commands go here"

  branches:
    master:
      - step:
          name: Deploy to Production
          trigger: manual
          script:
            - echo "Deployment to production goes here"

    develop:
      - step:
          name: Deploy to Staging
          trigger: manual
          script:
            - echo "Deployment to staging goes here"

    release/*:
      - step:
          name: Prepare Release
          script:
            - echo "Prepare release branch"
      - step:
          name: Deploy Release
          trigger: manual
          script:
            - echo "Deploy to release environment goes here"

    feature/*:
      - step:
          name: Integrate Feature
          script:
            - echo "Integrate feature into develop goes here"

That configuration makes sure deployments to master, develop, and release/* branches require a manual trigger, not automatically deploying after each merge.

• Scenario-1: Merging a feature branch to develop will trigger the Integrate Feature step, but not deploy to staging. A manual step must be triggered for deployment to staging.

• Scenario-2: Merging a hotfix branch to master will trigger the Deploy to Production step, but it will require a manual trigger to deploy. After deployment to master, a manual step must be triggered for deployment to develop.

• Scenario-3: Committing directly to a release branch will trigger the Prepare Release step and then require a manual trigger to deploy to the release environment. Subsequent manual triggers are required to deploy to master and develop.

---

Note that Bitbucket Pipelines also support the custom pipeline which can be triggered manually. That might be useful if you want to have even more control over the deployment process, especially for complex workflows like the one you are implementing.

image: your-preferred-docker-image

pipelines:
  default:
    - step:
        name: Build and Test
        script:
          - echo "Build and test commands go here"

  branches:
    develop:
      - step:
          name: Integrate Feature
          script:
            - echo "Integrate feature into develop goes here"

    master:
      - step:
          name: Merge to Master
          script:
            - echo "Prepare production deployment"

  custom: # Custom pipelines definitions
    deploy-to-staging:
      - step:
          name: Manual Deploy to Staging
          script:
            - echo "Deployment to staging goes here"
            
    deploy-to-production:
      - step:
          name: Manual Deploy to Production
          script:
            - echo "Deployment to production goes here"

    deploy-release-to-envs:
      - step:
          name: Manual Deploy Release to Staging and Production
          script:
            - echo "Deploy release to both staging and production environments"

    deploy-hotfix-to-dev:
      - step:
          name: Manual Deploy Hotfix to Develop
          script:
            - echo "Deploy hotfix to develop environment"

You can trigger the deploy-to-staging custom pipeline manually whenever you want to deploy the develop branch to the staging environment.
When you want to deploy the master branch to production, you manually trigger the deploy-to-production custom pipeline.

For a release branch, after preparing the release, you can manually trigger deploy-release-to-envs to deploy to both staging and production.
When you have a hotfix that needs to be deployed to develop, after merging to master, you can manually trigger deploy-hotfix-to-dev.

To trigger a custom pipeline manually, you can go to the Bitbucket repository's Pipelines section, click on 'Run pipeline', select the branch, and then choose the custom pipeline you want to run.

This setup allows your team to have full control over when to deploy to different environments, without the pipeline being triggered automatically on every push or merge. The manual steps will not run until someone triggers them, giving your team the opportunity to review changes before they are deployed.

Answer 2

There are a series of subtleties around pushing back from a pipeline but it can be done. Things that come to my mind:

• you may not do with a shallow clone (default depth are 50 commits)
• the pushed commit either should or should not trigger a new pipeline, so you may or may not preface commit messages with "[skip ci]"
• if you had pushed back in the past via ssh and access keys, you'll face some sharp edges if you try to opt-in to using the auto-authenticated https proxy that is now featured in pipelines

Then you can push back to the repository from a manual step that happens after the deploys for commits in each branch.

Scenario 1

if anyone merge feature branch to dev, it will trigger pipeline and deploy it in dev and wait for manual trigger to deploy the same in release and master.

definitions:
  yaml-anchors:
    - &deploy-step
        script:
          - ./deploy $BITBUCKET_DEPLOYMENT_ENVIRONMENT
pipelines:
  dev:
    - step:
        <<: *deploy-step
        name: deploy development
        deployment: dev
    - step:
        name: push release
        trigger: manual
        clone:
          depth: full
        script:
          - git checkout release/x
          - git merge $BITBUCKET_BRANCH
          - git push origin release/x

  release/*:
    - step:
        name: prepare release
        script:
          - # you tell me
    - step:
        name: push main
        trigger: manual
        clone:
          depth: full
        script:
          - git checkout main
          - git merge $BITBUCKET_BRANCH
          - git push origin main
 
  main:
    - step:
        <<: *deploy-step
        name: deploy production
        deployment: pro

Scenario 2

if anyone merge hotfix branch to master, it will trigger pipeline and deploy it in master and wait for manual trigger to deploy the same in dev and it won't trigger scenario 1 again.

pipelines:
  # ...
  main:
    - step:
        <<: *deploy-step
        name: deploy production
        deployment: pro
    - step:
        name: pushback dev
        trigger: manual
        clone:
          depth: full
        script:
          - git checkout dev
          - git merge $BITBUCKET_BRANCH -m "[skip ci] Merge main into dev"
          - git push origin dev

Scenario 3

if anyone commit directly to release, it will trigger pipeline and deploy it in release and wait for manual trigger to deploy the same in master and dev and it won't trigger scenario-1 and scenario-2 again.

I am afraid there is no way to tell a commit came from a merged hotfix PR or a direct push, but previous scenarios 1 and 2 should already cover this because a merge in main will always pushback to dev, where you can create a new upstream PR to manually trigger the release workflow. (IMHO you should not allow direct pushes anyway if you are being this picky about your branching model)