Permit Rollbacks in Bitbucket Cloud Deployments

Issue #16604 open
Tanju Erinmez
created an issue

I have a build #10 deployed to production but need to quickly rollback to build #9 (the previous stable deployment). If I select the build #9 and click re-run it generates a build #11 which goes through test, staging, etc. This is problematic because the build artifacts are associated with build #9 and are actually readily stored & available in S3 in our case. A build #11 would a) take time and b) recreate the artifacts from scratch, thus, it would not be really a rollback.

Given how BB Deployments is built on top of BB Pipelines, I guess what would be needed is to be able to re-run a specific step.

(raised with @Aneita Yang via email)

Official response

  • Aneita Yang staff

    Hi everyone,

    Thanks for your interest in this feature.

    I'd love to speak with a couple of customers to better understand how you perform rollbacks today and also get an idea for what you'd like to see from a rollback feature. If you're interested in providing feedback, please reach out to us at pipelines-feedback@atlassian.com and include which timezone you're in, and we can schedule a quick 30 minute chat.

    Thanks,
    Aneita

Comments (26)

  1. Dean Hutchison

    +1 Need. I don't understand how this is not already a feature - I think this is essential for production. We previously did this in Bitbucket server and it was perfect. We need a quick method of deploying a previously built pipeline. Once we run our build we store our docker image in our registry. If deployments let me re-run a deployment step then I would be able to run a script to deploy our docker image from our registry without having to go through the build process again. We would be able to revert in seconds rather than several minutes. At the moment we have to do this as a process outside of Bitbucket.

  2. Daniel Chodusov

    Rollback feature would be definitely appreciated.

    I would love to have some configuration option in pipelines to trigger custom rollback script - something like this, when using deployer

            - step:
                name: Rollback the latest release
                deployment: staging
                trigger: rollback
                script:
                    - composer global require deployer/deployer
                    - composer install --ignore-platform-reqs
                    - php vendor/bin/dep rollback staging -vvv
    
  3. Chris Paynter

    I'd find this extremely useful so that I don't have to go through the build and containerise step (longest step) every time I want to re push to staging (say if I'm playing around with configs and just want to re-trigger the docker run command with the correct environment variables).

  4. Aneita Yang staff

    Hi everyone,

    Thanks for your interest in this feature.

    I'd love to speak with a couple of customers to better understand how you perform rollbacks today and also get an idea for what you'd like to see from a rollback feature. If you're interested in providing feedback, please reach out to us at pipelines-feedback@atlassian.com and include which timezone you're in, and we can schedule a quick 30 minute chat.

    Thanks,
    Aneita

  5. Sibtain Ul Hassan

    Rollback in pipelines should be like they way it works in Bamboo. You should be able to rollback to any previous deployment version without rebuilding the whole code. It's just the build artifact which goes through for the redeployment.

    Currently in pipelines if you want to rollback you have to build whole code again and then goes through all the process before getting deployment. A standard rollback feature just redeploys the previously built artifact in case of rollback.

  6. Yury Zhytkou

    Must have. I would expand this though to be able to re-deploy any previously successful build number without running through the whole pipeline and all steps again

  7. Corey Crowden

    +1 This is the only thing holding me back from using pipelines. A definable rollback step as Daniel mentioned above would be ideal.

    I'm currently using DeployBot's Atomic deployment feature, which stores each deployment in it's own directory under release. This uses symlinks to direct the active webroot to the current release, and can be rolled back in an instant with the click of button by simply changing the symlink with the previous release.

    With a rollback pipeline, we can very simply replicate this for an instance rollback with a single command to symlink the active webroot to the previous release.

    Hopefully, that makes sense...

  8. Log in to comment