Thanks Jordan.

That makes things a whole lot easier. Could have saved me much typing. Why isn't this feature documented somewhere other than here? Googling this gets a lot of "not possible" kinds of answers.

Thanks,
Matt

After you clone, you can change the source build plan.

I withdraw my previous comment. I found it. You have to Edit then there's another ... menu.

But it only clones within the same plan. I was looking for some way to clone a deployment project into another build plan.

Is there any plan to provide that?

Thanks,
Matt

Hello morgan.larosa,

Thanks for your comment, and please accept my apologies for the confusion.
You are correct, what I explained above is to clone an environment. The clone project feature is located under the "..." menu. I'm attaching screenshots (CloneaProject_01.png, CloneaProject_02.png and CloneaProject_03.png) to show how we can get to this menu, select the "Clone Project" feature and duplicate the project by giving it a new name.

Please let me know if you have any questions, or if there is any thing we can help you with.

Thank you.
Best regards,
Sepideh

I stand corrected - or rather, amended: whilst the advice provided by Sepideh is irrelevant to this ticket, it is possible to clone a deployment project by editing the project to be cloned and selecting 'Clone project' under the '...' menu.

It's a shame this wasn't documented correctly against this ticket. :S

The ticket relates to cloning deployment projects, not deployment environments. Until it's possible to clone a deployment project, including all of its environments - or, as a workaround, to clone a deployment environment from one deployment project into another - I don't believe this ticket is resolved.

This feature, to clone a deployment environment, is implemented in Bamboo 5.6 as marked here. You can find the "clone" option under "Actions" menu of each environment. I'm attaching a screenshot showing where this feature is located.

Hi,

The reason why I don't want to give you a defined date is that there are many things that can lead us to postpone a release by a week or so. The last thing that I want is to set the wrong expectations and have 5.6 coming later than what you would expect.

We plan to release 5.6 before the first week of August and possibly before the end of the month. I apologise for the confusion with the documentation, we will be more vigilant in the future.

I hope that my response helps to narrow the date of the release a little bit but I can understand your frustration. You can reach out to me directly on spittet@atlassian.com if you have more question around the 5.6 release.

Regards,

Sten

+1 on the prior post.

Atlassian's docs have referenced Bamboo 5.6 for weeks; this morning the latest release notes - dated today, July 22nd - were updated to Bamboo 5.6's contents:
https://confluence.atlassian.com/display/BAMBOO/Bamboo+releases

Don't treat us so bad, Atlassian.

-Kelly G. Schoenhofen

Sorry to be a pain, but where does that type of answer fit with the "Don't bullshit the customer" philosophy at Atlassian?

While we're hanging out for this one as well, 5.6 has an important fix for us in BAM-13588

"Upcoming weeks" is too broad a term, and we're getting tired of waiting.

Hi scott.carpenter@roames.com.au,

I cannot disclose a release date but you can expect it to be released in the upcoming weeks.

Cheers,

Sten

Hi Sten,
When do you expect to release the 5.6 for onDemand?

Thanks,
Scott

Hi markgillespie, drew3,

We are about to release Bamboo 5.6 soon but it is not yet available for download. We fixed Bamboo Update so that it doesn't prompt for 5.6 download anymore. Please accept my apologies for the confusion, but stay tuned for the new release as it should be coming out shortly.

Best regards,

Sten Pittet
Dev Tools Product Manager

Bumping for question above. Where is 5.6?

Hmm Bamboo Update check says 5.6.0 is out, but the download page says 5.5.1

What gives? Is 5.6 released or not?

When is this coming to the OnDemand version?

A templating system would be helpful for us as well to manage deployment to multiple dev and testing environments.

It's good news that we will soon be able to clone Deployment Plans, bit I totally agree with @Mark Brodziak in the need of a templating system so can can clone, but also adjust later the settings of a big number of plans. There are other products out there like ThoughtWorks Go that have been providing this funtionality for a while.

Hi there,

In Bamboo 5.6 we have added the ability to clone deployment projects and clone environments within the same deployment project.

Bamboo 5.6 is due in early July.

Thanks,
James Dumay
Product Manager

My only previous experience is with Jenkins, which allows jobs to be cloned and also provides a REST API for creating them (even better). I think Bamboo's separation of build plans, deployment plans and environments has the potentially to be very powerful, but in its current implementation is frustratingly restrictive for anyone who needs to create new plans regularly and deploy to shared environments. I've resorted to Selenium IDE scripts which literally 'play back' my actions in Firefox to speed up and standardise the process of creating a new plan, but this is inflexible and liable to break when Bamboo is updated.

For the sake of comparison, do any of the watchers of this issue know of any CI products that allow one to clone deployment plans? Or is Bamboo the only product with the concept of deployment plans being separate from builds?

As was mentioned in a previous comment, I would love to be able to:
1) Clone an entire Deployment Project
2) Within a Deployment Project, clone an Environment.

The steps required for each Environment in our DP are the same, usually with slight config changes. Having to manually create each ENV from scratch is very laborious (and prone to human error).

This gets multiplied by a factor of 4 (the number of envs we have) when it comes to setting up a new DP!

I'd like to also provide some comments in relation to the need for some sort of abstraction here. Cloning or copying is a short term fix to set up a deployment project or environments within a deployment project. Yes, it would be helpful during creation, I suppose - but I think more needs to be done here. Once deployment projects are set up they still need to be maintained and adjusted over time. If they are just copies and they don't share any abstraction concepts - well, this is just painful, particularly if you have a lot of environments.

With my current use of Bamboo, one of my build pipelines (for a larger project) has about 10 environments. I want to start carving out discrete services from this project to break down the monolith. Any new services that I create will need their own build pipeline. Supposing I create 3 new services (all of which need to go to all of the same environments as the original big monolith project) I now have 40 deployment projects to maintain - each of which holding their own completely detached set of tasks.

The current Bamboo design for deployment projects doesn't scale well in relation to the above scenario.

I personally think that Bamboo needs to extract the concept of an environment so that, instead of being an attribute of a deployment, it is instead a first-class citizen (maybe we need an environments page / tab?). If we could define environments that can be used by different deployment projects this would help. If we could define a set of deployment tasks that get inherited (by default) for each environment within a deployment project, this would also help - a lot.

I've been asked to query as to when we might have a released Bamboo version with this described functionality. I am sure others are wondering as well.

If you can clone deployment projects, why not also be able to clone environments in a project?
Please make this aswell!

Jason, I like your idea of inheritance. It grants powers of both the micro (granular control) and the macro (common configuration).

I'm not sure that a straight implementation of inheritance would help with presentation, though. Right now, my "All Deployment Projects" page shows hundreds of deployments, but only about a half dozen of them are unique. My tasks pull the necessary bits for differentiating the deployment from build plan variables. Ideally, I'd only see five projects on the "All Deployment Projects" page. Then, under a separate "Deployments" tab, I'd see the information on each individual deployment.

I believe the current way that deployments are modeled is much too simplistic and, thus, inflexible. The addition of a "copy tasks" button won't change my opinion. The way James describes the feature, it sounds like a cheap and lazy solution that fails to attack the problem head on.

To put it into perspective: we also have hundreds of projects in JIRA, but only 11 workflow schemes.

@Mike, my ideal would be close or possibly identical if they focus on abstract like you mention. I'm thinking more of a template but not a copy-from style, more like a parent that the child inherits from. That way in case something does change I can alter it across the board but still get the granularity I need for security and auditing; and if allowed children can override the parent's setting. Bulk altering would be a comprise because initial setup would still be longer. A single deployment plan to me sounds like you may lose some of the granularity multiple plans provide, especially if not all the environments are triggered.

James,

I think we'd prefer an abstraction that allowed the use of a single deployment plan for multiple projects. Even if Atlassian implements a "copy tasks" feature, I'm still going to have to do the manual leg work to create the deployment project, define the environments, configure notifications, specify the agent(s), setup the triggers, etc, etc. A "copy tasks" function will not save me much time at all in the grand scheme of things.

It's NOENTITY at me com
Sorry for that.

Hi All,
If someone need urgent temporary solution (workaround) for that problem until it will be fully implemented by Atlassian devs, please drop me an email at
nonentity at me com
regs
Andy

Hi jtysper,

The development team have written a short spec for this feature and we are waiting for our scheduling to clear up before we can start work on it.

The final solution will not involve a "clone" operation (such as the clone plan), but a more flexible solution that will allow a user to copy tasks between Jobs and Environments (from the feedback we have gathered, its the task list that customers want to clone).

We've got a few items in the works that are not reflected in this JIRA project (yet) so its taking us a while to get to the more popular requests such as this one.

Thanks
James Dumay
Product Manager

In respect to the number of votes: there are 11 issues for Bamboo with more votes. 6 of those have been resolved (though one - BAM-230 - effectively doesn't work anymore). The very highest - BAM-10947, with 78 votes is "to be reviewed".

So this issue needs another 18 voters to get more traction than writing documentation to support PHP...

I would further be interested in how Atlassian deals with these kinds of improvements.

This topic has currently 60 voters but the priority is still "Minor".
There are even more similar issues with many voters - all regarding the topic "the Bamboo deployment model is currently to simplistic".
For example there are BAM-13269 "Task management for deployment environments" (34 voters) and BAM-13575 "Globally defined deployment environments" (10 voters).

Does Atlassian intend to approach these issues and if yes, in which release of Bamboo?

I am not sure if "cloning" is really the solution to your problem but given the current situation it would at least be a first step in the right direction - opposed to creating n more or less equal environments by hand. I strongly suggest though to go even a step further and make deployment plans templated so they can be simply reused in parameterized way and if a step has to be added/modified you have only to make one change instead of n.

I strongly agree with this feature as it will be scaleable and more productive. Other than that, the deployment release of Bamboo is awesome!

I would also need following features:

• Clone deployment project
• Clone environment within a project

The environment name already IS exposed as a variable. I know because I am using it in our plans. The variable is ${bamboo.deploy.environment}.

+ to Jason's comment. Expose the environment name as a variable so that one can pass in the single deployment script since good CD practice is using the same script to deploy no matter the environment.

Mike and Kevin have described exactly what we need to ease setup and/or configuration of multiple plans that are very similar.

@Kevin We're doing the same thing, if we could clone environments that would be nice too but not nearing as repetitive as new Deployment Projects each containing the 3 different environments. If Bamboo would expose the Environment name to a Bamboo Variable we could easily use that as our flag and have identical Environment setups minus the name.

Agreed clone is helpful, but for us the ability to deploy the same release bits to 3 different env (QA, Staging, Prod) all take the same tasks. We just need a way to 'deploy customized' where we can pass in or override a couple of flags. Today all the host/setup info is in our scripts so we really just need to override a variable or two to determine which environment we are pushing to.

Added my vote as well. This would be very useful. Please add to next release if possible.

I'd like to echo many of the above comments, in particular those made by Mike Eldridge. We will essentially have (when complete) a lot of plans (> 50) that are all deploying to the same environments in the same way. As it stands we will have to cut and paste the instructions from an existing deployment plan to create the new plans and change one or two lines for each. Ideally we'd like some kind of abstract deployment project that can be called from any of our plans, passing in parameters / variables to deploy the correct stuff.

Short of that the ability to clone existing deployment projects / plans / environments would be a real advantage.

Put great effort in the my environment.
After We finished it we wanted to clone it (50 times), I'm still a little shocked that there is no clone for it!

I'd like to echo Mike Eldridge's comment. The 1:1 mapping is a huge pain point for us. We are stuck using half-baked features. The branching of build plans limits you to a single source repository. Since our build plans pull from multiple repositories we're forced into cloning build plans to get the branching implementation we require. But without the ability to clone the corresponding deployment projects it's a kludy workaround at best. Providing clone for deployments would be a huge step in the right direction if not the broader implementation with an abstract deployment project Mike's suggested.

+1 This is becoming much more painful than before. We had been using our deployment stage in our Build Plans before and at least we could clone the Stage of the Build Plan. I now have about 10 identical deployment plans I have to do. +1 as well to the idea of being able to use one deployment plan for multiple build plans, this would save a lot of time when updating a deployment stage/plan.

avdschyff you might be also interested in this Plan to Deployment project migration feature request BAM-13346

We already use Bamboo for deployment using standard build plans. We'd like to use deployment plans, but with over 200 deployment plans over 5 environments, the current functionality is not very useful without being able to clone either individual plans or whole environments.

It would also be useful to clone (or move) our existing build plans to be deployment plans, otherwise everything will have to be re-done.

+1 on the feature for applying a single deployment plan to multiple source build plans, like workflow schemes can be applied to projects in JIRA. Right now, it's a 1:1 mapping, but since the deployment plans inherit variables from the build plans, it's desirable to have a single abstract deployment plan that is applied to multiple build plans. You'd probably want to move the release versioning out of the abstract deployment plan and into the individual mapping. Other questions would have to be answered, like at what point in the abstraction are notifications, triggers, agents, etc configured... It would require some careful thought.

Cloning would be better than nothing, though. We have a lot of deployment plans with the same environments, same tasks, same triggers, same notifications, and same agents. Cutting and pasting is no fun.