nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Pipelining Bamboo Deployments into various environments

Subhi Andrews

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?

Accepted answers

All comments

Daniel Santos_157bm4

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.

Subhi Andrews

Daniel,

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.

Regards.

Daniel Santos_157bm4

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.

Subhi Andrews

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?