We are using Bitbucket Pipelines as a CI/CD service. I am trying to deal with one inconvenience --> The inability to trigger multiple concurrent deployments with the same name. BB docs
Consider the following example:
stepdefinitions:
- prepare-and-test: &prepare-and-test
name: Prepare and Test
script:
- export DEV_ENV="${BITBUCKET_BRANCH}"
- Do some other stuff
- build-and-deploy: &build-and-deploy
name: Build and Deploy
deployment: personal-dev-env
script:
- export DEV_ENV="${BITBUCKET_BRANCH}"
- Do some other stuff
pipelines:
branches:
dev-*:
- step: *prepare-and-test
- step: *build-and-deployExplination:
dev-$some_integer is a git branch and corresponds to a particular developer in our organization but also corresponds to his personal develop environment. The idea here is whenever a code change is made --> trigger BitBucket pipeline that will reflect this change on the corresponding env/server.
Example:
Let's say we have 3 repos - webserver, php, database.
Now dev-3 wants to change his webserver config, so he checks out dev-3 branch in webserver repo --> makes changes --> pushes to dev-3 branch --> His changes are automatically deployed to dev-3 env/server.
So far so good, however let's imagine we have 100 developers/branches and want to make one change and deploy it to all dev envs. Example:
Let's checkout master branch --> make the change --> push
Now let's merge master branch into all dev-** branches (let's say they are 100) so that the change is reflected on all dev environments.
This is where the inconvenience happens, as BitBucket attempts to start 100 pipelines with a deployment with the same name and refuses to do so. The end result is that 99 pipelines are now paused and expect a manual action to be resumed. This means one should wait for each pipeline just to click 'Resume' button on the 'Paused' pipeline.
I can totally agree that this restriction is there for a very good reason, however it's just not potentially destructive in any way for my particular use case.
I was therefore disappointed to find out that there's no way to skip/ignore this enforcement, OR just auto-resume paused pipeliens.
To deal with this we have currently created 100 environments both in the repository settings (BitBucket GUI menu) with a differant name and have this in our bitbucket-pipelines.yaml :
pipelines:
branches:
dev-1:
- step: *prepare-and-test
- step:
<<: *build-and-deploy
deployment: personal-dev-01
dev-2:
- step:
<<: *build-and-deploy
deployment: personal-dev-02
etc..This approach totally deals with the pauses, as the deployments now have differant names and they can run concurrently . However, what i don't like about this approach is that if another 10 developers join us --> another 10 BitBucket environments should be added in BB UI (repository settings) and 10 more branches must be explicitly specified in the bitbucket-pipelines.yaml. And this is per repo ! (Obviously this doesn't look sane ...)
I thought about using ${BITBUCKET_BRANCH} variable to dynamically specify the deployment's name based on branch, something like this:
deployment: personal-dev-"${BITBUCKET_BRANCH}"However i found that BB vars won't expand in the scope i wanted them too.
Another idea would be to use nodejs/husky to trigger a git hook that will edit the bitbucket-pipelines.yaml file based on checked-out branch whenever a merge is made. (Or something similar)
However i feel this is totally going in the wrong direction and there must be a simpler, cleaner way to :
- Specify deployment name in bitbucket-pipelines.yaml dynamically, based on checked-out branch. Or
- Deal with the pauses in another way entirely ?
I do hope my question is clear enough, but let me know if additional explination is needed somewhere.
