i am trying to build and deploy two separate microservices (api and client) from a monorepo.
i added four environments: api-qa, client-qa, api-prod, and client-prod.
definitions:
steps:
- step: &build-api
name: build-api
condition:
changesets:
includePaths:
- "shared/**"
- "api/**"
script:
- echo build api
- step: &build-client
name: build-client
condition:
changesets:
includePaths:
- "shared/**"
- "api/src/entities/**"
- "client/**"
script:
- echo build client
- step: &deploy-api-qa
name: deploy-api-qa
deployment: api-qa
condition:
changesets:
includePaths:
- "shared/**"
- "api/**"
script:
- echo deploy api to qa
- step: &deploy-client-qa
name: deploy-client-qa
deployment: client-qa
condition:
changesets:
includePaths:
- "shared/**"
- "api/src/entities/**"
- "api/**"
script:
- echo deploy client to qa
- step: &deploy-api-prod
name: deploy-api-prod
deployment: api-prod
trigger: manual
condition:
changesets:
includePaths:
- "shared/**"
- "api/**"
script:
- echo deploy api to prod
- step: &deploy-client-prod
name: deploy-client-prod
deployment: client-prod
trigger: manual
condition:
changesets:
includePaths:
- "shared/**"
- "api/src/entities/**"
- "api/**"
script:
- echo deploy client to prod
pipelines:
default:
- step: *build-api
- step: *build-client
- step: *deploy-api-qa
- step: *deploy-client-qa
- parallel:
- step: *deploy-api-prod
- step: *deploy-client-prod
this *almost* works. i do end up with four different environments, however, the "promote" button acts weirdly. there's no promote button on api-qa and the promote button on client-qa wants to promote to api-prod.
what am i doing wrong here? thanks in advance.
Hello,
Since this question is very technical I suggest you to post this on the developper part of the forum:
https://community.developer.atlassian.com/
I think you'll get more answers and from a better quality!
Hope this help
The problem is that the steps are executed in order. Since `api-prod` comes after `deploy-client-qa`, when it comes time to promote from "qa" to "prod", it executes the first step in "prod".
I sort of fixed this by making putting all "qa" steps under one parallel step and all "prod" steps under another parallel step.
The problem is that I have to finish deploying all the "qa" steps before I can start promoting to "production". But at least I can choose which "qa" step to run, without having to run them in the exact sequence they appear in bitbucket-pipelines.yml.
Unfortunately there does not seem to be a way to be choose to deploy to one "qa" deployment and then promote it to any one of the "prod" deployments.
So in my case, I gave up and declared all my environments as "qa" and just have to be smart about which order to deploy things. All I wanted was an easy way to push my artifact to different servers, that's why I even bothered with Bitbucket Pipelines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi, Iantz moore
I have one query related to this. What I have to do if I want to re-use the deployment environments like TEST, STAGING & PROD, to deploy 20+lambdas. Should I have to define all these lambdas in definitions section of the pipeline?. Please suggest the best way to deploy into multiple environments in multiple times.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.