Bamboo deployment, how to trigger it without completing all stages

[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

[Ben Hodson]

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.

[Xabier Davila]

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.

[Xabier Davila]

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

[Shahriyar Imanov]

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.

[Xabier Davila]

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

[Xabier Davila]

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

[Ron Chan]

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.

[Xabier Davila]

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.