Go 버전 관리

개요

GitLab Runner 및 Security Projects를 제외한 모든 Go 이진 파일은 Distribution team이 관리하는 프로젝트에서 빌드됩니다.

Omnibus GitLab 프로젝트는 모든 이진 파일이 포함된 단일한, 통합 운영 체제 패키지를 만들고, Cloud-Native GitLab (CNG) 프로젝트는 Helm Charts 또는 GitLab Operator에 의해 배포되고 구성된 일련의 Docker 이미지를 게시합니다.

제공된 Go 버전에 대한 테스트

Go를 사용하는 모든 프로젝트에 대한 테스트 매트릭스에는 배포된 버전이 포함되어야 합니다. GO_VERSION으로 설정된 Go 버전을 확인하세요: - 리눅스 패키지 빌드. - Cloud-Native GitLab (CNG).

여러 Go 버전 지원

개별 Go 프로젝트는 다음과 같은 이유로 여러 Go 버전을 지원해야 합니다.

  • 새 Go 버전이 출시되면 CI 파이프라인에 통합하여 새 컴파일러와의 호환성을 확인해야 합니다.
  • 배포된 Go 버전을 지원해야 하며, 이는 최신의 마이너 릴리스보다 뒤쳐질 수 있습니다.
  • 리눅스 패키지 빌드 또는 Cloud-Native GitLab (CNG)에서 Go 버전이 변경되면, 여전히 이전 버전을 지원해야 할 수 있습니다.

이러한 3가지 요구사항은 Go의 세 가지 마이너 버전을 지원함으로써 쉽게 충족할 수 있습니다.

가장 오래된 Go 버전을 지원하지 않고 최신 2개 릴리스만 지원하는 것도 괜찮습니다. 이것으로 마지막 3개의 마이너 GitLab 릴리스에 대한 백포트를 지원할 수 있다면 충분합니다.

예를 들어, GitLab 12.10에서 go 1.11을 지원 중단하려면 12.9, 12.8, 12.7에서 사용 중인 Go 버전을 확인해야 합니다. 활성 마일스톤 12.10은 고려하지 않습니다. 중요 패치 릴리스의 경우 12.7을 위한 백포트가 필요합니다.

  • Omnibus GitLab 및 Cloud-Native GitLab (CNG)이 GitLab 12.7 이후에 Go 1.12를 사용 중이라면 1.11 지원을 안전하게 중단할 수 있습니다.
  • Omnibus GitLab 또는 Cloud-Native GitLab (CNG)이 GitLab 12.7에서 1.11을 사용 중이라면 보안 패치의 간편한 백포팅을 위해 1.11 지원을 계속해야 합니다.

Go 버전 업데이트

우리는 항상 다음을 해야합니다.

  • Omnibus GitLab 및 Cloud Native GitLab에서 동일한 Go 버전을 사용합니다.
  • 지원되는 버전을 사용합니다.
  • 해당 버전의 가장 최근의 패치 수준을 사용하여 보안 패치에 대응합니다.

버전 변경은 컴파일되는 모든 프로젝트에 영향을 미치므로 새로운 Go 버전에 대한 모든 프로젝트의 테스트가 완료된 후에 패키지 빌더를 변경하기 전에 확인하는 것이 중요합니다. Go의 호환성 약속에도 불구하고 마이너 버전 간의 변경 사항은 우리 프로젝트에서 버그를 노출하거나 문제를 일으킬 수 있습니다.

업그레이드 프로세스

업그레이드 프로세스에는 다음과 같은 핵심 단계가 포함됩니다.

추적 작업

올바른 사람이나 레이블을 찾는 데 도움이 필요하다면 제품 범주 페이지를 사용하세요.

  1. gitlab-org 그룹에서 에픽 생성:
    • 에픽 제목을 Update Go version to <VERSION_NUMBER>로 지정합니다.
    • 아래 나열된 프로젝트의 엔지니어링 매니저에게 핑을 보냅니다.
      • 대부분의 엔지니어링 매니저는 제품 페이지나 기능 페이지에서 식별할 수 있습니다.
      • 여전히 엔지니어링 매니저를 찾을 수 없으면 관련 프로젝트에 관여한 유지 관리자를 식별하는 데 Git blame를 사용하세요.
  2. 아래 위치에 표시된 각 종속성에 대해 Support building with Go <VERSION_NUMBER>라는 제목의 업그레이드 이슈를 생성합니다. 각 이슈에 적절한 레이블을 추가하여 트라이지를 쉽게 할 수 있도록 합니다. 이는 stage, group 및 section을 포함해야 합니다.
    • 해당 이슈는 관리 그룹의 구성원에 의해 지정되어야 합니다.
    • 마일스톤은 관리 그룹의 구성원에 의해 지정되어야 합니다.

    참고: 일부 중첩된 프로젝트 의존성이 존재합니다. 큰 제품의 일부인 종속성을 생성할 때, 이슈 내에 관계를 기록하세요. 예를 들어: Omnibus GitLab 컨텍스트에서 구축된 프로젝트는 런타임 Go 버전이 Omnibus에 의해 관리되지만, “지원”과 호환성은 개별 프로젝트의 관심사여야 합니다. 상위 프로젝트의 종속성 이슈는 업데이트된 Go 버전을 지원하기 위한 내용이어야 합니다.

    참고: 업그레이드 이슈는 업그레이드 유효성 검증 항목을 정의해야 합니다. 예약된 작업을 지원하고 작업 부하를 관리하기 위해 Opereration and performance at scale with Go <VERSION_NUMBER>라는 두 번째 성능 테스트 이슈를 만드는 것이 강력히 권장됩니다.

  3. GitLab Development Kit에서 업데이트 예약:
    • 이슈 제목을 Support using Go version <VERSION_NUMBER>로 설정합니다.
    • 이전 단계에서 생성된 각 이슈에 대한 관련 이슈로 설정합니다.
  4. Go 기반 보안 분석기를 유지하는 Sec Section 팀 당 하나씩 일정 하세요. 각각에 section::sec 레이블을 추가합니다:

    참고: 이러한 보안 분석기의 업데이트는 Charts나 Omnibus의 업그레이드를 차단해서는 안 됩니다. 분석기는 별도로 독립적으로 별도의 컨테이너 이미지로 빌드됩니다.

  5. Distribution 프로젝트에 대한 빌더 업데이트 일정화:
    • 이전 단계에서 생성된 종속성 및 GitLab Development Kit 이슈를 차단자로 설정해야 합니다.
    • 각 이슈는 다음과 같은 형식으로 제목과 설명을 가져야 합니다:

      • Cloud-Native GitLab 

        `ci_files/variables.yml`에서 `GO_VERSION` 업데이트.

      • Omnibus GitLab Builder 

        `.gitlab-ci.yml`에서 `GO_VERSION` 업데이트하여 빌더 태그와 일치시키십시오.

      • Omnibus GitLab 

        `.gitlab-ci.yml`에서 `BUILDER_IMAGE_REVISION`을 빌더에서 태그와 일치하도록 업데이트하세요.

    참고: 컴포넌트가 Omnibus GitLab 및 Cloud Native GitLab의 빌드 버전을 자동으로 업그레이드하지 않는 경우, 컴포넌트의 업그레이드 이슈에 차단된 상태로 Updated bundled version of COMPONENT_NAME라는 제목의 이슈를 해당 추적기에 열어야 합니다.

Go를 사용하는 알려진 종속성

구성 요소 이름 작업 추적 위치
Alertmanager 이슈 추적기
Docker Distribution Pruner 이슈 추적기
Gitaly 이슈 추적기
GitLab CLI (glab). 이슈 추적기
GitLab Compose Kit 이슈 추적기
GitLab 컨테이너 레지스트리 이슈 추적기
GitLab Elasticsearch Indexer 이슈 추적기
GitLab Zoekt Indexer 이슈 추적기
쿠버네티스용 GitLab 에이전트 서버 (KAS) 이슈 추적기
GitLab Pages 이슈 추적기
GitLab 품질 이미지 이슈 추적기
GitLab Shell 이슈 추적기
GitLab Workhorse 이슈 추적기
GitLab 브라우저 기반 DAST 이슈 추적기
GitLab Coverage Fuzzer 이슈 추적기
LabKit 이슈 추적기
Node Exporter 이슈 추적기
PgBouncer Exporter 이슈 추적기
Postgres Exporter 이슈 추적기
Prometheus 이슈 추적기
Redis Exporter 이슈 추적기

커뮤니케이션 계획

프로세스 전반에 걸쳐 몇 가지 주요 시점에서 커뮤니케이션이 필요하며 완료 정의의 일환으로 관련 이슈에 포함되어야 합니다.

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

업그레이드 유효성 검사

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

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

  • 고립된 구성 요소 작동 성능 테스트.

    통합 테스트는 비용이 많이 들며 구성 요소 간 운영 문제를 테스트해야 합니다. 고립된 구성 요소 테스트는 업데이트에 대한 피드백 평균 시간을 줄이고 조직 전체의 리소스 소비를 감소시킵니다.

  • 구성 요소는 GitLab 성능 테스트 도구에서 종단간 테스트 커버리지를 가져야 합니다.
  • 다음을 통한 통합 검증: 새로운 패키지 설치 및 이전 버전에서의 업그레이드를 통해:
    • 단일 GitLab 노드
    • 참조 아키텍처 배포
    • 지오 배포