Go 버전 관리하기

개요

GitLab Runner와 Security Projects를 제외한 모든 Go 실행 파일은 분배 팀에서 관리하는 프로젝트에서 빌드됩니다.

Omnibus GitLab 프로젝트는 모든 실행 파일을 포함하는 단일한 모노리식 운영 체제 패키지를 만들고, Cloud-Native GitLab (CNG) 프로젝트는 Helm 차트 또는 GitLab Operator로 배포 및 구성된 일련의 Docker 이미지를 배포합니다.

배송된 Go 버전에 대한 테스트

Go를 사용하는 모든 프로젝트의 테스트 매트릭스에는 분배에 의해 배송된 버전을 포함해야 합니다. 다음에서 GO_VERSION으로 설정된 Go 버전을 확인하세요:

여러 Go 버전 지원

개별 Go 프로젝트는 여러 Go 버전을 지원해야 합니다. 왜냐하면:

Go의 새 버전이 출시되면 새 컴파일러와의 호환성을 확인하기 위해 CI 파이프라인에 통합해야 합니다.
분배에서 배송하는 Go 버전을 지원해야 합니다. 이는 최신의 마이너 버전보다 낮을 수 있습니다.
Linux 패키지 빌드나 Cloud-Native GitLab (CNG)에서 Go 버전을 변경하면 여전히 이전 버전을 백포트할 필요가 있을 수 있습니다.

이러한 3가지 요구사항은 간단히 Go의 3가지 최신 마이너 버전을 지원하여 충족될 수 있습니다.

지원하는 Go 버전 중 가장 오래된 버전의 지원을 중단하고 최근 2개 릴리스만 지원하는 것도 좋습니다. 이것이 마지막 3가지 마이너 GitLab 릴리스로 백포팅을 지원하는 데 충분한 경우입니다.

예를 들어, GitLab 12.10에서 go 1.11의 지원을 중단하려면, 12.9, 12.8 및 12.7에서 사용 중인 Go 버전을 확인해야 합니다. 비상 시 보안 릴리스를 위해 12.7의 백포팅이 필요하기 때문에 12.10 활성 마일스톤은 고려하지 않습니다.

만약 Omnibus GitLab와 Cloud-Native GitLab (CNG)이 12.7 이후에 Go 1.12를 사용했다면, 1.11의 지원을 안전하게 중단할 수 있습니다.
Omnibus GitLab 또는 Cloud-Native GitLab (CNG)이 12.7에서 1.11을 사용 중이라면, 보안 수정의 쉬운 백포팅을 위해 1.11의 지원을 유지해야 합니다.

Go 버전 업데이트

항상 다음을 해야 합니다:

Omnibus GitLab와 Cloud-Native GitLab에 동일한 Go 버전 사용.
지원되는 버전 사용.
해당 버전의 최신 패치 레벨 사용하여 보안 패치와 함께 유지합니다.

버전 변경은 컴파일되는 모든 프로젝트에 영향을 미치므로, 새 Go 버전에 대한 모든 프로젝트의 테스트가 완료되었는지 확인한 후 패키지 빌더를 변경하기 전에 중요합니다. Go의 호환성 약속에도 불구하고, 마이너 버전 간의 변경은 프로젝트에서 버그를 드러낼 수도 있고 문제를 발생시킬 수 있습니다.

업그레이드 프로세스

업그레이드 프로세스는 몇 가지 주요 단계를 포함합니다:

컴포넌트 업데이트 및 유효성 검사 추적.
릴리스를 위한 컴포넌트 통합 추적.
이해당사자와의 커뮤니케이션.

작업 추적

올바른 사람 또는 라벨을 찾아야 하는 경우, 제품 범주 페이지를 사용하세요:

gitlab-org 그룹에 에픽 생성:
- 에픽의 제목은 Go 버전을 <VERSION_NUMBER>로 업데이트로 지정합니다.
- 아래에 나열된 프로젝트의 엔지니어링 매니저에게 ping합니다.
  - 대부분의 엔지니어링 매니저는 제품 페이지나 기능 페이지에서 확인할 수 있습니다.
  - 여전히 엔지니어링 매니저를 찾을 수 없는 경우, 관련 프로젝트에 참여한 유지보수자를 식별하기 위해 Git blame를 사용합니다.
이전 단계에서 지시한 위치에 의존성마다 업그레이드 문제를 만듭니다:
- 지원하는 Go <VERSION_NUMBER>로 빌드하기라는 제목으로 각 의존성에 대한 업그레이드 문제를 만듭니다. 각 문제에는 더 쉬운 트리지 위해 적절한 라벨이 포함되어야 합니다. 이것에는 stage, group 및 section이 포함되어야 합니다.
- 문제는 유지 보수 그룹의 구성원에 의해 할당되어야 합니다.
- 마일스톤은 유지 보수 그룹의 구성원에 의해 할당되어야 합니다.
프로젝트 의존성 사이에 일부 중첩이 있습니다. 더 큰 제품의 일부인 의존성에 대한 문제를 만들 때, 문제 본문에 관계를 기록하세요. 예시: Omnibus GitLab 문맥에서 빌드된 프로젝트의 런타임 Go 버전은 Omnibus에 의해 관리되지만 “지원” 및 호환성은 개별 프로젝트의 문제여야 합니다. 부모 프로젝트의 의존성 문제에 대한 문제는 업데이트된 Go 버전을 지원하도록 추가해야 합니다.

업그레이드 문제에는 업그레이드 유효성 항목이 반드시 포함되어야 합니다. 작업 일정을 보조하고 작업 부하를 관리하기 위해 지원 및 성능 테스트의 동작 및 성능을 <VERSION_NUMBER> Go로 검증이라는 두 번째 성능 테스트 문제를 만드는 것이 강력히 권장됩니다.
GitLab 개발 키트로 업데이트 일정을 조정:
- 문제의 제목은 Go 버전 <VERSION_NUMBER> 사용 지원으로 지정합니다.
- 앞서 생성된 각 문제와 관련된 문제로 설정합니다.
각각의 Sec Section 팀 당 하나의 문제를 예약하고 Go 기반 보안 분석기를 유지하는 팀에 section::sec 라벨을 추가합니다:
이러한 보안 분석기의 업데이트는 Omnibus나 Charts의 업데이트를 차단해서는 안 됩니다. 분석기는 개별적으로 별도의 컨테이너 이미지로 독립적으로 빌드됩니다.
Distribution 프로젝트에서 빌더 업데이트 일정 잡기:
- 이전 단계에서 만든 의존성 및 GitLab 개발 키트 문제를 차단합니다.
- 각 문제는 다음과 같이 제목과 설명을 가지고 있어야 합니다:
  - Cloud-Native GitLab
    `ci_files/variables.yml`에서 `GO_VERSION` 업데이트.
  - Omnibus GitLab Builder
    `docker/VERSIONS`의 `GO_VERSION` 업데이트.
  - Omnibus GitLab
    `.gitlab-ci.yml`에서 `BUILDER_IMAGE_REVISION` 업데이트하여 빌더의 태그와 일치.
Omnibus GitLab 및 Cloud Native GitLab에 자동으로 업그레이드되지 않는 컴포넌트의 경우, 해당 컴포넌트의 업그레이드 문제가 차단되도록 설정하고, 컴포넌트의 업그레이드 문제에 의존합니다.

사용 중인 Go를 활용한 알려진 의존성

컴포넌트 이름	작업 추적 위치
Alertmanager	이슈 트래커
Docker Distribution Pruner	이슈 트래커
Gitaly	이슈 트래커
GitLab CLI (`glab`).	이슈 트래커
GitLab Compose Kit	이슈 트래커
GitLab 컨테이너 레지스트리	이슈 트래커
GitLab Elasticsearch Indexer	이슈 트래커
Kubernetes용 GitLab 에이전트 서버 (KAS)	이슈 트래커
GitLab Pages	이슈 트래커
GitLab 품질 이미지	이슈 트래커
GitLab Shell	이슈 트래커
GitLab Workhorse	이슈 트래커
GitLab 브라우저 기반 DAST	이슈 트래커
GitLab 커버리지 Fuzzer	이슈 트래커
LabKit	이슈 트래커
Node Exporter	이슈 트래커
PgBouncer Exporter	이슈 트래커
Postgres Exporter	이슈 트래커
Prometheus	이슈 트래커
Redis Exporter	이슈 트래커

커뮤니케이션 계획

프로세스 전반에 걸쳐 여러 중요 시점에서 커뮤니케이션이 필요하며, 완료 정의의 일부로 관련 이슈에 포함되어야 합니다:

에픽 생성 직후 Slack에 게시되어야 합니다. 커뮤니티 구성원은 해당 단계에서 ping된 엔지니어링 매니저들에게 도움을 요청해야 합니다. 책임 있는 GitLab 팀 구성원은 다음 Slack 채널에 에픽 링크를 공유해야 합니다:
- #backend
- #development
GitLab 개발 키트 업데이트를 Merge한 직후, 동일한 유지 관리자는 엔지니어링 주간 회의 동기화에 항목을 추가하고 변경 사항을 다음 Slack 채널에 발표해야 합니다:
- #backend
- #development
업데이트된 Go 버전을 Cloud-Native GitLab 및 Omnibus GitLab에서 Merge한 직후, 변경 사항을 엔지니어링 주간 회의 동기화에 추가하고 다음 Slack 채널에서 발표해야 합니다:
- #backend
- #development
- #releases

업그레이드 유효성 검증

상류 컴포넌트 유지 관리자는 다음을 사용하여 Go 기반 프로젝트의 유효성을 검증해야 합니다:

코드베이스의 확립된 단위 테스트.
Merge Request 성능 가이드라인에 규정된 절차.
성능, 신뢰성 및 가용성 가이드라인에 규정된 절차.

상류 컴포넌트 유지 관리자는 다음을 고려하여 Go 기반 프로젝트의 유효성을 검증해야 합니다:

격리된 컴포넌트 작동 성능 테스트.
통합 테스트는 비용이 많이 들며 컴포넌트 간 운영 문제를 테스트해야 합니다. 격리된 컴포넌트 테스트는 업데이트에 대한 피드백 시간을 줄이고 조직 전체의 리소스 소모를 줄입니다.
GitLab 성능 테스트 도구에서 컴포넌트가 종단 간 테스트 커버리지를 가져야 합니다.
단일 GitLab 노드 및 이전 버전에서의 업그레이드를 포함하여 신선한 패키지 설치로 통합 검증:
- 참조 아키텍처 배포
- Geo 배포