November 4, 2020
Introducing: Concurrency slot variable
There is no such thing as one correct approach to Continuous Integration and Delivery. It's possible to distinguish some patterns, yes, but each use case is different and depends on many variables: project guidelines, type of Git workflow, experience and skill of developers, etc. etc.
A crucial element to most delivery pipelines is the testing phase, an essential step to delivering high quality, reliable software. More advanced testing, for example, such as integration, browser, or E2E tests, often require deploying the application to a staging environment first. This may cause issues if you are running tests concurrently for different branches or pull requests. As one of our clients put it:
We have multiple projects and each has its own pipeline which is triggered by pull requests to this project and runs automated tests. In our case, if we have concurrent executions, we're able to get the situation when 2 different projects start "pull request" pipelines (with e2e automated tests) at the same time. So, we are not able to set the environment variable to each project. For example, we have 2 different test environments (e.g.
test2). And we need to set up (ideally) that one execution will use
test1and another one will use
$BUDDY_SLOT_NO. The variable holds a unique index that you can easily use to define which staging server it should use.
Let's assume you have 4 concurrent pipeline executions allowed in your workspace. At the moment the first pipeline is run, Buddy automatically populates the value of
$BUDDY_SLOT_NO and sets it to
1. And, accordingly, when the second pipeline is run, the value of
$BUDDY_SLOT_NO will equal
2, the third –
3, and the last one –
4. The fifth execution will be waiting in queue and will receive its slot number at the moment one of the executions has finished.
If you are using staging servers in your CI/CD workflow, we recommend becoming a beta tester of our new Sandboxes v2.0. The feature will let you dynamically create sandbox environments to which you can deploy your application, run tests, share the preview with your customers, and easily destroy the sandbox when it's no longer needed.
Customer Success Manager