Go 버전 관리
GitLab v19.1GitLab 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의 호환성 약속에도 불구하고, 마이너 버전 간의 변경 사항은 프로젝트에서 버그를 노출하거나 문제를 일으킬 수 있습니다.
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가 승인한 기능을 추가하는 경우 필요합니다.
자세한 내용은 다음을 참조하세요:
업그레이드 프로세스#
업그레이드 프로세스에는 여러 핵심 단계가 포함됩니다:
작업 추적#
-
다음 변수를 사용하여 드라이 런(dry run)을 위한 새 파이프라인을 생성합니다:
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 |
커뮤니케이션 계획#
프로세스 전반의 여러 핵심 시점에서 커뮤니케이션이 필요하며, 완료 정의(definition of done)의 일부로 관련 이슈에 포함되어야 합니다:
- 에픽을 생성한 직후, 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 배포