Bamboo deployment, how to trigger it without completing all stages
Asked by Xabier Davila:

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:

<https://jira.atlassian.com/browse/BAM-13347>

<https://jira.atlassian.com/browse/BAM-13501>  
[](https://community.atlassian.com/t5/Bamboo-questions/Bamboo-deployment-how-to-trigger-it-without-completing-all/qaq-p/413054?attachment-id=8913){#link_11730d0136664f}  
[](/tnckb94959/attachments/tnckb94959/bamboo-questions/13004/1/Build%20and%20Deploy.PNG){#display_11730d0136664f_0}


Answers:
author: Ben Hodson
body: 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.

comments: author: Xabier Davila
body: 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.


author: Xabier Davila
body: I've added an Improvement request [BAM-16160](https://jira.atlassian.com/browse/BAM-16160) to Bamboo project. This could be resolved having triggers for deployment plans linked to stage completion.


author: Shahriyar Imanov
body: 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).

<br />

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

comments: author: Xabier Davila
body: 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


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


author: Ron Chan
body: 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.

comments: author: Xabier Davila
body: 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.