작업 실행 방식 제어

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

새로운 파이프라인이 시작되기 전에, GitLab은 파이프라인 구성을 확인하여
어떤 작업이 해당 파이프라인에서 실행될 수 있는지를 결정합니다.
변수의 값이나 파이프라인 유형과 같은 조건에 따라 작업이 실행되도록 구성할 수 있습니다.
rules로 설정 가능합니다.

수동으로 실행해야 하는 작업 만들기

작업이 사용자가 시작하지 않으면 실행되지 않도록 요구할 수 있습니다.
이것을 수동 작업이라고 합니다.
프로덕션에 배포하는 것과 같은 작업에 수동 작업을 사용하려고 할 수 있습니다.

작업을 수동으로 지정하려면, .gitlab-ci.yml 파일의 작업에
when: manual를 추가하세요.

기본적으로, 수동 작업은 파이프라인이 시작될 때 생략된 것으로 표시됩니다.

보호된 브랜치를 사용하여
무단 사용자가 수동 배포를 실행하지 못하도록
보다 엄격하게 수동 작업 보호할 수 있습니다.

수동 작업의 유형

수동 작업은 선택적이거나 차단 될 수 있습니다.

선택적 수동 작업의 경우:

  • allow_failure가 true로 설정되며, 이는 rules 외부에 when: manual이 정의된 작업의 기본 설정입니다.
  • 상태가 전체 파이프라인 상태에 기여하지 않습니다. 모든 수동 작업이 실패해도
    파이프라인은 성공할 수 있습니다.

차단 수동 작업의 경우:

  • allow_failure가 false로 설정되며, 이는 rules 내에 when: manual이 정의된 작업의 기본 설정입니다.
  • 작업이 정의된 단계에서 파이프라인이 중지됩니다. 파이프라인이 계속 실행되도록 하려면,
    수동 작업을 실행하세요.
  • 파이프라인 성공 필수를 활성화한 프로젝트에서
    차단된 파이프라인에 대해 병합할 수 없습니다.
  • 파이프라인은 차단됨 상태를 표시합니다.

strategy: depend를 사용하는 트리거된 파이프라인에서 수동 작업을 사용할 때,
수동 작업의 유형은 파이프라인이 실행되는 동안 트리거 작업의 상태에 영향을 줄 수 있습니다.

수동 작업 실행

수동 작업을 실행하려면, 할당된 브랜치에 병합할 수 있는 권한이 있어야 합니다:

  1. 파이프라인, 작업, 환경 또는 배포 보기로 이동합니다.
  2. 수동 작업 옆에 있는 실행 ( )를 선택합니다.

수동 작업을 실행할 때 사용자 정의 CI/CD 변수 추가도 가능합니다.

수동 작업을 위한 확인 대화 상자 추가

수동 작업에 대해 확인 대화 상자를 추가하려면,
when: manual와 함께 manual_confirmation을 사용하세요.
확인 대화 상자는 특히 프로덕션에 배포하는 것과 같은 민감한 작업에 대해
우발적인 배포 또는 삭제를 방지하는 데 도움이 됩니다.

사용자는 수동 작업이 실행되기 전에 작업을 확인하라는 메시지를 받으며,
이는 추가적인 안전층과 제어 기능을 제공합니다.

수동 작업 보호

Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

보호된 환경을 사용하여
수동 작업을 실행할 수 있는 사용자 목록을 정의할 수 있습니다.
보호된 환경에 연결된 사용자만 수동 작업을 트리거하도록 허용할 수 있으며, 이는:

  • 환경에 배포할 수 있는 대상을 보다 정확히 제한합니다.
  • 승인된 사용자가 “승인”할 때까지 파이프라인을 차단합니다.

수동 작업을 보호하려면:

  1. 작업에 environment를 추가합니다. 예를 들면:

    deploy_prod:
  stage: deploy
  script:
    - echo "생산 서버에 배포"
  environment:
    name: production
    url: https://example.com
  when: manual
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

  2. 보호된 환경 설정에서
    예를 들어 (production) 환경을 선택하고,
    수동 작업을 트리거할 수 있는 사용자, 역할 또는 그룹을 배포 허용 목록에 추가합니다.
    이 목록에 있는 사용자만 이 수동 작업을 트리거할 수 있으며,
    GitLab 관리자는 항상 보호된 환경을 사용할 수 있습니다.

차단 수동 작업과 함께 보호된 환경을 사용하여
나중에 파이프라인 단계를 승인할 수 있는 사용자 목록을 가지고 있을 수 있습니다.
보호된 수동 작업에 allow_failure: false를 추가하고,
파이프라인의 다음 단계는 인증된 사용자가 수동 작업을 트리거한 후에만 실행됩니다.

지연 후 작업 실행

when: delayed를 사용하여 대기 기간 후에 스크립트를 실행하거나 작업이 즉시 pending 상태로 들어가지 않도록 할 수 있습니다.

start_in 키워드를 사용하여 기간을 설정할 수 있습니다. start_in의 값은 초 단위의 경과 시간이며, 단위가 제공되지 않는 경우입니다. 최소 1초, 최대 1주입니다. 유효한 값의 예시는 다음과 같습니다:

  • '5' (단위가 없는 값은 작은 따옴표로 둘러싸여야 합니다)
  • 5 seconds
  • 30 minutes
  • 1 day
  • 1 week

단계에 지연 작업이 포함된 경우, 파이프라인은 지연 작업이 완료될 때까지 진행되지 않습니다.

이 키워드를 사용하여 서로 다른 단계 간에 지연을 삽입할 수 있습니다.

지연 작업의 타이머는 이전 단계가 완료된 직후에 시작됩니다. 다른 유형의 작업과 마찬가지로, 지연 작업의 타이머는 이전 단계가 통과되지 않으면 시작되지 않습니다.

다음 예시는 이전 단계가 완료된 후 30분 후에 실행되는 timed rollout 10%라는 작업을 생성합니다:

timed rollout 10%:
  stage: deploy
  script: echo 'Rolling out 10% ...'
  when: delayed
  start_in: 30 minutes
  environment: production

활성화된 지연 작업의 타이머를 중지하려면 Unschedule ( )를 선택하세요. 이 작업은 더 이상 자동으로 실행되도록 예약할 수 없습니다. 그러나 수동으로 작업을 실행할 수 있습니다.

지연 작업을 수동으로 시작하려면 Unschedule ( )를 선택하여 지연 타이머를 중지한 후 Run ( )을 선택하세요. 곧 GitLab Runner가 작업을 시작합니다.

대규모 작업 병렬화

대규모 작업을 여러 개의 작은 작업으로 나누어 병렬로 실행하려면 .gitlab-ci.yml 파일에서 parallel 키워드를 사용하세요.

다양한 언어 및 테스트 스위트는 병렬화를 활성화하는 다양한 방법을 가지고 있습니다. 예를 들어, Semaphore Test Boosters와 RSpec를 사용하여 Ruby 테스트를 병렬로 실행할 수 있습니다:

# Gemfile
source 'https://rubygems.org'

gem 'rspec'
gem 'semaphore_test_boosters'

test:
  parallel: 3
  script:
    - bundle
    - bundle exec rspec_booster --job $CI_NODE_INDEX/$CI_NODE_TOTAL

그런 다음 새 파이프라인 빌드의 Jobs 탭으로 이동하여 RSpec 작업이 세 개의 별도의 작업으로 나뉘어 있는 것을 확인할 수 있습니다.

경고: Test Boosters는 작성자에게 사용 통계를 보고합니다.

일차원 병렬 작업 행렬 실행

하나의 파이프라인에서 작업을 여러 번 병렬로 실행하되, 각 작업의 인스턴스에 대해 서로 다른 변수 값을 사용하려면 parallel:matrix 키워드를 사용하세요:

deploystacks:
  stage: deploy
  script:
    - bin/deploy
  parallel:
    matrix:
      - PROVIDER: [aws, ovh, gcp, vultr]
  environment: production/$PROVIDER

병렬 트리거 작업 행렬 실행

단일 파이프라인에서 trigger 작업을 여러 번 병렬로 실행하되, 각 작업의 인스턴스에 대해 서로 다른 변수 값을 사용하여 실행할 수 있습니다.

deploystacks:
  stage: deploy
  trigger:
    include: path/to/child-pipeline.yml
  parallel:
    matrix:
      - PROVIDER: aws
        STACK: [monitoring, app1]
      - PROVIDER: ovh
        STACK: [monitoring, backup]
      - PROVIDER: [gcp, vultr]
        STACK: [data]

이 예시는 6개의 병렬 deploystacks 트리거 작업을 생성하며, 각 작업은 PROVIDER 및 STACK 값이 다르며, 이러한 변수를 가진 6개의 서로 다른 하위 파이프라인을 생성합니다.

deploystacks: [aws, monitoring]
deploystacks: [aws, app1]
deploystacks: [ovh, monitoring]
deploystacks: [ovh, backup]
deploystacks: [gcp, data]
deploystacks: [vultr, data]

각 병렬 매트릭스 작업에 대한 서로 다른 러너 태그 선택

parallel: matrix에서 정의된 변수를 tags 키워드와 함께 사용하여 동적 러너 선택을 할 수 있습니다:

deploystacks:
  stage: deploy
  script:
    - bin/deploy
  parallel:
    matrix:
      - PROVIDER: aws
        STACK: [monitoring, app1]
      - PROVIDER: gcp
        STACK: [data]
  tags:
    - ${PROVIDER}-${STACK}
  environment: $PROVIDER/$STACK

parallel:matrix 작업에서 아티팩트 가져오기

parallel:matrix로 생성된 작업에서 아티팩트를 가져오려면 dependencies 키워드를 사용해야 합니다.

dependencies의 값으로는 문자열 형식으로 작업 이름을 사용합니다:

<job_name> [<matrix argument 1>, <matrix argument 2>, ... <matrix argument N>]

예를 들어, RUBY_VERSION이 2.7이고 PROVIDER가 aws인 작업에서 아티팩트를 가져오려면 다음과 같이 작성합니다:

ruby:
  image: ruby:${RUBY_VERSION}
  parallel:
    matrix:
      - RUBY_VERSION: ["2.5", "2.6", "2.7", "3.0", "3.1"]
        PROVIDER: [aws, gcp]
  script: bundle install

deploy:
  image: ruby:2.7
  stage: deploy
  dependencies:
    - "ruby: [2.7, aws]"
  script: echo hello
  environment: production

dependencies 항목에 대한 인용부호는 필수입니다.

여러 병렬화된 작업을 사용하는 needs를 통한 병렬화된 작업 지정

여러 병렬화된 작업과 함께 needs:parallel:matrix에서 정의된 변수를 사용할 수 있습니다.

예를 들어:

linux:build:
  stage: build
  script: echo "Linux 빌드 중..."
  parallel:
    matrix:
      - PROVIDER: aws
        STACK:
          - monitoring
          - app1
          - app2

mac:build:
  stage: build
  script: echo "Mac 빌드 중..."
  parallel:
    matrix:
      - PROVIDER: [gcp, vultr]
        STACK: [data, processing]

linux:rspec:
  stage: test
  needs:
    - job: linux:build
      parallel:
        matrix:
          - PROVIDER: aws
            STACK: app1
  script: echo "Linux에서 rspec 실행 중..."

mac:rspec:
  stage: test
  needs:
    - job: mac:build
      parallel:
        matrix:
          - PROVIDER: [gcp, vultr]
            STACK: [data]
  script: echo "Mac에서 rspec 실행 중..."

production:
  stage: deploy
  script: echo "프로덕션 실행 중..."
  environment: production

이 예시는 여러 작업을 생성합니다. 병렬 작업은 각각 다른 PROVIDER와 STACK 값을 가집니다.

  • 3개의 병렬 linux:build 작업:
    • linux:build: [aws, monitoring]
    • linux:build: [aws, app1]
    • linux:build: [aws, app2]
  • 4개의 병렬 mac:build 작업:
    • mac:build: [gcp, data]
    • mac:build: [gcp, processing]
    • mac:build: [vultr, data]
    • mac:build: [vultr, processing]
  • linux:rspec 작업 1개.
  • production 작업 1개.

작업은 세 가지 실행 경로를 가집니다:

  • 리눅스 경로: linux:build: [aws, app1] 작업이 종료되는 즉시 linux:rspec 작업이 실행되며, mac:build 작업이 완료될 때까지 기다리지 않습니다.

  • macOS 경로: mac:build: [gcp, data]와 mac:build: [vultr, data] 작업이 완료되는 즉시 mac:rspec 작업이 실행되며, linux:build 작업이 완료될 때까지 기다리지 않습니다.

  • production 작업은 모든 이전 작업이 완료되는 즉시 실행됩니다.