릴리스
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
중요한 마일스톤에서 프로젝트를 패키징하기 위한 릴리스를 만듭니다. 릴리스와 관련된 Git 태그를 삭제하면 릴리스도 삭제됩니다. 릴리스를 만들 때 또는 그 이후에 다음을 할 수 있습니다: 왼쪽 사이드바에서 Deploy > Releases를 선택하거나,
중요한 마일스톤에서 프로젝트를 패키징하기 위한 릴리스를 만듭니다. 릴리스는 코드, 바이너리, 문서 및 릴리스 노트를 프로젝트의 완전한 스냅샷으로 결합합니다. 릴리스가 만들어지면 GitLab이 자동으로 코드에 태그를 지정하고, 스냅샷을 아카이브하고, 감사에 적합한 증거를 생성합니다. 이는 규정 준수 요구 사항에 완벽하고 개발 프로세스에 대한 사용자의 신뢰를 줄 수 있는 영구적인 기록을 만듭니다.
사용자는 다음의 혜택을 받습니다:
- 최신 안정 버전 및 설치 패키지에 쉽게 액세스
- 새 기능 및 수정 사항에 대한 명확한 문서
- 해당 에셋과 함께 특정 버전을 다운로드할 수 있는 기능
- 시간 경과에 따른 프로젝트 진화를 추적하는 간단한 방법
릴리스와 관련된 Git 태그를 삭제하면 릴리스도 삭제됩니다.
릴리스를 만들 때 또는 그 이후에 다음을 할 수 있습니다:
릴리스 보기#
릴리스 목록을 보려면:
-
왼쪽 사이드바에서 Deploy > Releases를 선택하거나,
-
프로젝트 개요 페이지에서 릴리스가 하나 이상 있으면 릴리스 수를 선택합니다.
- 공개 프로젝트에서는 이 수가 모든 사용자에게 표시됩니다.
- 비공개 프로젝트에서는 최소 Reporter 권한이 있는 사용자에게 이 수가 표시됩니다.
릴리스 정렬#
Released date 또는 Created date로 릴리스를 정렬하려면 정렬 순서 드롭다운 목록에서 선택합니다. 오름차순과 내림차순 사이를 전환하려면 Sort order를 선택합니다.
최신 릴리스에 대한 영구 링크#
영구 링크를 통해 최신 릴리스 페이지에 액세스할 수 있습니다. GitLab은 항상 영구 링크 URL을 최신 릴리스 페이지 주소로 리디렉션합니다.
URL 형식:
https://gitlab.example.com/namespace/project/-/releases/permalink/latest
영구 링크 URL에 접미사를 추가할 수도 있습니다. 예를 들어, 최신 릴리스가 gitlab-org 네임스페이스와 gitlab-runner 프로젝트의 v17.7.0#release인 경우 읽기 가능한 링크는 다음과 같습니다:
https://gitlab.com/gitlab-org/gitlab-runner/-/releases/v17.7.0#release
다음 영구 링크로 최신 릴리스 URL에 액세스할 수 있습니다:
https://gitlab.com/gitlab-org/gitlab-runner/-/releases/permalink/latest#release
릴리스 에셋에 영구 링크를 추가하는 방법에 대한 내용은 최신 릴리스 에셋에 대한 영구 링크를 참조하세요.
정렬 기본 설정#
기본적으로 GitLab은 released_at 시간을 사용하여 릴리스를 가져옵니다. 쿼리 매개변수 ?order_by=released_at 사용은 선택 사항이며, ?order_by=semver 지원은 이 이슈에서 추적됩니다.
RSS 피드로 릴리스 추적#
GitLab은 Atom 형식으로 프로젝트의 릴리스 RSS 피드를 제공합니다. 피드를 보려면:
- 구성원인 프로젝트의 경우:
- 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- Deploy > Releases를 선택합니다.
- 모든 프로젝트의 경우:
- Project overview 페이지로 이동합니다.
- 오른쪽 사이드바에서 Releases ([rocket-launch])를 선택합니다.
- 오른쪽 상단 모서리에서 피드 기호 ([rss])를 선택합니다.
릴리스 만들기#
릴리스를 만들 수 있는 방법:
Releases 페이지에서 릴리스 만들기#
사전 요구 사항:
- 프로젝트에 대한 Developer, Maintainer 또는 Owner 권한이 있어야 합니다. 자세한 내용은 릴리스 권한을 참조하세요.
Releases 페이지에서 릴리스를 만들려면:
- 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- Deploy > Releases를 선택하고 New release를 선택합니다.
- Tag name 드롭다운 목록에서 다음 중 하나를 수행합니다:
- 기존 Git 태그를 선택합니다. 이미 릴리스와 관련된 기존 태그를 선택하면 유효성 검사 오류가 발생합니다.
- 새 Git 태그 이름을 입력합니다.
- Create tag 팝오버에서 새 태그를 만들 때 사용할 브랜치 또는 커밋 SHA를 선택합니다.
- 선택 사항. Set tag message 텍스트 상자에 어노테이션 태그를 만들기 위한 메시지를 입력합니다.
- Save를 선택합니다.
- 선택 사항. 다음을 포함하여 릴리스에 대한 추가 정보를 입력합니다:
- Create release를 선택합니다.
CI/CD Job을 사용하여 릴리스 만들기#
Job 정의에서 release 키워드를 사용하여 GitLab CI/CD 파이프라인의 일부로 릴리스를 직접 만들 수 있습니다.
릴리스는 CI/CD 파이프라인의 마지막 단계 중 하나로 만드는 것이 좋습니다.
릴리스는 Job이 오류 없이 처리된 경우에만 만들어집니다. API가 릴리스 생성 중에 오류를 반환하면 릴리스 Job이 실패합니다.
다음 링크는 CI/CD Job을 사용하여 릴리스를 만들기 위한 일반적인 예시 구성을 보여줍니다:
사용자 정의 SSL CA 인증 기관 사용#
ADDITIONAL_CA_CERT_BUNDLE CI/CD 변수를 사용하여 사용자 정의 SSL CA 인증 기관을 구성할 수 있습니다. 이는 glab CLI가 사용자 정의 인증서와 함께 HTTPS를 사용하여 API를 통해 릴리스를 만들 때 피어를 확인하는 데 사용됩니다.
ADDITIONAL_CA_CERT_BUNDLE 값에는 X.509 PEM 공개 키 인증서의 텍스트 표현 또는 인증 기관이 포함된 path/to/file이 포함되어야 합니다.
예를 들어 .gitlab-ci.yml 파일에서 이 값을 구성하려면 다음을 사용합니다:
release:
variables:
ADDITIONAL_CA_CERT_BUNDLE: |
-----BEGIN CERTIFICATE-----
MIIGqTCCBJGgAwIBAgIQI7AVxxVwg2kch4d56XNdDjANBgkqhkiG9w0BAQsFADCB
...
jWgmPqF3vUbZE0EyScetPJquRFRKIesyJuBFMAs=
-----END CERTIFICATE-----
script:
- echo "Create release"
release:
name: 'My awesome release'
tag_name: '$CI_COMMIT_TAG'
ADDITIONAL_CA_CERT_BUNDLE 값은 UI의 사용자 정의 변수로 구성할 수도 있습니다. 인증서 경로가 필요한 file 또는 인증서의 텍스트 표현이 필요한 변수로 설정합니다.
단일 파이프라인에서 여러 릴리스 만들기#
파이프라인에는 여러 release Job이 있을 수 있습니다. 예를 들어:
ios-release:
script:
- echo "iOS release job"
release:
tag_name: v1.0.0-ios
description: 'iOS release v1.0.0'
android-release:
script:
- echo "Android release job"
release:
tag_name: v1.0.0-android
description: 'Android release v1.0.0'
릴리스 에셋을 Generic 패키지로#
Generic 패키지를 사용하여 릴리스 에셋을 호스팅할 수 있습니다.
패키지된 에셋으로 릴리스를 만들려면:
-
CI/CD 파이프라인에서 패키지 파일을 빌드합니다.
-
glabCLI Job으로 릴리스를 만듭니다:Create Release: stage: release image: registry.gitlab.com/gitlab-org/cli:latest rules: - if: $CI_COMMIT_TAG script: - | glab release create "$CI_COMMIT_TAG" \ --name "Release ${VERSION}" \ --notes "Your release notes here" \ path/to/your/release-asset-file \ --use-package-registry포함하려는 각 에셋에 대해 추가
--assets-link링크를 추가합니다.
예정된 릴리스#
Releases API를 사용하여 미리 릴리스를 만들 수 있습니다.
미래의 released_at 날짜를 설정하면 릴리스 태그 옆에 Upcoming Release 배지가 표시됩니다. released_at 날짜와 시간이 지나면 배지가 자동으로 제거됩니다.
과거 릴리스#
히스토리
- GitLab 15.2에서 도입되었습니다.
Releases API 또는 UI를 사용하여 과거에 릴리스를 만들 수 있습니다. 과거의 released_at 날짜를 설정하면 릴리스 태그 옆에 Historical release 배지가 표시됩니다. 과거에 릴리스되었기 때문에 릴리스 증거를 사용할 수 없습니다.
릴리스 편집#
릴리스가 만들어진 후 세부 정보를 편집하려면 릴리스 업데이트 API 또는 UI를 사용할 수 있습니다.
사전 요구 사항:
- Developer, Maintainer 또는 Owner 권한이 있어야 합니다.
UI에서:
- 왼쪽 사이드바에서 Deploy > Releases를 선택합니다.
- 수정하려는 릴리스의 오른쪽 상단 모서리에서 Edit this release (연필 아이콘)를 선택합니다.
- Edit Release 페이지에서 릴리스의 세부 정보를 변경합니다.
- Save changes를 선택합니다.
릴리스 삭제#
히스토리
- GitLab 15.2에서 도입되었습니다.
릴리스를 삭제하면 에셋도 삭제됩니다. 그러나 연관된 Git 태그는 삭제되지 않습니다. 릴리스와 관련된 Git 태그를 삭제하면 릴리스도 삭제됩니다.
사전 요구 사항:
- Developer, Maintainer 또는 Owner 권한이 있어야 합니다. 릴리스 권한에 대한 자세한 내용을 읽어보세요.
릴리스를 삭제하려면 릴리스 삭제 API 또는 UI를 사용합니다.
UI에서:
- 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- Deploy > Releases를 선택합니다.
- 삭제하려는 릴리스의 오른쪽 상단 모서리에서 Edit this release (✏️)를 선택합니다.
- Edit Release 페이지에서 Delete를 선택합니다.
- Delete release를 선택합니다.
릴리스에 마일스톤 연결#
릴리스를 하나 이상의 프로젝트 마일스톤과 연결할 수 있습니다.
GitLab Premium 고객은 릴리스에 연결할 그룹 마일스톤을 지정할 수 있습니다.
사용자 인터페이스에서 또는 Releases API에 대한 요청에 milestones 배열을 포함하여 수행할 수 있습니다.
사용자 인터페이스에서 릴리스에 마일스톤을 연결하려면:
- 왼쪽 사이드바에서 Deploy > Releases를 선택합니다.
- 수정하려는 릴리스의 오른쪽 상단 모서리에서 Edit this release (연필 아이콘)를 선택합니다.
- Milestones 목록에서 연결하려는 각 마일스톤을 선택합니다. 여러 마일스톤을 선택할 수 있습니다.
- Save changes를 선택합니다.
Deploy > Releases 페이지에서 마일스톤의 이슈에 대한 통계와 함께 Milestone이 최상위 섹션에 나열됩니다.
릴리스는 Plan > Milestones 페이지에서도 볼 수 있으며, 이 페이지에서 마일스톤을 선택할 때도 표시됩니다.
다음은 릴리스가 없는 마일스톤, 하나의 릴리스가 있는 마일스톤, 두 개의 릴리스가 있는 마일스톤의 예입니다.
하위 그룹의 프로젝트 릴리스는 상위 그룹의 마일스톤과 연결할 수 없습니다. 자세한 내용은 이슈 #328054, 릴리스는 상위 그룹 마일스톤과 연결할 수 없음을 참조하세요.
릴리스가 만들어질 때 알림 받기#
프로젝트에 새 릴리스가 만들어지면 이메일로 알림을 받을 수 있습니다.
릴리스에 대한 알림을 구독하려면:
- 왼쪽 사이드바에서 Project overview를 선택합니다.
- Notification setting (벨 아이콘)을 선택합니다.
- 목록에서 Custom을 선택합니다.
- New release 체크박스를 선택합니다.
- 저장하려면 대화 상자를 닫습니다.
배포 동결을 설정하여 의도하지 않은 릴리스 방지#
배포 동결 기간을 설정하여 지정한 시간 동안 의도하지 않은 프로덕션 릴리스를 방지합니다. 배포 동결은 배포를 자동화할 때 불확실성과 위험을 줄이는 데 도움이 됩니다.
Maintainer는 사용자 인터페이스에서 또는 Freeze Periods API를 사용하여 freeze_start 및 freeze_end를 crontab 항목으로 정의하는 배포 동결 창을 설정할 수 있습니다.
실행 중인 Job이 동결 기간에 있으면 GitLab CI/CD는 $CI_DEPLOY_FREEZE라는 환경 변수를 만듭니다.
그룹의 여러 프로젝트에서 배포 Job이 실행되는 것을 방지하려면 그룹 전체에서 공유되는 파일에 .freezedeployment Job을 정의합니다.
includes 키워드를 사용하여 프로젝트의 .gitlab-ci.yml 파일에 템플릿을 통합합니다:
.freezedeployment:
stage: deploy
before_script:
- '[[ ! -z "$CI_DEPLOY_FREEZE" ]] && echo "INFRASTRUCTURE OUTAGE WINDOW" && exit 1; '
rules:
- if: '$CI_DEPLOY_FREEZE'
when: manual
allow_failure: true
- when: on_success
배포 Job이 실행되는 것을 방지하려면 .gitlab-ci.yml 파일의 deploy_to_production Job에서 extends 키워드를 사용하여 .freezedeployment 템플릿 Job에서 구성을 상속합니다:
deploy_to_production:
extends: .freezedeployment
script: deploy_to_prod.sh
environment: production
이 구성은 조건부로 배포 Job을 차단하고 파이프라인 연속성을 유지합니다. 동결 기간이 정의되면 Job이 실패하고 파이프라인이 배포 없이 진행될 수 있습니다. 동결 기간 후에는 수동 배포가 가능합니다.
이 접근 방식은 중요한 유지 관리 중 배포 제어를 제공하고 CI/CD 파이프라인의 원활한 흐름을 보장합니다.
UI에서 배포 동결 창을 설정하려면 다음 단계를 완료합니다:
- Maintainer 권한이 있는 사용자로 GitLab에 로그인합니다.
- 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- Settings > CI/CD를 선택합니다.
- Deploy freezes로 스크롤합니다.
- Expand를 선택하여 배포 동결 표를 봅니다.
- Add deploy freeze를 선택하여 배포 동결 모달을 엽니다.
- 원하는 배포 동결 기간의 시작 시간, 종료 시간 및 시간대를 입력합니다.
- 모달에서 Add deploy freeze를 선택합니다.
- 배포 동결이 저장된 후 편집 버튼 (✏️)을 선택하여 편집하고 삭제 버튼 ([remove])을 선택하여 제거할 수 있습니다.
프로젝트에 여러 동결 기간이 있으면 모든 기간이 적용됩니다. 겹치는 경우 동결은 완전히 겹치는 기간을 커버합니다.
자세한 내용은 배포 안전성을 참조하세요.
릴리스 권한#
릴리스 보기 및 에셋 다운로드#
- Reporter, Developer, Maintainer 또는 Owner 권한이 있는 사용자는 프로젝트 릴리스에 대한 읽기 및 다운로드 액세스 권한이 있습니다.
- Guest 권한이 있는 사용자는 프로젝트 릴리스에 대한 읽기 및 다운로드 액세스 권한이 있습니다. 여기에는 관련 Git 태그 이름, 릴리스 설명, 릴리스 작성자 정보가 포함됩니다. 그러나 소스 코드 및 릴리스 증거와 같은 다른 리포지터리 관련 정보는 수정됩니다.
소스 코드에 대한 액세스 없이 릴리스 게시#
히스토리
- GitLab 15.6에서 도입되었습니다.
소스 코드 및 릴리스 증거와 같은 리포지터리 관련 정보를 프로젝트 구성원에게만 제공하면서 프로젝트 외부 구성원이 릴리스에 액세스할 수 있게 할 수 있습니다. 이러한 설정은 소프트웨어의 새 버전에 대한 액세스를 제공하기 위해 릴리스를 사용하지만 소스 코드를 공개적으로 사용 가능하게 하고 싶지 않은 프로젝트에 이상적입니다.
릴리스를 공개적으로 사용 가능하게 하려면 다음 프로젝트 설정을 설정합니다:
- Project visibility가 Public으로 설정
- Repository가 활성화되고 Only Project Members로 설정
- Releases가 활성화되고 Everyone With Access로 설정
릴리스 및 에셋 만들기, 업데이트 및 삭제#
- Developer, Maintainer 또는 Owner 권한이 있는 사용자는 프로젝트 릴리스 및 에셋에 대한 쓰기 액세스 권한이 있습니다.
- 릴리스가 보호된 태그와 연결된 경우, 사용자는 보호된 태그를 만드는 것이 허용되어야 합니다.
릴리스 권한 제어의 예로, 와일드카드(*)로 태그를 보호하고 Allowed to create 열에서 Maintainer를 설정하여 Maintainer 또는 Owner 권한이 있는 사용자만 릴리스를 만들고, 업데이트하고, 삭제하도록 허용할 수 있습니다.
릴리스 메트릭#
히스토리
- GitLab Premium 13.9에서 도입되었습니다.
Group > Analytics > CI/CD로 이동하여 그룹 수준의 릴리스 메트릭을 볼 수 있습니다. 이러한 메트릭에는 다음이 포함됩니다:
- 그룹의 총 릴리스 수
- 적어도 하나의 릴리스가 있는 그룹의 프로젝트 비율
예제 프로젝트#
Guided Exploration 프로젝트 GitVersion을 사용한 완전 자동화 소프트웨어 및 아티팩트 버전 관리는 다음을 보여줍니다:
- GitLab 릴리스 사용.
- GitLab CLI 사용.
- Generic 패키지 만들기.
- 패키지를 릴리스에 연결.
- 복잡한 리포지터리의 버전을 자동으로 결정하고 증분하기 위한 GitVersion이라는 도구 사용.
테스트를 위해 예제 프로젝트를 자신의 그룹이나 인스턴스로 복사할 수 있습니다. 프로젝트 페이지에서 어떤 다른 GitLab CI 패턴이 시연되는지에 대한 자세한 내용을 확인할 수 있습니다.
문제 해결#
릴리스 및 에셋 만들기, 업데이트 또는 삭제 시 오류#
릴리스가 보호된 태그와 연결된 경우 UI/API 요청이 다음과 같은 권한 부여 실패를 초래할 수 있습니다:
403 ForbiddenSomething went wrong while creating a new release
사용자 또는 서비스/봇 계정이 보호된 태그를 만드는 것이 허용되어 있는지 확인합니다.
자세한 내용은 릴리스 권한을 참조하세요.
스토리지에 대한 참고 사항#
이 기능은 Git 태그 위에 구축되어 있으므로 릴리스 자체를 만드는 것 외에 실질적으로 추가 데이터가 필요하지 않습니다. 추가 에셋과 자동으로 생성되는 릴리스 증거는 스토리지를 소비합니다.
GitLab CLI 버전 요구 사항#
release 키워드를 사용하는 방법이 변경될 예정입니다.
release-cli 도구가 GitLab CLI 도구로 교체 중입니다.
GitLab CLI 도구 v1.58.0 이상을 사용해야 하며, 그렇지 않으면 다음 오류 메시지나 경고 중 하나를 받을 수 있습니다:
Error: glab command not found. Please install glab v1.58.0 or higher.Error: Please use glab v1.58.0 or higher.Warning: release-cli will not be supported after 20.0. Please use glab version >= 1.58.0.
GitLab CLI 도구를 사용하는 두 가지 방법이 있습니다:
registry.gitlab.com/gitlab-org/release-cli:<version>컨테이너 이미지를 사용하는 경우registry.gitlab.com/gitlab-org/cli:v1.58.0또는glabv1.58.0을 포함하는registry.gitlab.com/gitlab-org/release-cli:v0.24.0을 사용할 수 있습니다.- 러너에 release-cli 또는 GitLab CLI 도구를 수동으로 설치한 경우 GitLab CLI 버전이 최소
v1.58.0인지 확인합니다.