• 개요
• 제공된 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 버전이 출시되면 CI 파이프라인에 이를 통합하여 새 컴파일러와의 호환성을 검증해야 합니다. - Distribution에서 제공하는 Go 버전을 지원해야 하며, 이는 최신의 마이너 릴리스보다 뒤에 있을 수 있습니다. - Linux 패키지 빌드나 Cloud-Native GitLab (CNG)에서 Go 버전을 변경하면, 백포트를 위해 이전 버전을 지원해야 할 수 있습니다.

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

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

예를 들어, 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 이후로 1.12를 사용했다면, 우리는 안전하게 1.11 지원을 중단할 수 있습니다.
• Omnibus GitLab 또는 Cloud-Native GitLab (CNG)가 1.11을 GitLab 12.7에서 사용했다면, 보안 수정을 쉽게 백포팅하기 위해 1.11 지원을 계속해야 합니다.

Go 버전 업데이트

항상 다음을 해야 합니다: - Omnibus GitLab와 Cloud Native GitLab에 동일한 Go 버전 사용. - 지원되는 버전 사용. - 보안 수정에 대응하기 위해 해당 버전의 가장 최근 패치 수준 사용.

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

업그레이드 과정

업그레이드 과정에는 몇 가지 중요한 단계가 포함됩니다: - 구성 요소 업데이트와 유효성 검사 추적. - 릴리스에 대한 구성 요소 통합 추적. - 이해관계자와의 의사 소통.

작업 추적

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

1. gitlab-org 그룹에서 에픽 생성:
   • 에픽 제목은 Go 버전을 <VERSION_NUMBER>으로 업데이트로 지정합니다.
   • 다음 프로젝트에 대한 담당 엔지니어매니저를 핑합니다[#known-dependencies-using-go].
     • 대부분의 엔지니어매니저는 제품 페이지 또는 기능 페이지에서 확인할 수 있습니다.
     • 여전히 엔지니어매니저를 찾을 수 없는 경우, 프로젝트에 관여한 유지보수자를 식별하기 위해 Git blame를 사용하세요.
2. 이전 단계에서 지정된 위치에 있는 각 종속성을 위해 업그레이드 이슈를 만듭니다:
   • 각 문제에 올바른 라벨을 추가하여 쉬운 삼분하는 작업을 돕기 위해 Support building with Go <VERSION_NUMBER>라는 제목을 지정합니다.
   • 이슈는 유지되는 그룹의 구성원에 의해 할당되어야 합니다.
   • 마일스톤은 유지된 그룹의 구성원에 의해 할당되어야 합니다.

   참고: 프로젝트 종속성들 간에 중첩이 있습니다. 대규모 제품의 종속성 중 하나에 대한 이슈를 만들 때, 이슈 본문에 관련성을 기술하세요. 예를 들어: Omnibus GitLab 컨텍스트에서 빌드된 프로젝트의 런타임 Go 버전이 Omnibus에서 관리되지만, “지원”과 호환성은 개별 프로젝트의 고려사항이어야 합니다. 상위 프로젝트의 종속성 이슈는 업데이트된 Go 버전을 지원하는 데 관한 것이어야 합니다.

   참고: 업그레이드 이슈는 테스트 항목인 업그레이드 검증 항목을 정의해야 합니다. 작업 일정을 도와주고 작업 부하를 관리하기 위해 두 번째 성능 테스트 이슈인 Go <VERSION_NUMBER>로 작동 및 성능 유효성 검사를 만드는 것이 강력히 권장됩니다.

3. GitLab 개발 키트에서 업데이트 예정인 이슈를 일정에 추가합니다:
   • 이슈 제목은 Go 버전 <VERSION_NUMBER> 사용 지원입니다.
   • 이전 단계에서 만든 각 이슈와 연관된 것으로 설정합니다.
4. Sec Section 팀 당 한 개의 이슈를 일정에 추가하고 각각의 “section::sec” 라벨을 추가합니다:
   • 정적 분석 트래커.
   • Composition 분석 트래커.
   • 컨테이너 보안 트래커.

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

5. Distribution 프로젝트에서 빌더 업데이트 일정을 추가한다:
   • 이전 단계에서 생성한 종속성 및 GitLab 개발 키트 이슈들을 차단 상태로 설정합니다.
   • 각각의 이슈에 대해 다음과 같은 제목과 설명을 추가하세요:

     • Cloud-Native GitLab

       `ci_files/variables.yml`의 `GO_VERSION`을 업데이트하세요.
       

     • Omnibus GitLab Builder

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

     • Omnibus GitLab

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

   참고: 만약 구성 요소가 Omnibus GitLab과 Cloud Native GitLab에 자동으로 업그레이드되지 않는 경우, 해당 구성 요소의 업그레이드 이슈가 차단된 상태로COMPONENT_NAME의 번들 버전을 업데이트라는 제목으로 해당 트래커에 열리는 것이어야 합니다.

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

구성 요소 이름	작업 추적 위치
Alertmanager	이슈 트래커
Docker Distribution Pruner	이슈 트래커
Gitaly	이슈 트래커
GitLab CLI (glab).	이슈 트래커
GitLab Compose Kit	이슈 트래커
GitLab 컨테이너 레지스트리	이슈 트래커
GitLab Elasticsearch Indexer	이슈 트래커
Kubernetes용 GitLab 에이전트 서버 (KAS)	이슈 트래커
GitLab Pages	이슈 트래커
GitLab Quality Images	이슈 트래커
GitLab Shell	이슈 트래커
GitLab Workhorse	이슈 트래커
GitLab 브라우저 기반 DAST	이슈 트래커
GitLab 커버리지 퍼저	이슈 트래커
LabKit	이슈 트래커
Node Exporter	이슈 트래커
PgBouncer Exporter	이슈 트래커
Postgres Exporter	이슈 트래커
Prometheus	이슈 트래커
Redis Exporter	이슈 트래커

커뮤니케이션 계획

프로세스 전반에 걸쳐 특정한 시점에서 커뮤니케이션이 요구되며, 완료 정의의 일환으로 관련 이슈에 포함되어야 합니다:

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

업그레이드 유효성 검사

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

• 코드베이스의 확립된 단위 테스트.
• 병합 요청 성능 지침에 확립된 절차.
• 성능, 신뢰성 및 가용성 지침에 확립된 절차.

상류 구성 요소 유지자는 다음으로 Go 기반 프로젝트를 유효성 검사해야 합니다:

• 격리된 구성 요소 운영 성능 테스트.

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

• 구성 요소는 GitLab Performance Test 도구에서 엔드 투 엔드 테스트 커버리지를 가져야 합니다.
• 다음을 위한 설치 및 업그레이드를 통한 통합 검증:
  • 단일 GitLab 노드
  • 참조 아키텍처 배포
  • Geo 배포