f4dbaae2a132 I dont know why this is closed. Issues are still around after +5 years.

https://community.atlassian.com/t5/Bitbucket-questions/Usage-of-Deployment-variables-on-multiple-steps/qaq-p/1103443?anon_like=2238885#U2948012

d7fa1e6e13fa naaah, not at all. You're using the framework to build something completely new. I must say I'm pretty happy with the results. I wrote an article on this.

https://medium.com/@jedfra6/how-i-finally-solved-cicd-in-bitbucket-after-2-years-of-trying-080e2159a798

Since that time I also solved an issue with admin checks for specific jobs, which is great. 

Would I prefer to have all that ootb in Bitbucket - for sure. But I'm happy at least I have tools at hand to help me go forward

badacfdb410f Dynamic Pipelines are indeed powerful, but building your own pipeline engine on top of Bitbucket Pipelines seems like using TypeScript to write JavaScript. It's all bells and whistles, until you realize you have to implement TypeScript yourself first.

This is not a solution, and Atlassian should just do better in providing basic functionality all modern (and old ) CICD platforms provide for years.

If it's of any help - if any of you have Bitbucket Premium, you should be able to solve those problems with Bitbucket Dynamic Pipelines. That's what I did. 

So in my usecase stages was a good alternative, but then parallel steps within a stage isn't supported....bleh. One alternative after another alternative after another for things to barely work. +1 to 64cb4dfcddfb's comment the other day. This is why I'm moving my pipelines to gitlab instead.

I think what we all need to understand is that our friends at Atlassian have their hands full making changes of dubious value to their UIs.  Why would they work on making their tools do a better job of meeting our actual requirements when they can just move UI elements around to make them harder to find?

+1

Amazing how many basic features which are staples of CI/CD development are just not allowed, or a limitation, or totally impossible in Bitbucket pipelines. Do Atlassian realise that their main competititors in this space i.e. GitHub/GitLab are totally blowing Bitbucket pipelines in the middle of last decade. This ticket and dozens or so other tickets to allow for basic stuff, like variablising deployment variables, allowing conditional steps, deployments with parallel steps, more than one step with a deployment in a stage and other very simple capabilities to implement is really hindering the ability for engineers to use Bitbucket pipelines properly. These tickets have been open for literally years, with no updates, no comments from anyone at Atlassian and it's very poor.

Do "Dynamic Pipelines" solve any of this? 

"Stage" does not solve the issue when looking at more complex pipelines, where you would want multiple steps to be grouped under a stage but you would want to be able to have manual trigger or conditions on the steps as well. It is still a big limitation and definitely unresolved.

I don't believe the `stage` solution works for my use case where I would also like to share deployment across multiple steps. We are using our BB pipeline to plan and apply terraform changes across multiple environment. In this case, we want to group our steps by "terraform plan" for all regions then group steps by "terraform apply" for all regions. We would like to share deployment across two different parallel steps that cannot be grouped by 'stage'.

This will allow us to review the terraform plan for all regions before applying it.

See example below.

---
definitions:
  - step: &plan
      script:
        - make save_plan CELL_ID=$CELL_ID UNIT=pipeline AWS_ACCOUNT=$AWS_ACCOUNT
  - steps: &apply
      script:
        - make apply_plan CELL_ID=$CELL_ID UNIT=pipeline AWS_ACCOUNT=$AWS_ACCOUNT
        
pipelines:
  default:
    - parallel:
        - step:
            <<: *plan
            name: "Plan dev region-1"
            deployment: dev-region-1
        - step:
            <<: *plan
            name: "Plan dev region-2"
            deployment: dev-region-2
    - step:
        name: "Apply all the things in Internal Dev"
        trigger: manual
        script:
          - "true"
    - parallel:
        - step:
            <<: *apply
            name: "Apply dev region-1"
            deployment: dev-region-1
        - step:
            <<: *apply
            name: "Apply dev region-2"
            deployment: dev-region-2