GitLabInsights

리소스 그룹 소개

Source: GitLab Blog | Author: Chirissie Buchanan

GitLab CI/CD 파이프라인은 DevOps 수명 주기의 모든 단계에서 통합된 단일 워크플로의 일부로 코드를 빌드, 테스트 및 배포합니다. 우리 GitLab 팀은 고객들이 더 나은 소프트웨어를 더 신속하게 배포할 수 있도록 하고 싶고 GitLab을 개선시키기 위해 새로운 기능과 기존 기능을 지속적으로 반복(iterate)합니다.

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.

Resource groups response

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.”

waiting on 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

댓글 남기기