Omnibus GitLab 릴리스 프로세스

우리의 주요 목표는 Omnibus 패키지에 GitLab 버전이 명확히 나타나도록 하는 것입니다.

공식 Omnibus GitLab 패키지 빌드 방식

공식 패키지 빌드는 GitLab Inc.에서 완전히 자동화됩니다.

빌드의 두 가지 유형을 구별할 수 있습니다.

https://packages.gitlab.com에 릴리스되는 패키지
S3 버킷에서 사용 가능한 브랜치에서 빌드된 테스트 패키지

두 유형은 동일한 인프라에서 빌드됩니다.

인프라

각 패키지는 해당하는 플랫폼에서 빌드됩니다(CentOS 6 패키지는 CentOS6 서버에서, Debian 8 패키지는 Debian 8 서버에서 빌드됩니다). 빌드 서버의 수는 다양하지만, 각 플랫폼 당 적어도 한 대의 빌드 서버가 존재합니다.

Omnibus GitLab 프로젝트는 GitLab CI를 완전히 활용합니다. 이는 Omnibus GitLab 리포지터리에 대한 각 푸시가 GitLab CI에서 빌드를 트리거하고, 그 후 패키지를 생성한다는 것을 의미합니다.

우리는 GitLab.com을 Omnibus GitLab 패키지를 사용하여 배포하고 있기 때문에, GitLab.com에 문제가 발생하거나 패키지의 보안 릴리스로 인해 패키지를 빌드하기 위해 별도의 원격이 필요합니다.

이 원격 리포지터리는 https://dev.gitlab.org/에 위치해 있습니다. https://dev.gitlab.org/의 Omnibus GitLab 프로젝트와 다른 공개 원격과의 유일한 차이점은 프로젝트에 활성화된 GitLab CI가 있고, 빌드 서버에서 실행되는 프로젝트에 할당된 특정 러너가 있습니다. GitLab 쉘, 예를 들면, GitLab 쉘은 https://dev.gitlab.org/에서도 GitLab.com에서와 완전히 동일합니다.

모든 빌드 서버는 GitLab Runner를 실행하고, 모든 러너는 프로젝트에 연결하기 위해 배포 키를 사용합니다. 빌드 서버는 또한 공식 패키지 리포지터리 https://packages.gitlab.com 및 테스트 패키지를 저장하는 특별한 Amazon S3 버킷에 액세스할 수 있습니다.

빌드 프로세스

GitLab Inc.은 릴리스 도구 프로젝트를 사용하여 각 릴리스에 대한 릴리스 작업을 자동화합니다. 릴리스 관리자가 릴리스 프로세스를 시작하면 Omnibus GitLab에 대해 몇 가지 중요한 작업이 수행됩니다:

프로젝트의 모든 원격이 동기화됩니다.
컴포넌트 버전은 GitLab CE/EE 리포지터리에서 읽힌 뒤(Omnibus GitLab 리포지터리에 기록됩니다(예: VERSION, GITLAB_SHELL_VERSION).
특정 Git 태그가 작성되고 Omnibus GitLab 리포지터리에 동기화됩니다.

https://dev.gitlab.org/의 Omnibus GitLab 리포지터리가 업데이트되면 GitLab CI 빌드가 트리거됩니다.

구체적인 단계는 Omnibus GitLab 리포지터리의 .gitlab-ci.yml 파일에서 확인할 수 있습니다. 빌드는 동시에 모든 플랫폼에서 실행됩니다.

빌드 중에 Omnibus GitLab은 외부 라이브러리를 원본 위치에서 가져와 GitLab, GitLab 쉘, GitLab Workhorse 등의 GitLab 컴포넌트들을 https://dev.gitlab.org/에서 가져옵니다.

빌드가 완료되고 .deb 또는 .rpm 패키지가 빌드되면, 빌드 유형에 따라 패키지가 https://packages.gitlab.com 또는 임시 S3 버킷에 푸시됩니다(30일 이상 된 파일은 삭제됩니다).

컴포넌트 버전 매뉴얼으로 지정하기

개발 환경에서

패키징할 GitLab 태그를 선택합니다(예: v6.6.0).
Omnibus GitLab 리포지터리에 릴리스 브랜치를 생성합니다(예: 6-6-stable).
패치 릴리스를 수행하는 경우처럼 릴리스 브랜치가 이미 존재하는 경우, 로컬 머신에 최신 변경 사항을 가져왔는지 확인합니다:
```
git pull https://gitlab.com/gitlab-org/omnibus-gitlab.git 6-6-stable # 기존 릴리스 브랜치
```
support/set-revisions를 사용하여 config/software/의 파일 리비전을 설정합니다. 태그 이름을 사용하여 Git SHA1 값을 찾아 다음에 대해 설정하고, 다운로드 소스를 https://dev.gitlab.org/에 설정합니다. EE 릴리스의 경우 set-revisions --ee를 사용합니다:
```
# 사용법: set-revisions [--ee] GITLAB_RAILS_REF GITLAB_SHELL_REF GITALY_REF GITLAB_ELASTICSEARCH_INDEXER_REF
   
# GitLab CE의 경우:
support/set-revisions v1.2.3 v1.2.3 1.2.3 1.2.3 1.2.3
   
# GitLab EE의 경우:
support/set-revisions --ee v1.2.3-ee v1.2.3 1.2.3 1.2.3 1.2.3
```

새 버전을 릴리스 브랜치에 커밋합니다:

git add VERSION GITLAB_SHELL_VERSION GITALY_SERVER_VERSION
git commit

GitLab 태그에 해당하는 Omnibus GitLab에 주석이 달린 태그를 생성합니다. Omnibus 태그는 일반적으로 다음과 같은 형식입니다: MAJOR.MINOR.PATCH+OTHER.OMNIBUS_RELEASE인데, 여기서 MAJOR.MINOR.PATCH는 GitLab 버전입니다. OTHER는 ce, ee 또는 rc1(또는 rc1.ee)과 같은 것일 수 있고, OMNIBUS_RELEASE는 0부터 시작하는 숫자입니다:
```
git tag -a 6.6.0+ce.0 -m 'Pin GitLab to v6.6.0'
```
Omnibus GitLab 태그에 하이픈 -을 사용하지 마십시오.

상위 태그를 Omnibus 태그 순서로 변환하는 예시:

상위 태그 Omnibus 태그 순서

v7.10.4 7.10.4+ce.0, 7.10.4+ce.1, ...
v7.10.4-ee 7.10.4+ee.0, 7.10.4+ee.1, ...
v7.11.0.rc1-ee 7.11.0+rc1.ee.0, 7.11.0+rc1.ee.1, ...
릴리스 브랜치와 태그를 https://gitlab.com 및 https://dev.gitlab.org/에 푸시합니다:
```
git push git@gitlab.com:gitlab-org/omnibus-gitlab.git 6-6-stable 6.6.0+ce.0
git push git@dev.gitlab.org:gitlab/omnibus-gitlab.git 6-6-stable 6.6.0+ce.0
```
https://dev.gitlab.org/에 주석이 달린 태그를 푸시하면 패키지 릴리스가 트리거됩니다.

상위 태그	Omnibus 태그 순서
`v7.10.4`	`7.10.4+ce.0`, `7.10.4+ce.1`, `...`
`v7.10.4-ee`	`7.10.4+ee.0`, `7.10.4+ee.1`, `...`
`v7.11.0.rc1-ee`	`7.11.0+rc1.ee.0`, `7.11.0+rc1.ee.1`, `...`

패키지 게시

패키지 빌드 진행 상황은 https://dev.gitlab.org/gitlab/omnibus-gitlab/builds에서 추적할 수 있습니다. 빌드가 성공하면 자동으로 packagecloud 리포지터리에 푸시됩니다.

클라우드 이미지 업데이트

클라우드 이미지 릴리스 프로세스는 여기에 문서화되어 있습니다: https://handbook.gitlab.com/handbook/alliances/cloud-images/.

새 이미지는 다음 경우에 릴리스됩니다:

GitLab의 새로운 월간 릴리스가 있을 때.
패치 릴리스에서 보안 취약점이 해결된 경우.
이미지에 영향을 미치는 중요한 문제를 해결하는 패치가 있는 경우.

새 이미지는 패키지 릴리스 후 영업일 3일 이내에 릴리스되어야 합니다.

이미지별 릴리스 문서:

(폐기 예정) OpenShift.