Bamboo deployment, how to trigger it without completing all stages

My (simplified) build plan stages look like this:

  • Build & Test
  • Promote (Manual)

I have this plan linked to a Deployment Project with a couple of test environments, let's say:

  • Test
  • Production

I would like that, once the Test stage has been successful, my binaries are deployed automatically to ENV: Test. The trigger After successful build plan would be a good candidate, but it doesn't trigger the deploy due to a build stage (Promote) pending to be completed.

Any ideas on how to achieve this?


EDIT 1: I'm still a bit confused with this. I'll explain a simplified version of what I want to achieve:

  1. Build and, on successful build, automatically deploy to (say) ENV: Test.
  2. As a manual step, I want to run Promote and deploy to Prod.

As far as I can see, you can not create tags from deployment tasks (and not sure if you should be able to do so), hence I assume this has to be done in a manual Promotion stage in the build plan. If I do that (manual stage), then I can not have an automatic deployment to UAT. If I do Promotion in a deployment plan, I can not create a tag.

I'm flexible with my build plan/deployment project configuration, so: what's the suggestion to achieve the 2 requisites mentioned above? That is, automated deployment to UAT and tag creation on promotion to Prod 


EDIT 2: Still haven't found a proper solution for this. Keep on thinking the best option would be to have deployment triggers linked to build plan stages completion

Build and Deploy.PNG

I can see a few reasons for this:

  1. You want to isolate the 'deployment' tasks from the 'build' tasks. If my deployment to prod fails due to, say, a connectivity issue, that doesn't mean I need to rebuild my binary. Just re-running a deployment should be fine.
  2. Tag creation and artifact promotion (to name 2) do not belong to deployment. I want to be able to re-run my deployments, roll them back, etc. How should I address the tag creation if I put this task in a deployment environment? Think of re-running deployments, roll-backs, etc.
  3. I still want to have as much as possible automated, hence I want to deploy to my ENV: Test as soon as I have a green build. I do not want my developers to have to manually create and deploy a release.

Found the following related tickets:

4 answers

This issue seems to hit on what I am trying to do as well. Basically, I would like to trigger deployments on completion of a build plan STAGE. Currently deployments can only be either scheduled or triggered by completion of the entire build plan. 

I would like to be able to create different deploy environments, each with separate permissions, some tied to fully automated build plan stages and others tied to manual stages of the same build plan. 

In my organization we have procedures and decision gates which require manual stages to trigger deployments in certain environments, but I want the same build to deploy automatically in our dev environment. Currently I have to create two build plans to meet our needs which is messy and confusing as each is actually a unique build and release.

The illustration above (Edit 2) depicting a manual trigger for code tagging and subsequent deploy to production would be what I am looking for, with the ability to have the dev deployment automatically triggered on completion of the Test stage.

I thought about the option for creating separate plans, but that's a no go for us for the reason you mention (lack of clarity) but also because we have hundreds of plans and not having templates or an easy way to update all plans in one go makes it too costly to maintain.

What's the purpose of your Promote stage once Build is already deployed to Dev.  My point it, just remove that stage or make it not-Manual, then your deployment will be auto triggered by build.

There are a few things I need to do on promotion: pre-promotion verification, generate release notes, tag, etc. I guess this should be done in the different Deployment Projects Environments, but, since those are not 'purely deployment' tasks it feels wrong.

The distinction between build and deployment is important, because some languages need project compilation/build procedure carried out and unit-tests performed. Only then, you would clean up your artifacts and deploy to production (if needed, you can perform unit-tests in product environment as well).

And you can't automate something by putting a manual step in the middle of the process.

Sorry, my question is not very clear: I mean why plan vs project? Why not call them build plans and deployment plans? or build projects and deployment projects? Anyway, not concerned about the names chosen, more on how to achieve automated deployment + tag creation on promotion

Just removed the part: "why build plans/ deployment projects distinction?" to make the question more clear

I've added an Improvement request BAM-16160 to Bamboo project. This could be resolved having triggers for deployment plans linked to stage completion.

Suggest an answer

Log in or Join to answer
Community showcase
Renan Battaglin
Published May 18, 2017 in Bamboo

FAQ: How to Upgrade Bamboo Server

Bamboo 5.9 will no longer be supported after June 12, 2017. What does this mean? As part of our End of Life policy, Atlassian supports major versions for two years after the first major iteratio...

1,061 views 0 5
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot