GitLab CI/CD pipelines build, test, deploy your code as part of a single workflow integrated across all stages of the DevOps lifecycle. Ultimately, we want to enable teams to deploy better software faster to their customers, and we do that by continually iterating on new and existing features to improve the GitLab experience.
Continuous delivery is all about making sure that CI-validated code goes through a structured deployment pipeline. While GitLab CI continues to be a top-rated solution in continuous integration, we want our continuous delivery capabilities to be just as loved and feedback from the GitLab community plays a big role in how we improve the user experience.
At GitLab, everything we do is public by default. This allows us to collaborate and share ideas, documentation, examples, and processes with the whole community. The original idea of limiting pipeline concurrency using resource groups was introduced by @inem in a public issue and the response was certainly enthusiastic.
For some users, they found that running multiple pipelines and/or jobs at the same time in an environment would lead to errors. Some pipelines and/or jobs use unique resources, and concurrent deployments meant that multiple users were affecting the environment with some unintended consequences.
Example:
Let's say your team is developing a mobile app and you deploy it for testing purposes to a physical smartphone on a Friday afternoon. Maybe you're a startup and only have one or two phones for this purpose. You may need to clear the cache and delete the app before downloading it again so you can start the test clean. But what if in the middle of your test, someone else decides to clear the data on that device? Situations like this would inevitably cause errors, leaving teams with little choice but to coordinate these deployments amongst themselves.
We’re always working hard to enable speedy, reliable pipelines. Coming to GitLab 12.7, available tomorrow, we’re introducing the resource_group attribute to projects so that only one job can deploy to a specific resource group at any given time. This will improve deployment flows, especially when deploying to physical environments.
If we go back to the mobile phone example, the phone would be it’s own resource_group and will only have one deployment at a time. If another deployment were to try and run on this device, the job will be queued until the first job is finished with the message “waiting for resource.”
Teams can define multiple resource_group(s) for their environment in .gitlab-ci.yml. Even if running separate pipelines, as long as a resource_group is assigned then the jobs will not run concurrently. Tools like Terraform similarly help users manage concurrencies by limiting resources.
As we continue to improve and iterate on our product vision for continuous delivery, we’ll be looking to make future improvements to resource groups and deployment environments. Some of our plans include implicit environment locking, only allowing forward incremental deployments, and the flexibility to define concurrency values (the default of 1 can’t be configured in this release).
Please join us in our public epic where we discuss continuous delivery and feel free to give feedback or suggestions on ways we can improve deployments. Everyone can contribute.
Cover image by mostafa meraji on Unsplash
