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 (31)

  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. Miroslav Sommer

    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 workflows to just those 3 environments.

    Some of the more stable environments, which are regularly spun up by various teams and various projects are below. Some teams use 2-5 of those, some 6-10, some 20+ different environments.

    CI UAT UAT (External) UAT (Selenium) integration performance training sandbox 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") ...

  9. Taher Dhilawala

    We use bitbucket pipeline to deploy our Backend and Frontend applications with AWS Code deploy and S3 respectively. However, it seems that I can have deployment: staging for only one step for my branch. The way we do it is,

       - deploystagingbackend: &deploystagingbackend
            deployment: staging
       - deploystagingfrontend: &deploystagingfrontend
            deployment: staging
          - *deploystagingbackend
          - *deploystagingfrontend

    But, when we run this, the pipeline fails with error "Invalid deployment value". On removing "deployment: staging" from either step, it works again.

    I guess the way deployments is build, you can only one environment per branch step. If we have the ability to configure environments then we can configure ours as "staging-frontend" and "staging-backend" to get around this issue.

  10. Martin

    Adding our use case to this issue.

    We use environment branches, so development deploys to dev environment, staging to staging and master to prod.

    Within the pipeline, we have parallel steps for building frontend, backend, running tests, etc.

    We would like to be able to tag a full pipeline run to a specific environment. So the development branch pipeline would be tagged as deployment to development environment.

  11. Stephen Hendricks

    @Taher Dhilawala RE: your comment about your stepdefintions: is this documented somewhere where you can define a step definition and call it from multiple places, or were you just writing pseudo code? I can't find anywhere in the documentation as far as the 'stepdefinitions' property.

  12. Joris Vandermeersch

    We need this too. I love Bitbucket Pipelines, but it's very restrictive in some aspects.

    • There's no need to hard-code deployment environment categories as test/staging/production. Instead, maybe allow an optional parameter to define a previous/next environment in the current environment, as in:
      - step:
          deployment: test1
          name: Deploy to test 1
            - <deploy my stuff>
            - staging
            - uat
      - step:
          deployment: test2
          name: Deploy to test 2
            - <deploy my stuff>
            - staging
            - uat
      - step:
          deployment: staging
          name: Deploy to staging
            - <deploy my stuff>
            - demo
      - step:
          deployment: uat
          name: Deploy to UAT
            - <deploy my stuff>
            - production
      - step:
          deployment: production
          name: Deploy to production
            - <deploy my stuff>
    • Furthermore, while admirable, it's silly to enforce people to always deploy in the same order. Sometimes you need to skip the test environment and go straight to staging. Sometimes you have several test environments and you only need to deploy to the second one. And sometimes you've tested everything you can in a branch, then merged that branch to master and you simply know everything will work because it's the same code now, so you really just need to get that to production and you're losing valuable time by waiting for all the other environments to deploy first.

    • Finally, it should be possible to deploy multiple environments at once. Currently you can't put deployment steps in a parallel block, this should be possible.

    In general, the deployments feature tries to fit every project into a test-staging-production sequence where those are the only possible environments, and no environment can be deployed until the previous one has been deployed successfully. Just remove those safeguards, let people decide for themselves how many environments they want and in what order they should be deployed (if they should be deployed at all).

    I understand the current way makes it easy to visualize the deployment process in the web UI, but surely you can figure out a nice visualization that's more flexible as well 😉

  13. Albert Pincevic
    • Dev (interactive developer testing)
    • Test (nightly long running integration tests)
    • UAT staging (test manual changes to salesforce along side our dependent code)
    • UAT
    • Prod staging (test manual changes to salesforce along side our dependent code)
    • Prod
  14. Satvik Sharma

    We currently follow the standard staging and prod environments but as a small team we all have our own test environments and choose which environment to deploy to within the pipeline.

  15. Chad Cook

    Any updates on this? This is a blocking feature for us which is really hurting. Is it being worked on or should we be looking to do to another platform?

  16. Log in to comment