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. test1 and test2). And we need to set up (ideally) that one execution will use test1 and another one will use test2.
Success
To help you solve this, we have added a new Environment Variable called $BUDDY_SLOT_NO. The variable holds a unique index that you can easily use to define which staging server it should use.

Use case

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.

Tip
Since you know which slot the execution takes, you can use the variable to define the server to which you want to deploy your application.

Image loading...

Sandboxes as staging environments

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.

Hint
To become a beta tester, drop an email to support@buddy.works or leave a message on our live-chat with the URL to our account. You are also welcome to sign up to our upcoming webinar on sandboxes (date yet TBA)
Warning
Buddy is 100% customer driven. If there’s a feature or integration you miss, let us know in the comments below or directly at support@buddy.works.
Jarek Dylewski

Jarek Dylewski

Customer Support

A journalist and an SEO specialist trying to find himself in the unforgiving world of coders. Gamer, a non-fiction literature fan and obsessive carnivore. Jarek uses his talents to convert the programming lingo into a cohesive and approachable narration.

Previous pageSandboxes v2.0: Multiple port mapping & authorizationNext pageDocker Hub pull limit in Buddy Self-Hosted
Nov 4th 2020
Share