ソフトウェア・コンポーネントのアップグレード

Linuxパッケージは、GitLabによって開発されたものや、フリーでオープンソースのプロジェクトから提供されたものなど、一連のソフトウェアコンポーネントから作られています。ソフトウェア・コンポーネントは、新機能やバグ修正、セキュリティ脆弱性の発見に応じて個別にアップデートすることができます。

ソフトウェアコンポーネントのアップグレードは、特に後方互換性のない変更が行われた場合、リスクが高くなる可能性があります。セマンティック・バージョニング]を考慮したり、変更履歴を調べたり、リリースノートを調べたりすることで、アップグレードに伴うリスクの大きさを知ることができます。どのような場合でも、アップグレードはマージする前に徹底的にテストされるべきです。

CNGプロジェクトは、これらと同じソフトウェアコンポーネントのいくつかを使用しています。両方のプロジェクトに共通するコンポーネントは、両方で更新されるべきです。

ソフトウェアコンポーネントの種類

Linuxパッケージで使用されるソフトウェアコンポーネントには2種類あります：

  • 外部ソフトウェア・コンポーネント
  • 内部ソフトウェアコンポーネント

外部ソフトウェア・コンポーネント

外部ソフトウェアコンポーネントのソースは、外部サイトから直接ダウンロードするか、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. バージョンを更新したいバージョンに変更します。該当する場合は、対応するsha256 も、対応するバージョンのソース tarball の値に変更します。

必要なパッチを追加または変更します。

新しいコンポーネントのバージョンは

  • 新しいパッチの追加
  • 既存のパッチの削除
  • 既存のパッチの変更

すべてのパッチファイルはconfig/patches/<component name> にあります。そして、対応するconfig/software/<component name>.rb ファイルで参照されます。例は以下にあります：

ブランチをプッシュ

ブランチをアップストリームリポジトリにプッシュします。

マージリクエストの作成(MR)

開発ブランチとターゲットブランチを使用してマージリクエストを作成します。

ビルド

Linux パッケージをビルドします：

更新されたソフトウェアコンポーネントのマージリクエストを受け付ける前に、CI/CD システムを使用してすべてのアーキテクチャでビルドする必要があります。

テスト

出来上がったLinuxパッケージをインストールし、コンポーネントの変更をテストします。

ソフトウェア・コンポーネントのアップデートのテスト

最小テスト要件

ソフトウェア・コンポーネントを更新する際には、最低限、以下のテストを実施する必要があります。

  • GitLab Enterprise Edition(EE) のビルドを、サポートされているすべてのプラットフォームで成功させてください。
  • qa-test CI/CD テストジョブを GitLab Enterprise Edition と GitLab Community Edition の両方で実行します。
  • インストールし、コンポーネントのバージョンがアップグレードされたことを確認します。
  • ソフトウェアコンポーネントの基本的な機能を確認します。

追加テストはほとんどの場合必要で、ソフトウェアコンポーネントによって異なります。

テスト計画

個々のコンポーネントのテスト計画です。これらはマージリクエストにコピーされ、その実行が記録されるようになっています。

すべてのコンポーネントがここに記載されているわけではありません。あなたが作業しているコンポーネントのアップグレードについて、マージリクエストを作成して追加することを検討してください。test-plans/upgrade-component-testplan-template.md を出発点として使用してください。

これらのテスト計画は網羅的なものではありません。コンポーネントに加えられた変更の度合いに応じて、補足する必要があるかもしれません。これらの追加をマージリクエストに記録し、ここに追加することを検討してください。テスト計画ファイルを作成するときは、次のファイル名パターンを使用してください：

upgrade-<component-name>-testplan.md

そして、test-plans/index.md にリンクを追加してください。