Our Bamboo plans are managed via bamboo specs, thus, un-editable. Simply renaming the Deployment plan has resulted in now having two deployment plans that are triggered by the same build. I have no way to disable the old. I only have delete in which I lose all deployment history. What's your solution for this?

Is this possible in Bamboo ?  I'd like to be able to disable a deployment plan.

If you have a Deployment Environment configured with lots of Tasks (as we do), the approach of manually disabling all the Tasks is error-prone. Also, the consulting situation in which we're using Bamboo means that often we'll need to temporarily re-enable the Deployment Environment later on. Again, this comes with the overhead and risk of a manual process.

If Bamboo's configuration-as-code functionality was finished, you could argue for deleting the Deployment Environment and just scripting something to re-instantiate it if necessary later on. Unfortunately, this isn't possible because Bamboo's configuration-as-code functionality still has critical gaps (e.g. you can't programmatically set specific Shared Credentials for custom Tasks).

The resulting situation looks pretty clunky to our customers, who we're often trying to convince to license Bamboo for their long-term use.

We're still big fans of the object model and usability of Bamboo so, Atlassian, it would be great if you guys could get this enable/disable Deployment Environment enhancement into a nearish-term backlog, please.

What if you just disable the tasks? Another option would be use to use a property that prevents the task from running or causes a failure. That has been the workaround I have been using.

@andy125 SMH

No, they responded. They're discontinuing Bamboo Cloud.

LOL. This issue has been out for SO LONG. Looks like this is another one of those many simple issue Atlassian is just going to ignore for a decade.

We recently caught a bug that passed through our buildpipeline. With this feature it could be prevented that those buggy build(s) can be manually deployed. Ideally there should be a reason attached to the the disabled deployment project/environment.

We take our staging environment down from time to time to reconfigure it. It wastes our money to fire up an EC2 instance to run a deployment that can't possibly succeed!