환경에 코드 버전을 배포하면 배포(deployment)가 생성됩니다. 일반적으로 환경당 활성 배포는 하나만 존재합니다.

GitLab은 다음을 제공합니다.

• 각 환경에 대한 배포의 전체 히스토리를 제공합니다.
• 배포를 추적하므로 서버에 무엇이 배포되어 있는지 항상 알 수 있습니다.

프로젝트에 Kubernetes 같은 배포 서비스가 연결되어 있다면, 이를 사용해 배포를 지원할 수 있습니다.

배포가 생성된 후에는 이를 사용자에게 롤아웃할 수 있습니다.

수동 배포 구성#

사람이 수동으로 배포를 시작해야 하는 job을 만들 수 있습니다. 예시는 다음과 같습니다.

deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  environment:
    name: production
    url: https://example.com
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

when: manual 액션은 다음과 같은 역할을 합니다.

• GitLab UI에서 해당 job에 대해 실행([play]) 버튼을 노출하며, Can be manually deployed to <environment> 텍스트가 함께 표시됩니다.
• deploy_prod job을 수동으로 트리거해야 함을 의미합니다.

실행([play]) 버튼은 파이프라인, 환경, 배포, job 뷰에서 찾을 수 있습니다.

배포별로 새로 포함된 머지 리퀘스트 추적#

GitLab은 배포별로 새로 포함된 머지 리퀘스트를 추적할 수 있습니다. 배포가 성공하면 시스템은 최신 배포와 이전 배포 사이의 커밋 diff를 계산합니다. 추적 정보는 배포 API 로 가져오거나, 머지 리퀘스트 페이지의 머지 후 파이프라인에서 확인할 수 있습니다.

추적을 활성화하려면 다음 중 하나를 충족하도록 환경을 구성합니다.

• 환경 이름이 /를 사용하는 폴더 형태가 아닌 경우입니다(장기 유지되는 환경 또는 최상위 환경).

• 환경 티어가 production 또는 staging 인 경우입니다.

  다음은 .gitlab-ci.yml에서 environment 키워드를 사용하는 구성 예시입니다.

  # Trackable
  environment: production
  environment: production/aws
  environment: development
  
  # Non Trackable
  environment: review/$CI_COMMIT_REF_SLUG
  environment: testing/aws
  

구성 변경 사항은 새 배포에만 적용됩니다. 기존 배포 레코드는 머지 리퀘스트가 연결되거나 연결 해제되지 않습니다.

로컬에서 배포 확인#

각 배포마다 Git 리포지터리에 참조가 저장되므로, 현재 환경의 상태를 파악하려면 git fetch 한 번이면 충분합니다.

Git 구성에서 [remote "<your-remote>"] 블록에 다음 fetch 라인을 추가합니다.

fetch = +refs/environments/*:refs/remotes/origin/environments/*

오래된 배포 아카이브#

프로젝트에서 새 배포가 발생하면 GitLab은 배포에 대한 특수 Git ref를 생성합니다. 이 Git ref는 원격 GitLab 리포지터리로부터 채워지기 때문에, 프로젝트의 배포 수가 늘어날수록 git-fetch·git-pull 같은 일부 Git 작업이 느려질 수 있습니다.

Git 작업의 효율성을 유지하기 위해 GitLab은 최근 배포 ref 만(최대 50,000개) 유지하고 나머지 오래된 배포 ref는 삭제합니다. 아카이브된 배포는 감사 목적으로 UI 또는 API를 통해 계속 사용할 수 있습니다. 또한 아카이브된 이후에도 커밋 SHA를 지정하면(예: git checkout <deployment-sha>) 리포지터리에서 배포된 커밋을 계속 가져올 수 있습니다.

배포 롤백#

특정 커밋으로 배포를 롤백하면 새 배포가 생성됩니다. 이 배포는 고유한 job ID를 가집니다. 이 배포는 롤백 대상 커밋을 가리킵니다.

롤백이 성공하려면 배포 프로세스가 job의 script에 정의되어 있어야 합니다.

배포 job만 실행됩니다. 이전 job 이 생성한 아티팩트를 배포 시점에 다시 생성해야 하는 경우, 파이프라인 페이지에서 필요한 job을 수동으로 실행해야 합니다. 예를 들어 Terraform을 사용하고 plan과 apply 명령이 여러 job으로 분리되어 있다면, 배포하거나 롤백하려면 해당 job을 수동으로 실행해야 합니다.

배포 재시도 또는 롤백#

배포에 문제가 있는 경우 재시도하거나 롤백할 수 있습니다.

배포를 재시도하거나 롤백하는 방법은 다음과 같습니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Operate > Environments를 선택합니다.
3. 환경을 선택합니다.
4. 배포 이름 오른쪽에서 다음을 수행합니다.
   • 배포를 재시도하려면 Re-deploy to environment를 선택합니다.
   • 이전에 성공한 배포로 롤백하려면 해당 배포 옆의 Rollback environment를 선택합니다.

관련 주제#

• 환경
• 배포를 위한 다운스트림 파이프라인
• GitLab CI/CD로 여러 환경에 배포하기(블로그 게시물)
• 리뷰 앱
• 외부 배포 도구의 배포 추적

문제 해결#

배포 작업 중 다음과 같은 문제가 발생할 수 있습니다.

배포 ref를 찾을 수 없음#

GitLab은 Git 리포지터리의 성능을 유지하기 위해 오래된 배포 ref를 삭제합니다.

GitLab Self-Managed에서 아카이브된 Git ref를 복원해야 하는 경우, 관리자에게 Rails 콘솔에서 다음 명령을 실행하도록 요청합니다.

Project.find_by_full_path(<your-project-full-path>).deployments.where(archived: true).each(&:create_ref)

GitLab은 성능 문제로 인해 향후 이 지원을 중단할 수 있습니다. 이 기능의 동작 방식에 대해 논의하고 싶다면 GitLab 이슈 트래커에서 이슈를 생성할 수 있습니다.