Helm 차트 릴리스

차트 버전 관리

주요 릴리스

주요 릴리스는 차트나 GitLab 릴리스의 중대한 변경 또는 중요한 이정표를 위한 것입니다.

다음과 같은 경우에 주요 버전 번호를 올립니다:

중요한 추가 사항 또는 변경 사항. 예를 들어, 기본적으로 Pages를 추가하거나 NGINX를 완전히 삭제합니다.
GitLab이나 차트에서의 패치로, 기존 설치를 업그레이드하기 위해 수동 상호 작용이 필요한 변경 사항.
GitLab 이미지의 주요 업데이트(예: 12.0.0 릴리스).

마이너 릴리스

마이너 릴리스는 GitLab 이미지의 마이너 릴리스와 차트에서의 변경에 따라 반복됩니다.

다음과 같은 경우에 마이너 버전을 올립니다:

GitLab의 모든 마이너 버전 업데이트
차트에서 리소스 사용량을 증가시킬 수 있는 기본값 변경(서브차트나 파드 추가, 추가 서비스나 인그레스 추가)
더 많은 가시성을 필요로 하는 다른 기능 변경 사항.

패치 릴리스

이전 릴리스에 대한 매우 안정적인 업데이트로 간주되는 변경 사항에 대한 패치 릴리스입니다. 이에는 GitLab 이미지의 패치 릴리스가 포함됩니다.

다음과 같은 경우에 패치 버전을 올립니다:

GitLab 이미지의 패치 릴리스
마이너 또는 주요 버전을 올릴 필요가 없는 변경 사항 집합.

릴리스 시나리오 예시

차트 버전	GitLab 버전	릴리스 시나리오
`0.2.0`	`11.0.0`	GitLab 11 릴리스, 그리고 차트 베타
`0.2.1`	`11.0.1`	GitLab 패치 릴리스
`0.2.2`	`11.0.1`	차트 변경 사항 릴리스
`0.2.3`	`11.0.2`	GitLab 패치 릴리스, 일부 관련 차트 변경 사항 포함
`0.3.0`	`11.1.0`	GitLab 마이너 릴리스, 그리고 새로운 차트 변경 사항
`0.4.0`	`11.1.0`	마이너 버전 번호 포함이 합리적이라고 판단되는 차트 변경
`0.2.4`	`11.0.3`	보안 릴리스
~~`0.3.1`~~	~~`11.1.1`~~	~~보안 릴리스~~ (1)
`0.4.1`	`11.1.1`	보안 릴리스 (1)
…	…	…
`1.0.0`	`11.x.0`	GitLab 마이너 릴리스, 그리고 차트 GA
`2.0.0`	`11.x.x`	차트에 일부 큰 변경 사항 도입
`3.0.0`	`12.0.0`	GitLab 12 릴리스

(1): 보안 릴리스에 동일한 이미지 버전을 업그레이드해야하는 두 개의 차트 버전이 있는 경우, 더 최근 버전만 업데이트합니다. 그렇지 않으면 릴리스 논리를 자동화하는 것이 지나치게 복잡해집니다. 필요한 경우 사용자가 이미지 버전을 수동으로 지정하거나 차트를 업그레이드하여 이 문제를 해결할 수 있습니다.

향후 반복

우리는 우리만의 GitLab 버전을 사용할 것을 고려했지만, 여기서의 중대한 변경 사항이 필요하고 GitLab이 예를 들어 버전 번호를 12로 올려야하는 경우에 이르기까지는, 아직 GitLab 릴리스와 완전히 동기화되지 않았습니다. 현재 우리는 차트 고유의 버전 체계로 전진할 것이며, GitLab 코어 버전을 올리는 합리적인 이유로 차트 업데이트를 요청하게 될 때까지 이러한 릴리스 논리로 계속 진행할 것입니다.

브랜치 및 태그

이 차트에서는 다른 주요 GitLab 구성요소와 동일한 브랜치 전략을 제안합니다.

master 브랜치,
각 마이너 릴리스마다 master에서 생성하는 x-x-stable 브랜치.
이러한 안정적인 브랜치로부터 생성된 x.x.x 태그.

우리 브랜치 이름과 다른 GitLab 구성요소 사이의 차이점은, GitLab 버전 대신 차트 버전을 브랜치 이름에 사용할 것이라는 것입니다.

일반적으로 변경은 master에 병합되어, 릴리스 전에 적절한 브랜치로 체리픽됩니다. GitLab 이미지 업데이트는 master에서가 아니라 브랜치의 커밋으로 발생하며, master는 최신 데일리 이미지를 따를 것입니다.

릴리스 작업의 타임라인 예시

제안된 브랜치 전략을 사용하여 릴리스에 대한 관련 시간표

브랜치	태그	작업	세부 정보
`0-2-stable`		브랜치	master에서 생성된 브랜치
		이미지 업데이트	GitLab `11.0.0-rcX` 이미지 사용
		체리픽	master에서 추가 변경을 브랜치로 체리픽
		이미지 업데이트	GitLab `11.0.0` 이미지 사용
	`0.2.0`	태그	차트 `0.2.0` 릴리스
		체리픽	master에서 수정 사항을 브랜치로 체리픽
		이미지 업데이트	GitLab `11.0.1` 이미지 사용
	`0.2.1`	태그	차트 `0.2.1` 릴리스
`0-3-stable`		브랜치	master에서 생성된 브랜치
		이미지 업데이트	GitLab `11.1.0-rc1` 이미지 사용
`0-2-stable`		이미지 업데이트	GitLab `11.0.2` 이미지 사용
	`0.2.2`	태그	차트 `0.2.2` 릴리스
`0-3-stable`		체리픽	master에서 수정 사항을 브랜치로 체리픽
		이미지 업데이트	GitLab `11.1.0` 이미지 사용
	`0.3.0`	태그	차트 `0.3.0` 릴리스

차트 릴리스

차트의 새 버전을 릴리스하는 작업은 릴리스 도구 저장소의 Helm 릴리스 작업에서 처리됩니다.

릴리스는 GitLab 릴리스의 일환으로 이루어집니다. 필요한 경우 Distribution 팀은 추가적인 차트 릴리스를 시작할 수 있습니다. 릴리스 도구는 차트를 패키징하고 배포하기 위해 파이프라인을 트리거합니다. charts.gitlab.io 저장소의 release_chart 작업을 참조하세요.

또한, 릴리스 도구는 다음을 자동화합니다:

변경 로그,
차트 버전,
차트 app 버전,
global.gitlabVersion 값 및
GitLab 버전에서 차트 버전으로의 매핑.

개발 빌드

master로의 모든 병합마다 개발용 차트 버전이 빌드됩니다.

devel 채널을 사용하여 Helm 차트의 현재 비 프로덕션 “개발” 릴리스를 추적하는 것이 가능합니다:

helm repo add gitlab-devel https://gitlab.com/api/v4/projects/3828396/packages/helm/devel

그리고 특정 릴리스를 가리키는 helm에 --devel 옵션을 사용하여 다음과 같이 실행하세요:

helm install --devel --version 1.2.3-4567 gitlab-devel/gitlab

사용 가능한 devel 버전을 나열하려면:

helm search repo gitlab-devel --devel

수동으로 차트 릴리스하기

차트를 수동으로 릴리스하기 전에, 릴리스할 버전에 대한 안정적인 브랜치에 master에서 원하는 차트 변경 사항이 모두 선택되었는지 확인하세요.

예를 들어, 차트 버전 0.2.1을 릴리스하려면 변경 사항이 0-2-stable에 있어야 합니다.

릴리스를 태그할 ChatOps 명령이 존재합니다. 다음 명령을 관련된 릴리스 Slack 채널(예: #f_release_12_4)에서 실행하세요.

/chatops run helm tag <차트 버전> <GitLab 버전>

또는 다음과 같이 ChatOps 명령을 사용하지 않고 수동으로 실행할 수도 있습니다:

릴리스 도구 저장소를 체크아웃하고 설정하세요.

git clone git@gitlab.com:gitlab-org/release-tools.git
bundle install

그런 다음 적절한 Helm 릴리스 작업을 실행하세요:
- GitLab 앱 버전을 변경하지 않고 릴리스하려면 새 차트 버전(예: 0.2.1)으로 릴리스 작업을 호출하세요.
  - bundle exec rake release:helm:tag[0.2.1]
- 차트 버전과 앱 버전 모두 변경하여 릴리스하려면(예: 0.2.1과 GitLab 11.0.1)
  - bundle exec rake release:helm:tag[0.2.1,11.0.1]
TEST=true로 환경을 설정하여 푸시를 방지하는 dry-run 모드로 스크립트를 실행할 수 있습니다.