소프트웨어 구성 요소 업그레이드

리눅스 패키지는 GitLab에서 개발된 일부 소프트웨어 구성 요소와 무료 및 오픈 소스 프로젝트에서 가져온 기타 요소로 구성됩니다. 소프트웨어 구성 요소는 새로운 기능, 버그 수정 및 보안 취약점이 발견될 때마다 개별적으로 업데이트될 수 있습니다.

소프트웨어 구성 요소 업그레이드는 비호환성 변경이 이루어질 때 특히 리스크가 따를 수 있습니다. 의미 있는 버전 관리를 고려하고 변경 로그 및 릴리스 노트를 조사하면 업그레이드에 따른 리스크 정도를 파악할 수 있습니다. 모든 경우에 업그레이드는 합병하기 전에 철저히 테스트되어야 합니다.

CNG 프로젝트는 동일한 소프트웨어 구성 요소를 사용합니다. 두 프로젝트에 공통인 구성 요소는 두 곳에서 업데이트되어야 합니다.

소프트웨어 구성 요소 유형

리눅스 패키지에서 사용되는 두 가지 유형의 소프트웨어 구성 요소가 있습니다:

  • 외부 소프트웨어 구성 요소
  • 내부 소프트웨어 구성 요소

외부 소프트웨어 구성 요소

외부 소프트웨어 구성 요소는 외부 사이트에서 직접 다운로드하거나 omnibus-mirror 리포지토리에서 복사됩니다. 구성 요소는 git clone, 소스 tarball에서 추출, gem install (Ruby 모듈의 경우), 또는 pip install (Python 모듈의 경우)를 사용하여 제공될 수 있습니다.

내부 소프트웨어 구성 요소

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

내부 소프트웨어 구성 요소의 업데이트는 해당 리포지토리의 병합 요청을 통해 이루어집니다.

내부 소프트웨어 구성 요소 업데이트 워크플로우

내부 소프트웨어 구성 요소를 업데이트하기 위한 일반적인 워크플로우입니다.

포크/브랜치 생성

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

gitlab-org/omnibus-gitlab 리포지토리의 대상 브랜치(보통 master)에서 새로운 브랜치를 만듭니다.

config/software/<component.rb> 수정

  1. config/software 디렉토리에서 업데이트하려는 구성 요소에 대한 해당 구성 파일을 찾습니다. 예를 들어 prometheus.rb는 Prometheus 구성 요소에 사용됩니다.
  2. 버전을 업데이트하려는 버전으로 변경합니다. 해당하는 경우, 해당하는 버전 소스 tarball의 sha256도 해당 값으로 변경합니다.

필요한 패치 추가 또는 수정

새로운 구성 요소 버전은 다음이 필요할 수 있습니다:

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

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

브랜치 푸시

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

병합 요청 (MR) 생성

개발 브랜치와 대상 브랜치를 사용하여 병합 요청을 생성합니다.

빌드

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

업데이트된 소프트웨어 구성 요소에 대한 병합 요청을 수락하기 전에 모든 아키텍처에서 CI/CD 시스템을 사용하여 빌드해야 합니다.

테스트

결과 리눅스 패키지를 설치하고 구성 요소 변경사항을 테스트합니다.

소프트웨어 구성 요소 업데이트 테스트

최소한의 테스트 요구 사항

소프트웨어 구성 요소를 업데이트할 때 최소한 다음 테스트를 수행해야 합니다.

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

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

테스트 계획

다음은 개별 구성 요소에 대한 테스트 계획입니다. 이러한 계획은 그들의 실행이 기록될 수 있는 병합 요청에 복사되어야 합니다.

여기에 나열된 것이 모든 구성 요소라는 것은 아닙니다. 작업 중인 구성 요소 업그레이드를 위해 하나를 추가하려면 병합 요청을 만드시기 바랍니다. 시작점으로 test-plans/upgrade-component-testplan-template.md를 사용하십시오.

이러한 테스트 계획은 모든 것을 다루는 것이 아닙니다. 구성 요소에 따라 보완이 필요할 수 있습니다. 병합 요청에서 이러한 추가 정보를 기록하고 여기에 추가하는 것을 고려하십시오. 테스트 계획 파일을 만들 때 다음 파일 이름 패턴을 사용하십시오: 

upgrade-<component-name>-testplan.md

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