Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Pipelining Bamboo Deployments into various environments

We have a requirement where when a developer is manually triggering deployment to an environment he/she doesn't want that job to trigger other deployment environments. However, we also have a nightly deployment into these multiple environments that need to happen atomically - the same version to all environments. Is there a way to create a master plan that combines deployments to various environments?

1 answer

0 votes

Hi @Subhi Andrews

I'm not sure if I really got how your plan/deployment configuration is set, but I suppose that if you configure scheduled triggers on those environments you will have what you need.

  • Can you explain in details how your triggers are configured for this deployment?
  • Is the plan trigger also triggering any of your environments?

In my tests, I had one of the environments triggering for every build and the others only at a given scheduled time. The result was that in that give time I had all the environments deploying the same release.

Let me know if that makes sense to you.


We want to deploy the latest build into about 8 environments at 2 PM. Ideally in a certain order but we can live with any order so long as the same build gets on all the environments. Since we do not want to chain them by triggering one after another on successful deployment ( this would cause a manual run in an environment to cause the same chained triggering also, which we do not want), we have set up a 2 PM trigger on all 8 environments. 

Here is the problem we are facing. All jobs do some commits to git and push the changes into the same repository in Bitbucket ( to the same branch). This causes git push to be rejected from a few of the environments. Our git push task is a script that does a git pull before the push. This has reduced the number of git push failures but has not completely eliminated it.

Hope that clarifies why we would like to serialize this.

Thanks for your response.


Thank you for explaining, now it is clear for me what you are trying to solve.

I was thinking of what mechanisms you could use to overcome this issue and I didn't find many options:

  • Use only one dedicated agent for this deployment.
    This would force the deployment to run just one environment at a time.
  • Create a chain or trigger for the 8 environments and duplicate the ones you need to run manually (ugly solution, I know).
  • Use a different schedule time for each of the environments (another ugly solution).

I think the best option is to use a dedicated agent to run the deployment.

Please let me know if this is an option for you.

The first one won't work for us. We can wait on the automated nightly deployment for the single agent to become free. However, when people manually click deploy, we want it to complete quickly on the available agent. Restricting it to one agent could potentially cause delays with manually initiated deployment. This is not something we can live with.

The second one as you have correctly stated is an ugly solution.

Problem with using different time schedules for different environments is that the build that will get deployed into different environments could potentially become different based on new builds getting triggered between deployments to various environments.

These solutions won't work. Wondering if there is a way to commit to a separate branch have it merged automatically using Bitbucket hooks? 

Hi @Subhi Andrews

Based on my understanding of your requirement I've opened a feature request to allow manually running environments without triggering cascaded ones:

These solutions won't work. Wondering if there is a way to commit to a separate branch have it merged automatically using Bitbucket hooks? 

It sounds like a reasonable workaround. Do you have questions to implement it?
If you do, do you mind opening another question for this one on Bitbucket questions?

Like Steffen Opel _Utoolity_ likes this

Will start a thread in Bitbucket.

Like Daniel Santos likes this

Thank you for sharing!
You can mention this thread or me if you think it will help.

Like Daniel Santos likes this

Thank you!

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events