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에서 빌드를 유발하며, 그 후에 패키지가 생성됨을 의미합니다.
우리는 Omnibus GitLab 패키지를 사용하여 GitLab.com을 배포하고 있기 때문에, GitLab.com에 문제가 있는 경우나 패키지의 보안 릴리스로 인해 패키지를 빌드할 수 있는 별도의 원격이 필요합니다.
이러한 원격은 https://dev.gitlab.org에 위치해 있습니다. https://dev.gitlab.org의 Omnibus GitLab 프로젝트와 다른 공개 원격들과의 유일한 차이점은 해당 프로젝트에 활성화된 GitLab CI가 있고, 해당 프로젝트에 할당된 특정 러너가 빌드 서버에서 실행된다는 것입니다. GitLab Shell의 경우도 마찬가지이며, 예를 들어 GitLab.com과 동일하게 https://dev.gitlab.org에서 실행됩니다.
모든 빌드 서버는 GitLab Runner를 실행하고 있으며, 모든 러너는 프로젝트에 연결하기 위해 배포 키를 사용합니다. 빌드 서버는 또한 https://packages.gitlab.com의 공식 패키지 저장소와 테스트 패키지가 저장된 특수한 Amazon S3 버킷에 액세스할 수 있습니다.
빌드 프로세스
GitLab Inc은 모든 릴리스를 위해 릴리스 도구 프로젝트를 사용하여 릴리스 작업을 자동화하고 있습니다. 릴리스 매니저가 릴리스 프로세스를 시작할 때, Omnibus GitLab에 대한 몇 가지 중요한 작업이 수행됩니다:
- 프로젝트의 모든 원격이 동기화됩니다.
- 컴포넌트 버전은 GitLab CE/EE 저장소에서 읽히고 (예:
VERSION,GITLAB_SHELL_VERSION), Omnibus GitLab 저장소에 작성됩니다. - 특정한 Git 태그가 생성되어 Omnibus GitLab 저장소로 동기화됩니다.
https://dev.gitlab.org의 Omnibus GitLab 저장소가 업데이트되면, GitLab CI 빌드가 트리거됩니다.
구체적인 단계는 Omnibus GitLab 저장소의 .gitlab-ci.yml 파일에서 확인할 수 있습니다. 빌드는 동시에 모든 플랫폼에서 실행됩니다.
빌드 중에 Omnibus GitLab은 외부 라이브러리를 해당 소스 위치에서 가져오고, GitLab과 GitLab Shell, GitLab Workhorse 등과 같은 GitLab 컴포넌트들은 https://dev.gitlab.org에서 가져옵니다.
빌드가 완료되고 .deb 또는 .rpm 패키지가 빌드되면, 빌드 유형에 따라 패키지가 https://packages.gitlab.com 또는 임시(30일 이전 파일은 삭제됨) S3 버킷으로 푸시됩니다.
구성 요소 버전을 수동으로 지정하기
개발 환경에서
- 패키징할 GitLab의 태그를 선택합니다 (예:
v6.6.0). - Omnibus GitLab 리포지토리에서 릴리스 브랜치를 생성합니다 (예:
6-6-stable). -
패치 릴리스 등으로 이미 릴리스 브랜치가 존재하는 경우, 로컬 머신에 최신 변경 사항을 풀었는지 확인합니다:
git pull https://gitlab.com/gitlab-org/omnibus-gitlab.git 6-6-stable # 기존 릴리스 브랜치 -
config/software/의 파일의 리비전을 설정하기 위해support/set-revisions를 사용합니다. 이는 태그 이름을 가져와 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.47.10.4+ce.0,7.10.4+ce.1,...v7.10.4-ee7.10.4+ee.0,7.10.4+ee.1,...v7.11.0.rc1-ee7.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 영업일 이내에 릴리스되어야 합니다.
이미지별 릴리스 문서:
- (사용 중단됨) OpenShift.
도움말