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 구성 요소와 동일한 브랜칭 전략을 따를 것을 제안합니다.

master 브랜치,
마이너 릴리스를 위해 master에서 생성하는 x-x-stable 브랜치.
이러한 안정적인 브랜치에서의 x.x.x 태그.

우리의 브랜치 이름과 다른 GitLab 구성 요소의 차이점은 브랜치 이름에 GitLab 버전이 아닌 차트의 버전을 사용한다는 것입니다.

일반적으로, 변경 사항은 master에 병합된 후 릴리스 전에 적절한 브랜치로 체리픽됩니다. GitLab 이미지 업데이트는 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 릴리스의 일환으로 수행됩니다. 필요할 경우, 배포팀은 추가적인 차트 릴리스를 시작할 수 있습니다. 릴리스 도구는 차트를 패키징하고 배포하기 위한 파이프라인을 트리거합니다. charts.gitlab.io 저장소에서 release_chart 작업을 참조하세요.

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

변경 로그,
차트 버전,
차트 appVersions,
global.gitlabVersion의 값 및
GitLab 버전을 차트 버전으로 매핑.

개발 빌드

개발 차트 버전은 master에 병합될 때마다 빌드됩니다.

실제 비생산 “개발” 릴리스를 추적하는 것은 devel 채널을 사용하여 가능합니다:

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

특정 릴리스를 가리키는 --devel 옵션을 사용하는 helm을 통해:

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

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

helm search repo gitlab-devel --devel

차트를 수동으로 릴리즈하기

차트를 수동으로 릴리즈하기 전에, 릴리즈하려는 버전의 안정(stable) 브랜치에 있는 모든 차트 변경 사항이 master에서 선택되었는지 확인하십시오.

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

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

/chatops run helm tag <charts version> <GitLab version>

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로 설정하세요.