Helmチャートリリース

チャートのバージョン管理

メジャーリリース

メジャーリリースとは、ChartやGitLabのリリースにおいて、変更点や重要なマイルストーンのためのものです。

私たちはメジャーバージョン番号をバンプします：

  • 重要な追加や変更。例えば、Pagesをデフォルトで追加したり、NGINXを完全に削除したりします。
  • GitLabやチャートの変更があり、既存のインストールを手動でアップグレードする必要がある場合。
  • GitLabイメージのメジャーアップデート（例えば、12.0.0のリリース）。

マイナーリリース

マイナーリリースはGitLabイメージのマイナーリリースと繰り返し、Chartでの変更については独自の判断で行います。

私たちはこのリリースをバンプします：

  • GitLabのすべてのマイナーバージョンアップ
  • リソースの使用量を増加させる可能性のあるチャートのデフォルト値の変更（サブチャートまたはポッドの追加、追加サービスまたはイングレスの追加）
  • その他の機能変更で、より可視化する必要があると思われるもの。

パッチリリース

パッチリリースは、前回のリリースに対する非常に安定したアップデートと考えられる変更に対するリリースです。これにはGitLabイメージのパッチリリースも含まれます。

私たちはこのリリースをバンプします：

  • GitLab イメージのパッチリリース
  • マイナーバージョンやメジャーバージョンをバンプさせない変更のコレクション。

リリースシナリオの例

ChartバージョンGitLabバージョンリリースシナリオ
0.2.011.0.0GitLab 11のリリースとチャートベータ
0.2.111.0.1GitLabパッチリリース
0.2.211.0.1Chartの変更リリース
0.2.311.0.2GitLabパッチリリース、それに伴うChartの一部変更
0.3.011.1.0GitLabのマイナーリリースと、それに伴う新しいChartの変更。
0.4.011.1.0マイナーバージョンアップに含める意味があると思われるチャートの変更
0.2.411.0.3セキュリティリリース
0.3.111.1.1 セキュリティリリース(1)
0.4.111.1.1セキュリティリリース(1)
………
1.0.011.x.0GitLabマイナーリリース、Chart GAと一緒に。
2.0.011.x.xChartにいくつかの変更点を導入。
3.0.012.0.0GitLab 12リリース
  • (1):セキュリティリリースのために同じイメージバージョンにアップグレードする必要がある2つのChartバージョンがある場合、新しい方をアップデートします。そうしないと、リリースロジックの自動化が複雑になりすぎてしまいます。ユーザーは必要に応じて手動でイメージバージョンを指定するか、チャートをアップグレードすることで回避できます。

今後の予定

GitLab のバージョンをそのまま私たちのバージョンとして使うことも考えましたが、私たちはまだ GitLab のリリースと歩調を合わせているわけではありません。今のところ、私たちはチャート固有のバージョンスキームで進めるつもりです。チャートが十分に安定し、同じバージョンを共有することに抵抗がなくなり、チャートのアップデートがGitLab Coreのバージョンを上げる合理的な理由になるまで。

ブランチとタグ

このChartでは、他の主要なGitLabコンポーネントと同じブランチ戦略に従うことを提案します。

  • master ブランチ、
  • x-x-stable マイナーリリースごとに master から作成するブランチ。
  • x.x.x タグはこれらの安定ブランチから作成されます。

ブランチ名と他の GitLab コンポーネントの違いは、ブランチ名に GitLab のバージョンではなくチャートのバージョンを使うことです。

一般的に、変更はmasterにマージされ、リリース前に適切なブランチにcherry-pickされます。GitLabイメージの更新はブランチでのコミットとして行われ、masterでは行われません。

リリースアクションのタイムライン例

提案されたブランチ戦略を使ったリリースに関連するもの

ブランチタグアクション詳細
0-2-stable ブランチmasterから作成されたブランチ
  画像の更新GitLab11.0.0-rcX イメージを使用。
  ピックmaster からの追加変更をブランチにピック
  画像の更新GitLab11.0.0 イメージを使用。
 0.2.0タグチャート0.2.0 リリース
  ピックmaster からの修正をブランチにピック
  画像の更新GitLab11.0.1 イメージを使用。
 0.2.1タグチャート0.2.1 リリース
0-3-stable ブランチmasterから作成されたブランチ
  画像の更新GitLab11.1.0-rc1 イメージを使用。
0-2-stable 画像の更新GitLab11.0.2 イメージを使用。
 0.2.2タグチャート0.2.2 リリース
0-3-stable ピックmaster からの修正をブランチにピック
  画像の更新GitLab11.1.0 イメージを使用。
 0.3.0タグチャート0.3.0 リリース

チャートのリリース

新しいバージョンのチャートのリリースは、リリースツールリポジトリのHelmリリースタスクによって処理されます。

リリースは GitLab のリリースの一部として行われます。必要に応じて、ディストリビューションチームが追加のチャートリリースを開始することもあります。リリースツールは、チャートのパッケージ化と公開のためのパイプラインをトリガーします。charts.gitlab.io リポジトリのrelease_chart ジョブを参照してください。

さらに、リリースツールはチャートの管理を自動化します：

開発者向けビルド

開発者用Chartバージョンは、master へのマージごとにビルドされています。

devel チャンネルを使用することで、Helm チャートの現在の非プロダクション「開発」リリースを追跡することができます：

helm repo add gitlab-devel https://gitlab.com/api/v4/projects/3828396/packages/helm/devel

を使用し、helm の--devel オプションで特定のリリースを指定します：

helm install --devel --version 1.2.3-4567 gitlab-devel/gitlab

で、利用可能なdevel バージョンをリストアップします：

helm search repo gitlab-devel --devel

手動でチャートをリリース

手動でチャートをリリースする前に、master から必要なすべてのチャートの変更が、リリースするバージョンの安定版ブランチに反映されていることを確認してください。

たとえば、チャートのバージョン0.2.1 をリリースしたい場合、その変更は0-2-stable

リリースにタグを付けるChatOpsコマンドがあります。関連するリリースのSlackチャンネル（#f_release_12_4 など）で次のコマンドを実行します。

/chatops run helm tag <charts version> <GitLab version>

ChatOpsコマンドを使わずに、以下のように手動で行うこともできます：

  1. リリースツールリポジトリをチェックアウトしてセットアップします。

    git clone git@gitlab.com:gitlab-org/release-tools.git
bundle install

  2. そして適切なHelmリリースタスクを実行します：

    • GitLabアプリのバージョンを変更せずにリリースしたいときは、新しいChartのバージョンを指定してリリースタスクを呼び出します（0.2.1 など）。
      • bundle exec rake release:helm:tag[0.2.1]
    • チャートのバージョンとアプリのバージョンの両方を変更してリリースしたい場合（GitLab11.0.1 で0.2.1 のような場合）。
      • bundle exec rake release:helm:tag[0.2.1,11.0.1]

    TEST=true を環境に設定することで、プッシュを防ぐドライランモードでスクリプトを実行することができます。