• 개요
• 설치된 Go 버전에 대한 테스트
• 다중 Go 버전 지원
• Go 버전 업데이트
  • 업그레이드 과정
    • 작업 추적
    • Go를 사용하는 알려진 의존성
    • 커뮤니케이션 계획
    • 업그레이드 검증

Go 버전 관리

개요

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

Omnibus GitLab 프로젝트는 모든 이진 파일을 포함하는 단일한, 거대한 운영 체제 패키지를 생성하며, Cloud-Native GitLab (CNG) 프로젝트는 Helm Charts 또는 GitLab Operator에 의해 배포 및 구성된 Docker 이미지 집합을 게시합니다.

설치된 Go 버전에 대한 테스트

Go를 사용하는 모든 프로젝트의 테스트 매트릭스에는 Distribution에서 제공하는 버전이 포함되어야 합니다. GO_VERSION으로 설정된 Go 버전을 확인하세요:

• Linux 패키지 빌드.
• Cloud-Native GitLab (CNG).

다중 Go 버전 지원

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

• 새로운 Go 버전이 출시되면 해당 버전과의 호환성을 확인하기 위해 CI 파이프라인에 통합해야 합니다.
• Distribution에서 제공하는 Go 버전을 지원해야 합니다. 이는 최신의 마이너 릴리스보다 뒤질 수 있습니다.
• Linux 패키지 빌드나 Cloud-Native GitLab (CNG)에서 Go 버전을 변경하면 여전히 이전 버전을 백포트하기 위해 지원해야 할 수 있습니다.

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

만약 이것이 마지막 3개의 GitLab 마이너 릴리스로의 백포팅을 지원하는 데 충분하다면 가장 오래된 Go 버전을 지원하지 않고 최근 2개의 릴리스만 지원하는 것은 괜찮습니다.

예를 들어, 만약 GitLab 12.10에서 go 1.11의 지원을 중단하고 싶다면, 12.9, 12.8, 12.7에서 사용하는 Go 버전을 확인해야 합니다. 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 버전에 대해 테스트되었는지 확인하는 것이 중요합니다. Go의 호환성 약속에도 불구하고, 마이너 버전 간의 변경은 우리 프로젝트에서 버그를 드러내거나 문제를 일으킬 수 있습니다.

업그레이드 과정

업그레이드 과정에는 몇 가지 핵심 단계가 포함됩니다:

• 구성요소 업데이트 및 유효성 검사 추적.
• 릴리스용 구성요소 통합 추적.
• 이해 관계자와의 의사 소통.

작업 추적

올바른 담당자나 라벨을 찾는 데 도움이 필요하면 제품 카테고리 페이지를 사용하세요:

1. gitlab-org 그룹에서 에픽을 생성하세요:
   • 에픽의 제목은 Go 버전을 <VERSION_NUMBER>으로 업데이트로 지정합니다.
   • 아래 나열된 프로젝트의 엔지니어링 매니저에게 언급하세요.
     • 대부분의 엔지니어링 매니저는 제품 페이지나 기능 페이지에서 확인할 수 있습니다.
     • 여전히 엔지니어링 매니저를 찾을 수 없다면, 관련된 프로젝트에 참여한 유지보수자를 확인하기 위해 Git blame를 사용하세요.
2. 아래 위치에서 Go를 사용하는 의존성마다 Go <VERSION_NUMBER>으로 빌드 지원이라는 제목으로 업그레이드 이슈를 생성하세요. 각 이슈에 적절한 라벨을 추가하여 트리지를 쉽게 하세요. 이는 스테이지, 그룹 및 섹션을 포함해야 합니다.
   • 해당 이슈는 유지 그룹의 구성원에 의해 할당되어야 합니다.
   • 마일스톤은 유지 그룹의 구성원에 의해 할당되어야 합니다.
   어떤 의존성이 더 큰 제품의 일부인 경우, 의존성에 대한 이슈를 만들 때 해당 관계를 이슈 본문에 기록하세요. 예시: Omnibus GitLab 컨텍스트에서 빌드된 프로젝트는 런타임 Go 버전이 Omnibus에 의해 관리되지만 “지원”과 호환성은 개별 프로젝트의 관심사여야 합니다. 상위 프로젝트의 의존성 이슈는 업데이트된 Go 버전을 지원하는 것입니다.
   업그레이드 이슈에는 업그레이드 검증 사항이 반드시 포함되어야 합니다. 또한, 프로젝트 일정을 돕고 작업 부하를 관리하기 위해 Validate operation and performance at scale with Go <VERSION_NUMBER>이라는 두 번째 성능 테스트 이슈를 생성하는 것이 매우 권장됩니다.
3. GitLab Development Kit에 업데이트 일정을 예약하세요:
   • 이슈의 제목을 Go 버전 <VERSION_NUMBER> 사용 지원으로 지정하세요.
   • 이전 단계에서 생성된 모든 이슈와 관련된 것으로 설정하세요.
4. Go 기반 보안 분석기를 유지하는 Sec Section 팀당 한 개의 이슈를 예약하고 각각에 section::sec 라벨을 추가하세요:
   • 정적 분석 추적기.
   • 구성 분석 추적기.
   • 컨테이너 보안 추적기.
   이러한 보안 분석기의 업데이트는 Charts나 Omnibus의 업그레이드를 차단해서는 안 됩니다. 이 분석기는 따로 독립적으로 빌드된 별도의 컨테이너 이미지로 구축됩니다.
5. Distribution 프로젝트에서 빌더 업데이트 일정을 예약하세요:
   • 이전 단계에서 생성된 의존성 및 GitLab 개발 키트 이슈를 차단자로 설정하세요.
   • 각 이슈마다 아래와 같이 제목을 작성하고 설명에 주의하세요:

     • Cloud-Native GitLab

       `ci_files/variables.yml`의 `GO_VERSION` 업데이트.
       

     • Omnibus GitLab 빌더

       `docker/VERSIONS`의 `GO_VERSION` 업데이트.
       

     • Omnibus GitLab

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

   만약 컴포넌트가 Omnibus GitLab와 Cloud Native GitLab에 자동으로 업그레이드되지 않는다면, 해당 컴포넌트의 업그레이드 이슈를 차단자로 설정하고 이슈를 열어야 합니다. 이 때, 컴포넌트의 업그레이드 이슈는 COMPONENT_NAME의 번들 버전 업데이트라는 제목으로 설정해야 합니다.

Go를 사용하는 알려진 의존성

커뮤니케이션 계획

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

1. 에픽 생성 직후에는 Slack에 게시되어야 합니다. 커뮤니티 멤버는 이 단계에서 ping된 엔지니어링 매니저들에게 도움을 요청해야 합니다. 해당 GitLab 팀원은 다음 Slack 채널에 에픽 링크를 공유해야 합니다:
   • #backend
   • #development
2. GitLab Development Kit Update을 Merge한 후 즉시, 동일한 관리자는 엔지니어링 주간 리뷰 싱크 및 다음 Slack 채널에서 변경 사항을 알리어야 합니다:
   • #backend
   • #development
3. 업데이트된 Go 버전을 Cloud-Native GitLab 및 Omnibus GitLab에 Merge한 직후, 해당 변경 사항을 엔지니어링 주간 리뷰 싱크에 추가하고, 다음 Slack 채널에서 알릴 필요가 있습니다:
   • #backend
   • #development
   • #releases

업그레이드 검증

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

• 코드베이스의 확립된 유닛 테스트
• Merge Request 성능 가이드라인에 정의된 절차
• 성능, 신뢰성 및 가용성 가이드라인에 정의된 절차

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

• 고립된 컴포넌트 운영 성능 테스트.

  통합 테스트는 비용이 많이 들며 상호 컴포넌트에 대한 테스트를 해야 합니다. 고립된 컴포넌트 테스트는 업데이트에 대한 피드백 시간을 줄이고 조직 전반의 리소스 소모를 줄입니다.

• 컴포넌트는 GitLab Performance Test 도구에서 최종 사용자 테스트 커버리지를 가져야 합니다.
• 다음을 통한 통합 검증: 새 패키지 설치 및 이전 버전에서의 업그레이드를 통한
  • 단일 GitLab 노드
  • 참조 아키텍처 배포
  • Geo 배포