Enhance Deployments to support flexible environments

Issue #15362 open
Martin Essam
created an issue

The initial (alpha) release of Deployments only offered three fixed environments: test, staging, production.

However difference projects often have more and refer to them with different names.

For example: Development System Test System Integration Test User Acceptance Test Training Production

Having a fixed number (and named) set of deployment environments makes this otherwise desirable feature unusable since they are not going to invest in one technology to deploy to 3 environments and another for the remaining environments.

Comments (13)

  1. Aneita Yang staff
    • changed status to open

    Hey Martin,

    Thanks for raising this. I'll open this issue to gauge the interest of other users on this functionality.

    As I mentioned, our priority for the next couple of months is to build out the Deployments feature, for the 3 environments that are currently supported. After that, we will revisit the decision to support only 3 environments.

  2. j sweeney

    We have a need for additional environment OR environment labels. The scenario we're dealing with is having multiple groups under a particular environment. For example, we have Production East and Production West. It would be ideal if we could provide sub labels to see which production version is on which sub-environment.

  3. Scott Buchanan

    We would also use this feature with multiple environments across different pipelines. On some of our projects we have multiple work streams in progress simultaneously which need to be simultaneously reviewed. As such we have test01, test02, test03, etc. As soon as a project has more than two parallel workstreams (plus production), the current deployments implementation becomes untenable.

  4. Jean-S├ębastien Gerard


    Nice feature, looks tempting :)

    Yet, in our context, we have several branches sections in pipelines, and basically we have one dedicated branch for each environment (like, testing1 branch goes to test server1, testing2 to test server2, etc., and master goes to production server), and we have one (rarely two, but we have too) step per branch that handles the deploy of this branch to the target server.

    So, I'm not sure how/whether this feature fits in our scheme, as is. Because, if I understand well, it only makes sense (or support) when you have several deployment steps in one same pipeline, isn't ?

    Still, we would appreciate being able to to tag each of these different branch pipelines, and steps inside theses pipelines, "test1" "test2" "production" or whatever, so that we can better track these deployments.


  5. Aneita Yang staff

    Hi everyone,

    Thanks for the interest on this issue.

    I'd love to learn more about your different deployment workflows and what you'd like to see out of this feature. If you're interested in discussing your setup and use cases, please reach out to me at ayang@atlassian.com and we can schedule a quick 30 min chat.


  6. Matt Canty

    Hi Aneita,

    Ability to rename: Dev -> UAT -> Production

    Ability to add more: Dev -> UAT -> Staging -> Production

    This would allow us to flexibly align the Bitbucket pipelines with our existing process.

    Thanks Matt

  7. Peter Cresswell

    Agree on need for multiple environments. I run an application with background workers in various environments (all production but different AWS EB environments) so I would love to deploy to each environment in parallel and track the deployments.

  8. Log in to comment