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

Linux 패키지는 GitLab에서 개발한 일부와 자유 및 오픈 소스 프로젝트에서 출처를 찾은 others으로 구성된 여러 소프트웨어 구성 요소로 만들어집니다. 새로운 기능, 버그 수정 및 보안 취약점이 제공될 때 소프트웨어 구성 요소를 개별적으로 업데이트할 수 있습니다.

소프트웨어 구성 요소 업그레이드는 위험할 수 있으며, 특히 이전 버전과 호환되지 않는 변경 사항이 발생할 때 그렇습니다. Semantic versioning을 고려하고, 변경 로그를 검토하며, 릴리스 노트를 확인하면 업그레이드와 관련된 위험 요소를 파악하는 데 도움이 될 수 있습니다. 모든 경우에 업그레이드는 병합 전에 철저하게 테스트해야 합니다.

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

소프트웨어 구성 요소의 유형

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

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

외부 소프트웨어 구성 요소

외부 소프트웨어 구성 요소 소스는 외부 사이트에서 직접 다운로드하거나 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 디렉토리에서 업데이트하려는 구성 요소에 해당하는 구성 파일을 찾습니다. 예를 들어, config/software/prometheus.rb는 Prometheus 구성 요소에 사용됩니다.
  2. 버전을 업데이트하려는 버전으로 변경합니다. 해당되는 경우, 해당 버전 소스 tarball의 sha256 값도 변경합니다.

필요한 패치 추가 또는 수정

새 구성 요소 버전은 다음과 같은 요구 사항이 있을 수 있습니다:

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

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

브랜치 푸시

브랜치를 업스트림 리포지토리에 푸시합니다.

병합 요청(MR) 생성

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

빌드

Linux 패키지를 빌드하는 방법은 다음과 같습니다:

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

테스트

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

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

최소 테스트 요구 사항

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

  • 모든 지원되는 플랫폼에서 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에 링크를 추가하세요.