작업 실행 방식 제어하기

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

새로운 파이프라인이 시작되기 전에 GitLab은 파이프라인 구성을 확인하여 해당 파이프라인에서 실행할 작업을 결정합니다. rules를 사용하여 변수의 값이나 파이프라인 유형과 같은 조건에 따라 작업을 구성할 수 있습니다.

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

작업이 사용자에 의해 시작되지 않으면 실행되지 않도록 할 수 있습니다. 이를 수동 작업이라고 합니다. 이와 같은 경우에는 배포와 같은 작업에 사용하고 싶을 것입니다.

작업을 수동으로 지정하려면 .gitlab-ci.yml 파일의 작업에 when: manual을 추가하십시오.

기본적으로 수동 작업은 파이프라인이 시작될 때 건너뛰어진 것으로 표시됩니다.

권한 없는 사용자가 수동 배포를 실행하지 못하도록 protected branches를 사용할 수 있습니다.

수동 작업의 유형

수동 작업은 선택 사항 또는 차단 옵션일 수 있습니다.

선택 사항이 있는 수동 작업:

  • 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

protected environments를 사용하여 수동 작업을 실행할 수 있는 사용자 목록을 정의할 수 있습니다. 수동 작업을 실행할 수 있는 사용자는 보호된 환경과 관련된 사용자로 제한할 수 있으며 이로써 다음과 같은 것들이 가능합니다:

  • 환경으로의 배포를 제한할 수 있음.
  • 승인된 사용자가 승인할 때까지 파이프라인을 차단할 수 있음.

수동 작업을 보호하려면:

  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은 이 예시에서)을 선택하고, 허용된 배포 목록에 권한이 부여된 사용자, 역할 또는 그룹을 추가하십시오. 이 목록에 있는 사용자만이 이 수동 작업을 실행할 수 있으며, protected environments를 항상 사용할 수 있는 GitLab 관리자도 포함됩니다.

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

지연 후 작업 실행하기

작업이 일정 시간 대기한 후에 스크립트를 실행하거나 작업이 즉시 대기 중 상태로 들어가는 것을 피하려면 when: delayed를 사용하십시오.

start_in 키워드로 기간을 설정할 수 있습니다. start_in의 값은 초 단위의 경과 시간으로 제공되며, 단위가 제공되지 않으면 최소 1초에서 최대 1주까지의 유효한 값입니다.

다음은 이전 단계 완료 후 30분 후에 실행되는 timed rollout 10%이라는 작업을 만드는 예제입니다: 

timed rollout 10%:
  stage: deploy
  script: echo '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

병렬 트리거 작업 행렬 실행

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

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]

이 예제는 PROVIDER와 STACK에 대해 각기 다른 값이 있는 6개의 병렬 deploystacks 트리거 작업을 생성하며, 해당 변수로 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 "리눅스 빌드 중..."
  parallel:
    matrix:
      - PROVIDER: aws
        STACK:
          - monitoring
          - app1
          - app2

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

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

mac:rspec:
  stage: test
  needs:
    - job: mac:build
      parallel:
        matrix:
          - PROVIDER: [gcp, vultr]
            STACK: [data]
  script: echo "맥에서 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 작업
  • mac:rspec 작업

작업은 세 가지 실행 경로가 있습니다.

  • 리눅스 경로: linux:build: [aws, app1] 작업이 완료되자마자 linux:rspec 작업이 실행되며 mac:build의 완료를 기다리지 않습니다.
  • macOS 경로: mac:build: [gcp, data] 및 mac:build: [vultr, data] 작업이 완료되자마자 mac:rspec 작업이 실행되며 linux:build의 완료를 기다리지 않습니다.
  • 모든 이전 작업이 완료되자마자 production 작업이 실행됩니다.