• 概要
• 複数の Go バージョンをサポート
• Go バージョンの更新
  • アップグレード手順
    • 作業の追跡
    • Goを使った既知の依存関係
    • コミュニケーションプラン
    • アップグレードの検証

Go バージョンの管理

概要

GitLab Runnerと セキュリティプロジェクトを除くすべてのGoバイナリは、ディストリビューションチームが管理するプロジェクトでビルドされます。

Omnibus GitLabプロジェクトは、すべてのバイナリを含む単一のモノリシックなオペレーティングシステムパッケージを作成し、Cloud-Native GitLab(CNG)プロジェクトは、ChartmまたはGitLab Operatorによってデプロイおよび設定されたDockerイメージのセットを公開します。

Goを使用するすべてのプロジェクトのテストマトリックスには、ディストリビューションから出荷されたバージョンを含める必要があります：

• Omnibus GitLabで出荷されているGoのバージョンを確認してください。
• Cloud-Native GitLab(CNG) で出荷されているGo バージョンを確認してください。

複数の Go バージョンをサポート

個々の Go プロジェクトは複数の Go バージョンをサポートする必要があります：

• Goの新しいバージョンがリリースされたら、新しいコンパイラとの互換性を検証するために、CIパイプラインへのインテグレーションを開始する必要があります。
• Omnibus GitLab Goの公式バージョンをサポートしなければなりませんが、最新のマイナーリリースより遅れている可能性があります。
• OmnibusがGoのバージョンを切り替えた場合でも、セキュリティバックポートのために古いバージョンをサポートする必要があるかもしれません。

これら3つの要件は、Goの3つの最新マイナーバージョンのサポートを維持することで簡単に満たすことができます。

直近の3つのマイナーリリースへのバックポートをサポートするのに十分であれば、最も古いGoバージョンのサポートをやめて最新の2つのリリースのみをサポートしてもかまいません。

たとえば、GitLab12.10 のgo 1.11 のサポートをやめたい場合、12.9 、12.8 、12.7でどの Go バージョンを使っているかを確認する必要があります。アクティブなマイルストーンである12.10は考慮しません。なぜなら、クリティカルなセキュリティリリースの場合は12.7 のバックポートが必要だからです。

• もし、Omnibus GitLabとCloud-Native GitLab(CNG)の両方がGitLab12.7 以降でGo1.12 を使っていたのであれば、1.11のサポートを中止しても大丈夫です。
• もしOmnibus GitLabやCloud-Native GitLab(CNG) がGitLab12.7で1.11 を使っていたのであれば、セキュリティ修正のバックポートを容易にするために、Go1.11 のサポートを維持する必要があります。

Go バージョンの更新

常に

• Omnibus GitLabとCloud Native GitLabで同じGoバージョンを使用します。
• サポートされているバージョンを使用してください。
• セキュリティ修正に対応するために、そのバージョンの最新のパッチレベルを使用してください。

バージョンの変更はコンパイルされるすべてのプロジェクトに影響するので、パッケージビルダーを変更する前に、すべてのプロジェクトが新しい Go バージョンに対してテストするように更新されていることを確認することが重要です。Go の互換性が約束されているにもかかわらず、マイナーバージョン間の変更によってバグが露呈したり、プロジェクトに問題が発生したりすることがあります。

アップグレード手順

アップグレードプロセスには、いくつかの重要なステップがあります：

• コンポーネントの更新と検証を追跡します。
• リリースのためのコンポーネントインテグレーションを追跡します。
• ステークホルダーとのコミュニケーション

作業の追跡

正しい担当者やラベルを探すのにお困りの場合は、製品カテゴリーページをご利用ください：

1. gitlab-org グループにエピックを作成します：
   • エピックのタイトルUpdate Go version to <VERSION_NUMBER>.
   • 以下のプロジェクトの責任者であるエンジニアリング・マネージャーにPingを打ってください。
     • ほとんどのエンジニアリングマネージャーは、製品ページまたは機能ページで確認できます。
     • それでもエンジニアリングマネージャーが見つからない場合は、Git blameを使ってプロジェクトに参加しているメンテナーを特定しましょう。
2. 依存関係ごとにアップグレードのイシューを、Support building with Go <VERSION_NUMBER> というタイトルの下にある場所に作成します。トリアージを簡単にするために、それぞれのイシューに適切なラベルを追加します。ステージ、グループ、セクションを含めてください。
   • イシューはメンテナー・グループのメンバが割り当てます。
   • マイルストーンはメンテナー・グループのメンバーによって割り当てられる必要があります。
   プロジェクトの依存関係には重複があります。より大きな製品の一部である依存関係のイシューを作成する場合は、イシュー本文にその関係を記述してください。例えばOmnibus GitLab のコンテキストでビルドされたプロジェクトのランタイム Go バージョンは Omnibus によって管理されますが、「サポート」と互換性は個々のプロジェクトの問題です。親プロジェクトの依存関係のイシューでは、更新されたGoバージョンのサポートを追加してください。
   アップグレードのイシューには、アップグレード検証項目をTo-Doの定義に含める必要があります。タスクのスケジューリングやワークロードの管理に役立てるため、Validate operation and performance at scale with Go <VERSION_NUMBER> というタイトルの2つ目のパフォーマンステスト課題を作成することを強くお勧めします。
3. GitLab Development Kit を使ってアップデートをスケジュールします：
   • イシューのタイトルSupport using Go version <VERSION_NUMBER>.
   • issueを、前のステップで作成したすべてのissueに関連するものとして設定します。
4. Goベースのセキュリティ・アナライザを管理するSec Sectionチームごとに1つのイシューをスケジュールし、それぞれにsection::sec ：
   • 静的解析トラッカー。
   • コンポジション分析トラッカー
   • コンテナセキュリティトラッカー。
   これらのセキュリティアナライザのアップデートが、Chart や Omnibus のアップグレードを妨げることはありません。
5. ディストリビューション・プロジェクトでビルダーの更新をスケジュールします：
   • 前のステップで作成した依存性と GitLab Development Kit のイシューをブロッカーとして設定してください。
   • それぞれのイシューには、Support building with Go <VERSION_NUMBER> というタイトルと説明を記述してください：

     • クラウドネイティブ GitLab

        Update the `GO_VERSION` in `ci_files/variables.yml`.
       

     • Omnibus GitLab ビルダー

        Update `GO_VERSION` in `docker/VERSIONS`.
       

     • Omnibus GitLab

        Update `BUILDER_IMAGE_REVISION` in `.gitlab-ci.yml` to match tag from builder.
       

   コンポーネントがOmnibus GitLabと Cloud Native GitLabのために自動的にアップグレードされない場合、それぞれのトラッカーにUpdated bundled version of COMPONENT_NAME というタイトルでイシューを開き、コンポーネントのアップグレードのイシューによってブロックされるように設定する必要があります。

Goを使った既知の依存関係

コミュニケーションプラン

コミュニケーションは、プロセス全体を通じていくつかの重要なポイントで必要とされ、「To-Do」の定義の一部として関連イシューに含める必要があります：

1. エピック作成後、すぐにSlackに投稿してください。コミュニティ・メンバーは、このステップについて、ピングされたエンジニアリング・マネージャーに支援を求める必要があります。担当の GitLab チームメンバーは、以下の Slack チャンネルでエピックへのリンクを共有する必要があります：
   • #backend
   • #development
2. GitLab Development Kit Updateをマージした直後に、同じメンテナーはエンジニアリングウィークインレビュー同期にエントリーを追加し、以下のSlackチャンネルで変更をアナウンスしてください：
   • #backend
   • #development
3. Cloud-Native GitLabとOmnibus GitLabの Go バージョンのアップデートをマージした直後に、engineering-week-in-review sync に変更を追加し、以下の Slack チャンネルでアナウンスしてください：
   • #backend
   • #development
   • #releases

アップグレードの検証

アップストリーム コンポーネントのメンテナーは、Go ベースのプロジェクトを検証する必要があります：

• コードベースに確立されたユニットテスト。
• マージリクエストパフォーマンスガイドラインで確立された手順。
• パフォーマンス、信頼性、および可用性のガイドラインで確立された手順。

アップストリーム・コンポーネントのメンテナーは、Goベースのプロジェクトの検証を検討すべきです：

• 分離されたコンポーネントのオペレーション性能テスト。

  インテグレーションテストにはコストがかかるため、コンポーネント間のオペレーションに関する問題をテストする必要があります。コンポーネントを分離してテストすることで、アップデートのフィードバックまでの平均時間が短縮され、組織全体のリソース消費量が減少します。

• コンポーネントは、GitLabパフォーマンステストツールでエンドツーエンドのテストカバレッジを持つべきです。
• 新しいパッケージのインストールによるインテグレーション検証 そして以前のバージョンからのアップグレード：
  • 単一のGitLabノード
  • リファレンスアーキテクチャのデプロイ
  • デプロイ