Go 버전 관리

개요

모든 Go 바이너리는 GitLab Runner 및 보안 프로젝트를 제외하고는 배포팀이 관리하는 프로젝트에서 빌드됩니다.

Omnibus GitLab 프로젝트는 모든 바이너리가 포함된 단일 모노리스 운영 체제 패키지를 생성하며, Cloud-Native GitLab (CNG) 프로젝트는 Helm Charts 또는 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.10은 고려하지 않습니다.

  • 만약 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을 사용하고 있었다면, 우리는 보안 수정을 더 쉽게 백포트할 수 있도록 Go 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>로 설정한 업그레이드 이슈를 생성합니다. 각 이슈에 적절한 레이블을 추가하여 분류를 쉽게 합니다. 여기에는 단계, 그룹 및 섹션이 포함되어야 합니다.
    • 이슈는 유지 관리 그룹의 구성원이 할당해야 합니다.
    • 이정표는 유지 관리 그룹의 구성원이 할당해야 합니다.

    참고: 프로젝트 종속성 간에 일부 중복이 존재합니다. 더 큰 제품의 일부인 종속성에 대해 이슈를 생성할 때는 이슈 본문에 관계를 명시하세요. 예를 들어: Omnibus GitLab의 맥락에서 구축된 프로젝트는 런타임 Go 버전이 Omnibus에 의해 관리되지만 “지원” 및 호환성은 개별 프로젝트의 문제가 되어야 합니다. 부모 프로젝트의 종속성 이슈에서 문제는 업데이트된 Go 버전 지원 추가에 관한 것이어야 합니다.

    참고: 업그레이드 이슈는 완료 정의에 업그레이드 검증 항목을 포함해야 합니다. Validate operation and performance at scale with Go <VERSION_NUMBER>라는 제목의 두 번째 성능 테스트 이슈를 만드는 것이 일정을 계획하고 작업 부하를 관리하는 데 강력히 권장됩니다.

  3. GitLab 개발 키트와 업데이트 일정을 잡습니다:
    • 이슈 제목을 Support using Go version <VERSION_NUMBER>로 설정합니다.
    • 이전 단계에서 생성된 모든 이슈에 해당 이슈를 관련으로 설정합니다.
  4. Go 기반 보안 분석기를 유지 관리하는 섹션 팀당 하나의 이슈를 예약하고 각 이슈에 section::sec 레이블을 추가합니다:

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

  5. 배포 프로젝트와 함께 빌더 업데이트를 예약합니다:
    • 이전 단계에서 생성된 종속성 및 GitLab 개발 키트 이슈는 차단기로 설정되어야 합니다.
    • 각 이슈는 Support building with Go <VERSION_NUMBER>라는 제목과 다음과 같은 설명을 가져야 합니다:

    참고: Omnibus GitLab 및 클라우드 네이티브 GitLab에서 구성 요소가 자동으로 업그레이드되지 않는 경우, 해당 추적기에 Updated bundled version of COMPONENT_NAME라는 제목으로 이슈를 열고 구성 요소의 업그레이드 이슈에 의해 차단되도록 설정해야 합니다.

Go 사용 시 알려진 종속성

구성 요소 이름 작업 추적 위치
Alertmanager 이슈 트래커
Docker Distribution Pruner 이슈 트래커
Gitaly 이슈 트래커
GitLab CLI (glab). 이슈 트래커
GitLab Compose Kit Issuer Tracker
GitLab container registry 이슈 트래커
GitLab Elasticsearch Indexer 이슈 트래커
GitLab Zoekt Indexer 이슈 트래커
GitLab agent server for Kubernetes (KAS) 이슈 트래커
GitLab Pages 이슈 트래커
GitLab Quality Images 이슈 트래커
GitLab Shell 이슈 트래커
GitLab Workhorse 이슈 트래커
GitLab Browser-based DAST 이슈 트래커
GitLab Coverage Fuzzer 이슈 트래커
LabKit 이슈 트래커
Node Exporter 이슈 트래커
PgBouncer Exporter 이슈 트래커
Postgres Exporter 이슈 트래커
Prometheus 이슈 트래커
Redis Exporter 이슈 트래커

커뮤니케이션 계획

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

  1. 에픽을 생성한 직후, Slack에 게시해야 합니다. 커뮤니티 구성원은 이 단계에 대한 도움을 요청하기 위해 언급된 엔지니어링 관리자에게 문의해야 합니다. 책임있는 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 노드
    • 참조 아키텍처 배포
    • Geo 배포