Omnibus GitLab 릴리즈 프로세스

저희의 주요 목표는 어떤 버전의 GitLab이 omnibus 패키지에 포함되어 있는지 명확히 하는 것입니다.

공식 Omnibus GitLab 패키지가 구축되는 방법

공식 패키지 구축은 GitLab Inc에 의해 완전히 자동화되어 있습니다.

두 가지 유형의 빌드를 구분할 수 있습니다:

https://packages.gitlab.com에 배포될 패키지.
S3 버킷에서 사용할 수 있는 브랜치에서 빌드된 테스트 패키지.

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

인프라

각 패키지는 해당 플랫폼에서 빌드됩니다(예: CentOS 6 패키지는 CentOS 6 서버에서, 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 Shell과 같이 모든 GitLab 구성 요소에도 해당됩니다.

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

빌드 프로세스

GitLab Inc는 모든 릴리즈에 대한 릴리즈 작업을 자동화하기 위해 release-tools 프로젝트를 사용합니다.

릴리즈 관리자가 릴리즈 프로세스를 시작하면 Omnibus GitLab에 대해 몇 가지 중요한 작업이 수행됩니다:

모든 원격 리포지토리가 동기화됩니다.
구성 요소의 버전이 GitLab CE/EE 리포지토리에서 읽혀지고 Omnibus GitLab 리포지토리에 기록됩니다.
특정 Git 태그가 생성되어 Omnibus GitLab 리포지토리와 동기화됩니다.

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

구체적인 단계는 Omnibus GitLab 리포지토리의 .gitlab-ci.yml 파일에서 확인할 수 있습니다.

모든 플랫폼에서 빌드는 동시에 실행됩니다.

빌드 중에 Omnibus GitLab은 외부 라이브러리를 그들의 출처에서 가져오고 GitLab 구성 요소(예: GitLab, GitLab Shell, GitLab Workhorse 등)는 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 태그 시퀀스로 변환하는 예시:

upstream tag	omnibus tag sequence
`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에 푸시하면 패키지 릴리즈가 트리거됩니다.

패키지 배포

패키지 빌딩의 진행 상황은 https://dev.gitlab.org/gitlab/omnibus-gitlab/builds에서 추적할 수 있습니다.

성공적으로 빌드된 후 packagecloud 저장소에 자동으로 푸시됩니다.

클라우드 이미지 업데이트

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

새로운 이미지는 다음과 같은 경우에 릴리스됩니다:

GitLab의 새로운 월간 릴리즈가 있을 때.
패치 릴리즈에서 보안 취약점이 수정되었을 때.
이미지를 영향을 주는 중요한 문제를 수정하는 패치가 있을 때.

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

이미지 특정 릴리즈 문서:

(Deprecated) OpenShift.