• 차트 버전 관리
  • 주요 릴리스
  • 마이너 릴리스
  • 패치 릴리스
  • 예상 릴리스 시나리오
  • 향후 반복
• 브랜치와 태그
  • 릴리스 작업의 시간표 예제
• 차트 릴리스
  • 개발용 빌드
  • 차트 수동 릴리스

Helm 차트 릴리스

차트 버전 관리

주요 릴리스

주요 릴리스는 차트 또는 GitLab 릴리스의 중요한 이벤트 및 주요 변경 사항을 위한 것입니다.

우리는 주요 버전 번호를 다음과 같이 업데이트합니다:

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

마이너 릴리스

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

우리는 다음과 같은 이유로 업데이트합니다:

• GitLab의 모든 마이너 버전 업데이트
• 차트의 기본값 변경으로 자원 사용량이 증가할 수 있는 경우 (서브차트 또는 파드, 추가 서비스 또는 인그레스가 추가됨)
• 우리가 더 많은 시야를 포함해야 한다고 생각하는 다른 기능적인 변경 사항.

패치 릴리스

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

우리는 다음과 같은 이유로 업데이트합니다:

• GitLab 이미지의 패치 릴리스
• 마이너 또는 주요 버전을 업데이트하는 필요가 없는 변경 사항의 모음.

예상 릴리스 시나리오

• (1): 만약 보안 릴리스를 위해 두 개의 차트 버전이 모두 동일한 이미지 버전으로 업그레이드해야 하는 경우, 우리는 더 최신 버전만 업데이트합니다. 그렇지 않으면 자동화된 릴리스 로직이 지나치게 복잡해질 것입니다. 필요한 경우 사용자는 이미지 버전을 수동으로 지정하거나 자신의 차트를 업그레이드할 수 있습니다.

향후 반복

특정 GitLab 버전을 사용하는 대신 차트 고유의 버전 체계를 사용하려고 고려했지만, 여전히 차트에서 여기에서 중단 사항을 만들고 GitLab에게 예를 들어 버전 번호를 12로 올리도록 요청할 정도로 GitLab 릴리스와 동조되지는 않았습니다. 현재까지는 차트가 충분히 안정되어 있어서 동일한 버전을 공유하고 차트 업데이트가 합리적인 이유로 GitLab 코어 버전을 올릴 수 있는 경우까지 차트 고유의 버전 체계를 사용하여 계속 진행하겠습니다.

브랜치와 태그

이 차트에 대해 다른 주요 GitLab 구성 요소와 동일한 브랜치 전략을 따르기로 제안합니다.

• master 브랜치,
• 마이너 릴리스 당 마스터에서 만드는 x-x-stable 브랜치.
• 이러한 안정적인 브랜치로부터의 x.x.x 태그.

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

일반적으로 변경 사항은 마스터에 병합된 다음 릴리스 전에 해당 브랜치로 체리 픽됩니다. GitLab 이미지 업데이트는 마스터가 최신 이미지를 따르기 때문에 마스터가 아닌 브랜치에서 커밋될 것입니다.

릴리스 작업의 시간표 예제

제안된 브랜치 전략을 사용하여 릴리스 관련

차트 릴리스

차트의 새 버전을 릴리스하는 것은 릴리스 도구 리포지토리의 Helm 릴리스 작업에 의해 처리됩니다.

릴리스는 GitLab 릴리스의 일부로 진행됩니다. 필요한 경우 Distribution 팀은 추가적인 차트 릴리스를 시작할 수 있습니다. 릴리스 도구는 차트를 패키징하고 공개하기 위한 파이프라인을 트리거합니다. charts.gitlab.io 리포지토리의 release_chart 작업에서 자세한 내용을 확인하세요.

또한, 릴리스 도구는 다음을 자동화합니다: - 변경 로그, - 차트 버전, - 차트 앱 버전, - global.gitlabVersion 값 및 - GitLab 버전에서 차트 버전으로의 매핑 값을.

개발용 빌드

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

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

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 명령을 사용하지 않고 수동으로 실행 할 수도 있습니다:

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

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

2. 그런 다음 적절한 헬름 릴리스 작업을 실행하세요:

   • 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 모드에서 스크립트를 실행할 수 있습니다