소프트웨어 컴포넌트 업그레이드

Linux 패키지는 GitLab에서 개발된 일부 소프트웨어 컴포넌트와 무료 및 오픈 소스 프로젝트에서 제공된 다른 요소들로 구성됩니다. 소프트웨어 컴포넌트는 새로운 기능, 버그 수정, 보안 취약점이 발견될 때 개별적으로 업데이트될 수 있습니다.

소프트웨어 컴포넌트의 업그레이드는 비호환성 변경 사항이 있을 때 특히 위험할 수 있습니다. 의미론적 버전]을 고려하고 변경로그 및 릴리스 노트를 검토하여 업그레이드의 위험 정도를 파악할 수 있습니다. 모든 경우에 업그레이드는 통합하기 전에 철저히 테스트되어야 합니다.

CNG 프로젝트는 일부 이와 같은 소프트웨어 컴포넌트를 사용합니다. 두 프로젝트에서 공통으로 사용하는 컴포넌트는 둘 다 업데이트되어야 합니다.

소프트웨어 컴포넌트의 종류

Linux 패키지에는 두 가지 유형의 소프트웨어 컴포넌트가 사용됩니다:

  • 외부 소프트웨어 컴포넌트
  • 내부 소프트웨어 컴포넌트

외부 소프트웨어 컴포넌트

외부 소프트웨어 컴포넌트는 외부 사이트에서 직접 다운로드하거나 omnibus-mirror 리포지터리에서 복사됩니다. 소프트웨어 컴포넌트는 git clone으로 제공될 수 있으며, 소스 tarball에서 추출하거나(Ruby 모듈의 경우) gem install을 수행하거나, (Python 모듈의 경우) pip install을 수행할 수 있습니다.

내부 소프트웨어 컴포넌트

내부 소프트웨어 컴포넌트는 GitLab 및 외부 기여자에 의해 개발됩니다. 내부 소프트웨어 컴포넌트의 소스는 프로젝트의 GitLab 리포지터리에서 다운로드됩니다. 빌드에 사용되는 버전은 해당 프로젝트에 해당하는 *VERSION 파일에 포함된 Git 참조로 설정됩니다. 이러한 버전은 환경 변수로 재정의할 수 있습니다. 자세한 정보는 GitLab 컴포넌트의 특정 브랜치 또는 버전 사용하기를 참조하십시오.

내부 소프트웨어 컴포넌트의 업데이트는 해당 리포지터리에서의 Merge Request을 통해 이루어집니다.

내부 소프트웨어 컴포넌트 업데이트 워크플로우

내부 소프트웨어 컴포넌트를 업데이트하는 일반적인 워크플로우입니다.

포크/브랜치 생성

외부 기여자는 gitlab-org/omnibus-gitlab 리포지터리를 포크해야 합니다.

타겟 브랜치(일반적으로 master)에서 gitlab-org/omnibus-gitlab 리포지터리에서 새로운 브랜치를 생성합니다.

config/software/<component.rb> 수정

  1. 구성하려는 컴포넌트에 대한 해당 구성 파일을 config/software 디렉터리에서 찾습니다. 예를 들어 config/software/prometheus.rb은 Prometheus 컴포넌트에 사용됩니다.

  2. 원하는 버전으로 버전을 변경합니다. 적용 가능한 경우 해당하는 sha256도 해당 버전 소스 tarball의 값으로 변경하십시오.

필요한 패치 추가 또는 수정

새로운 컴포넌트 버전에 따라 다음이 필요할 수 있습니다:

  • 새로운 패치 추가
  • 기존 패치 제거
  • 기존 패치 변경

모든 패치 파일은 config/patches/<component name>에 저장됩니다. 그런 다음 해당 config/software/<component name>.rb 파일에서 참조됩니다. 예시는 다음에서 찾을 수 있습니다:

브랜치 푸시

브랜치를 상위 리포지터리에 푸시합니다.

Merge Request (MR) 생성

개발 브랜치와 타겟 브랜치를 사용하여 Merge Request을 생성합니다.

빌드

Linux 패키지를 다음 중 하나를 사용하여 빌드합니다:

Merge Request을 승인하기 전에 CI/CD 시스템을 사용하여 모든 아키텍처에서 빌드해야 합니다.

테스트

결과로 나온 Linux 패키지를 설치하고 컴포넌트 변경사항을 테스트합니다.

소프트웨어 컴포넌트 업데이트 테스트

최소한의 테스트 요구 사항

소프트웨어 컴포넌트를 업데이트할 때는 최소한 다음 테스트를 수행해야 합니다.

  • 모든 지원 플랫폼에서 성공적인 GitLab Enterprise Edition (EE) 빌드 수행
  • GitLab Enterprise Edition 및 GitLab Community Edition 모두에 대해 qa-subset-test 및 매뉴얼 qa-remaining-test-manual CI/CD 테스트 작업 실행
  • 컴포넌트 버전이 업그레이드되었는지 설치하고 확인합니다.
  • 소프트웨어 컴포넌트의 기본 기능 확인

거의 항상 추가 테스트가 필요하며, 소프트웨어 컴포넌트에 따라 다양합니다.

테스트 계획

다음은 개별 컴포넌트에 대한 테스트 계획입니다. 이들은 실행이 기록될 수 있는 Merge Request에 복사되어야 합니다.

이곳에 나열되지 않은 컴포넌트들이 있을 수 있습니다. 작업 중인 컴포넌트 업그레이드를 위해 Merge Request을 생성하는 것을 고려해주십시오. 시작점으로 test-plans/upgrade-component-testplan-template.md를 사용하십시오.

이 테스트 계획은 전제가 아닙니다. 컴포넌트에 따라 추가 기록이 필요할 수 있습니다. 이러한 추가 사항은 Merge Request에서 기록하고 여기에도 추가해주십시오. 테스트 계획 파일을 작성할 때 다음 파일 이름 패턴을 사용하십시오: 

upgrade-<component-name>-testplan.md

그리고 test-plans/index.md에 링크를 추가하십시오.