Why not more environments for Bitbucket Deployments?

[Miroslav Sommer]

I have found out in here...

https://confluence.atlassian.com/bitbucket/bitbucket-deployments-940695276.html

... that:

Bitbucket Deployments supports deploying to the following three environments:

• test
• staging
• production

and an "answer" to the question here:

https://confluence.atlassian.com/bitbucket/bitbucket-deployments-guidelines-941599590.html

we're looking to understand where more than three shared environments makes sense. It seems that most teams operating in this kind of model are struggling with complexity and having an unclear pipeline for getting code into production. We would not like to encourage this until we understand more about the benefits and purposes of each environment in a 4- or 5-environment model#

OK

I'm sorry, but we cannot accept your encouragement to use a static number of environments, let alone just 3.

Your limitation is one of the reasons we will not pay for Bitbucket Premium to use Pipelines or Deployments.

Did you actually ask any enterprise clients who pay for Bitbucket about how many and which environments do they regularly use?

We have many teams who have adopted different models for deployments and use dynamic number of environments, either short-lived or long-lived, mostly deploy to Cloud. They won't be able to reduce their workflow to just those 3 environments.

At one time, there might be just three environments (dev, production, production-DR) and at another time there might be thirty environments - each serving different purpose and spun up temporarily by an individual or a team working on a particular issue - all are independent and built for separate issues. In a team of couple of dozen developers and testers, it is not unusual that there are couple of dozen issues in progress and each have a slightly different requirements for an environment, thus requiring a distinct environment.

One of the more stable environments, which are regularly spun up by various teams and various projects are:

• CI
• UAT
• external UAT
• integration
• performance
• training
• blue
• green
• dryrun (like staging)
• live support
• production in Azure region A (primary)
• production in Azure region B (secondary)
• production in Azure region C (Disaster Recovery aka "DR")
• ...

The bottom line is that 3 environments are definitely not enough and we will never change hundreds of our projects to somehow reduce their environments to just those 3.

[Philip Hodder]

Hi Miroslav,

We have an open feature request here that you can follow: https://bitbucket.org/site/master/issues/15362/enhance-deployments-to-support-flexible Any related updates will be present here.

The current limitation of 3 environments was merely a point that we could iterate on top of, once we understood our customer's deployment workflows in more details.

If you're able, can you email Aneita (her details are on the ticket) about your use-case? I'll forward this question to her, as well.

Thanks,

Phil

[Miroslav Sommer]

Hi Phil,

Thanks for coming back to me on this - I'll email ayang at atlassian.com

Thanks,
Miro