How to achieve hot deployments to environment using Bitbucket Pipelines?

[Siddharth Goel]

Hello team !

We are evaluating various managed CICD vendors including Bitbucket pipelines for our deployment. Bitbucket Pipelines has a higher preference in our category as we are already using Bitbucket for our code. Our current provider for CICD pipeline is Jenkins. Please help us with one of our blocker. I will explain our use-case and blocker below.

We have two kind of deployment for our applications for each build -

1. Full Deployment : In this we install our package on a fresh Linux machine and decommission the old machine
2. Hot Deployment : We copy necessary artifact (jar, war, pkg, dll, executables etc.) in an existing machine at a specific directory to be picked and deployed without restarts

We have been successfully able to migrate our Full Deployment logs to Bitbucket Pipelines which works reasonably fine. However, with the existing constructs, I fail to understand how can I achieve Hot Deployments. Let me share what all I have looked into :

• Try using different steps under an environment. Example : 

- step: &Deploy-to-dev
 name: '🚀 Deployment - 💻 Dev'
 deployment: dev
 trigger: manual
 script:
 - ./full_deployment.sh dev

- step: &HotDeployment-Pkg1-to-dev
 name: '⚡️Hot Deploy Pkg1 - 💻 Dev'
 deployment: dev
 trigger: manual
 script:
 - ./hot_deploy.sh dev Pkg1

But with this I see following issue

The deployment environment 'dev' in your bitbucket-pipelines.yml file occurs multiple times in the pipeline. Please refer to our documentation for valid environments and their ordering.

• Using Stage concept. However, the issue with the Stage is that one cannot choose what to run and what not to run. It is full or none

Any help on the matter would be greatly appreciated.

[Theodora Boudale · Accepted solution]

Hi Siddharth and welcome to the community!

Steps of the same pipeline need to be executed sequentially. There is no option to skip a specific step; we have a feature request that you can vote for here: https://jira.atlassian.com/browse/BCLOUD-20833

You can work around this issue in one of the following two ways:

1st Option

Create two deployment environments instead of 1, named e.g. dev1 and dev2. The environments need to be of the same type for this solution to work (e.g. they both need to be under Test environments, or under Staging environments or under Production environments)

You can then make these two deployment steps parallel and manual, see below an example:

pipelines:
  default:
    - step:
        script:
          - echo "Build and Test"
    - parallel:
        steps:
          - step:
              deployment: dev1
              trigger: manual
              script:
                - echo "This is dev1 deployment"
          - step:
              deployment: dev2
              trigger: manual
              script:
                - echo "This is dev2 deployment"

I didn't use YAML anchors here, but this will also work with YAML anchors. Since the steps are parallel and manual, you can select which one to run.

Please keep in mind that if you have another step after the parallel set, then both parallel steps will need to be completed for the pipeline to run the next step.

Since two deployment environments are used, there will be no concurrency control. This shouldn't be an issue if each step deploys to a different machine, but it might be an issue if both steps deploy to the same machine and run at the same time.

2nd Option

You can use a separate custom pipeline for each of the deployment steps:

• https://support.atlassian.com/bitbucket-cloud/docs/pipeline-start-conditions/#Custom--manual--pipelines

Custom pipelines do not run automatically. They can be triggered manually or on schedule. You can see the different ways to trigger custom pipelines here:

• https://support.atlassian.com/bitbucket-cloud/docs/pipeline-triggers/

Please feel free to let me know if you have any questions!

Kind regards,
Theodora

[Siddharth Goel]

Thanks Theodora for your response and the welcome :)

Option two was something that had also crossed my mind, but option one could be interesting workaround for my case till the feature you mentioned is planned out.