Go 버전 관리
GitLab v19.4요약
GitLab Runner와 Security Projects를 제외한 모든 Go 바이너리는 Distribution 팀이 관리하는 프로젝트에서 빌드됩니다. Omnibus GitLab 프로젝트는 모든 바이너리를 담은 하나의 단일 운영 체제 패키지를 만들고, Cloud-Native GitLab(CNG) 프로젝트는 Helm Charts 또는 GitLab Operator로 배포하고 구성하는 Docker 이미지 모음을 게시합니다.
개요#
GitLab Runner와 Security Projects를 제외한 모든 Go 바이너리는 Distribution 팀이 관리하는 프로젝트에서 빌드됩니다.
Omnibus GitLab 프로젝트는 모든 바이너리를 담은 하나의 단일 운영 체제 패키지를 만들고, Cloud-Native GitLab(CNG) 프로젝트는 Helm Charts 또는 GitLab Operator로 배포하고 구성하는 Docker 이미지 모음을 게시합니다.
배포되는 Go 버전에 대한 테스트#
Go를 사용하는 모든 프로젝트의 테스트 매트릭스에는 Distribution 이 배포하는 버전이 포함되어야 합니다. 다음에서 GO_VERSION으로 설정된 Go 버전을 확인합니다.
여러 Go 버전 지원#
개별 Go 프로젝트는 다음과 같은 이유로 여러 Go 버전을 지원해야 할 수 있습니다.
- 새 Go 버전이 릴리스되면 상위 호환성을 확인하기 위해 CI 파이프라인에 이를 통합하기 시작해야 합니다.
- 백포트를 지원하려면 활성 마일스톤을 제외한 최근 3개 마이너 GitLab 릴리스에서 Distribution 이 배포한 Go 버전을 지원해야 합니다.
Go 버전 업데이트#
항상 다음을 지킵니다.
- Omnibus GitLab과 Cloud Native GitLab에 동일한 Go 버전을 사용합니다.
- 지원되는 버전을 사용합니다.
- 보안 수정 사항을 반영하기 위해 해당 버전의 최신 패치 레벨을 사용합니다.
버전 변경은 컴파일되는 모든 프로젝트에 영향을 주므로, 패키지 빌더가 새 Go 버전을 사용하도록 바꾸기 전에 모든 프로젝트가 그 버전으로 테스트하도록 업데이트되었는지 확인하는 것이 중요합니다. Go의 호환성 약속에도 불구하고 마이너 버전 사이의 변경이 버그를 드러내거나 프로젝트에 문제를 일으킬 수 있습니다.
go.mod의 버전#
핵심 요구 사항은 다음과 같습니다.
- 패치 버전은 항상
0을 사용합니다(예:go 1.23.4가 아니라go 1.23.0). - CNG와 Omnibus에서 사용하는 것보다 최신 버전을 지정하지 않습니다. 지정하면 빌드가 실패합니다.
go.mod파일에toolchain지시어를 사용하지 않습니다. 서로 다른 Go 버전으로 프로젝트를 빌드할 때 문제를 일으켜 왔기 때문입니다.
go.mod의 Go 버전은 모든 다운스트림 프로젝트에 영향을 줍니다.
최소 Go 버전을 지정하면, 해당 패키지를 가져오는 모든 프로젝트가 그 버전 이상을 사용해야 합니다.
이는 Go 버전 제약이 다른 프로젝트에 해결 불가능한 상황을 만들 수 있습니다.
예를 들어 CNG가 Go 1.23.4를 사용하는데 프로젝트가 최소 요구 버전으로 go 1.23.5를 선언하면 CNG는
해당 패키지를 빌드하지 못합니다.
마찬가지로 해당 패키지를 가져오는 다른 프로젝트도 Go 버전을 올려야 하는데, 이것이 현실적으로 어려울 수 있습니다.
CNG와 Omnibus에서 사용하는 버전은 위 내용을 참고합니다.
Go Modules Reference의 설명은 다음과 같습니다.
go 지시어는 이 모듈을 사용하는 데 필요한 Go의 최소 버전을 설정합니다.
Go 1.24.0과 호환되도록 하기 위해 go 1.24.0을 설정할 필요는 없습니다.
go 1.23.0으로 두어도 문제없이 동작합니다.
Go 1 호환성 약속 덕분에 Go 1.23.0과 그 이후 버전은
거의 확실하게 패키지를 문제없이 빌드합니다.
업그레이드 주기#
GitLab은 지원 중인 GitLab 버전이 수명이 끝난 Go 버전과 함께 배포되지 않도록 Go 메이저 버전이 릴리스된 뒤 8개월 이내에 이를 채택합니다.
보안 문제를 패치하거나, 버그를 수정하거나, 개발 팀이 요청하고 Product Management가 승인한 기능을 추가하는 마이너 업그레이드는 필수입니다.
자세한 내용은 다음을 참고합니다.
업그레이드 프로세스#
업그레이드 프로세스는 다음 핵심 단계로 이루어집니다.
작업 추적#
- Build Architecture Configuration 파이프라인 페이지로 이동합니다.
- 다음 변수를 사용해 드라이 런용 파이프라인을 새로 만듭니다.
COMPONENT_UPGRADE를true로 설정합니다.COMPONENT_NAME을golang.으로 설정합니다.COMPONENT_VERSION을 업그레이드 대상 버전으로 설정합니다.
- 파이프라인을 실행합니다.
- 드라이 런 파이프라인에 오류가 있는지 확인합니다. 레이블이 변경되었거나 직접 책임자가 더 이상 유효하지 않아 구독자 파일에서 오류가 발생하면, 해당 구독자 프로젝트에 연락해 구성을 갱신하도록 요청합니다.
- 드라이 런 파이프라인이 성공하면, 업그레이드 에픽과 관련 이슈를 모두 생성하기 위해 다음 변수를 사용해 파이프라인을 하나 더 만듭니다.
COMPONENT_UPGRADE를true로 설정합니다.COMPONENT_NAME을golang.으로 설정합니다.COMPONENT_VERSION을 업그레이드 대상 버전으로 설정합니다.EPIC_DRY_RUN을false로 설정합니다.
- 파이프라인을 실행합니다.
Go를 사용하는 알려진 의존성#
Go 업그레이드의 직접 책임자는 필요한 모든 컴포넌트가 업그레이드되도록 보장해야 합니다.
사전 요구 사항#
다음 절에 나열된 프로젝트가 새 Go 버전으로 빌드될 수 있도록, 아래 프로젝트를 표시된 순서대로 먼저 업그레이드해야 합니다.
| 컴포넌트 이름 | 작업 추적 위치 |
|---|---|
| GitLab Runner | Issue Tracker |
| GitLab CI Images | Issue Tracker |
| GitLab Development Kit (GDK) | Issue Tracker |
릴리스 승인에 필요한 항목#
Go 메이저 릴리스 버전은 해당 버전이 각 프로젝트의 빌드 job으로 반영될 수 있도록 아래에 나열된 모든 프로젝트를 업데이트해야 합니다. 실제 빌드 환경이 업데이트되기 전에 각 프로젝트가 성공적으로 빌드되어야 합니다.
| 컴포넌트 이름 | 작업 추적 위치 |
|---|---|
| Alertmanager | Issue Tracker |
| Docker Distribution Pruner | Issue Tracker |
| Gitaly | Issue Tracker |
| GitLab Compose Kit | Issue Tracker |
| GitLab container registry | Issue Tracker |
| GitLab Elasticsearch Indexer | Issue Tracker |
| GitLab Zoekt Indexer | Issue Tracker |
| GitLab agent server for Kubernetes (KAS) | Issue Tracker |
| GitLab Pages | Issue Tracker |
| GitLab Shell | Issue Tracker |
| GitLab Workhorse | Issue Tracker |
| LabKit | Issue Tracker |
| Spamcheck | Issue Tracker |
| GitLab Workspaces Proxy | Issue Tracker |
| Devfile Gem | Issue Tracker |
| GitLab Operator | Issue Tracker |
| Node Exporter | Issue Tracker |
| PgBouncer Exporter | Issue Tracker |
| Postgres Exporter | Issue Tracker |
| Prometheus | Issue Tracker |
| Redis Exporter | Issue Tracker |
릴리스를 위한 최종 업데이트#
위 표에 나열된 모든 컴포넌트가 성공적으로 빌드되면, 직접 책임자는 고객에게 GitLab 패키지와 Cloud Native 이미지를 제공하는 데 사용되는 빌드 이미지의 업데이트를 승인할 수 있습니다.
| 컴포넌트 이름 | 작업 추적 위치 |
|---|---|
| GitLab Omnibus Builder | Issue Tracker |
| Cloud Native GitLab | Issue Tracker |
독립적으로 릴리스되는 항목#
다음 컴포넌트도 업데이트해야 하지만, GitLab 릴리스의 Go/No-Go 결정을 막지는 않습니다. 이들이 뒤처지면 직접 책임자는 Product 및 Engineering 관리진에 에스컬레이션해야 합니다.
| 컴포넌트 이름 | 작업 추적 위치 |
|---|---|
| GitLab Browser-based DAST | Issue Tracker |
| GitLab Coverage Fuzzer | Issue Tracker |
GitLab CLI (glab). |
Issue Tracker |
커뮤니케이션 계획#
커뮤니케이션은 프로세스 전반의 여러 핵심 시점에 필요하며, 완료 정의의 일부로 해당 이슈에 포함되어야 합니다.
- 에픽을 만든 직후 Slack에 게시해야 합니다. 커뮤니티 기여자는 이 단계를 도와줄 엔지니어링 매니저를 멘션해 요청해야 합니다. 담당 GitLab 팀원은 다음 Slack 채널에 에픽 링크를 공유해야 합니다.
#backend#development
- GitLab Development Kit 업데이트를 머지한 직후, 같은 메인테이너가 엔지니어링 주간 리뷰 싱크에 항목을 추가하고
다음 Slack 채널에 변경 사항을 공지해야 합니다.
#backend#development
- Cloud-Native GitLab과
Omnibus GitLab에서 업데이트된 Go 버전이
머지되는 즉시 엔지니어링 주간 리뷰 싱크에 변경 사항을 추가하고 다음 Slack
채널에
공지합니다.
#backend#development#releases
업그레이드 검증#
업스트림 컴포넌트 메인테이너는 다음을 사용해 Go 기반 프로젝트를 검증해야 합니다.
- 코드베이스에 마련된 단위 테스트.
- 머지 리퀘스트 성능 가이드라인에 정해진 절차.
- 성능, 신뢰성, 가용성 가이드라인에 정해진 절차.
업스트림 컴포넌트 메인테이너는 다음을 사용해 Go 기반 프로젝트를 검증하는 방안도 고려해야 합니다.
-
컴포넌트 단독 동작 성능 테스트.
통합 테스트는 비용이 크며 컴포넌트 간 운영 문제를 확인하는 데 써야 합니다. 컴포넌트를 단독으로 테스트하면 업데이트에 대한 평균 피드백 시간이 줄고 조직 전체의 자원 소모도 줄어듭니다.
-
컴포넌트는 GitLab Performance Test 도구에서 엔드 투 엔드 테스트 커버리지를 갖추어야 합니다.
-
다음 환경에 대해 새 패키지 설치와 이전 버전에서의 업그레이드를 통한 통합 검증.
- 단일 GitLab 노드
- 레퍼런스 아키텍처 배포
- Geo 배포