リリース

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

主なリリース

メジャーリリースは、チャートやGitLabリリースの変更点や重要なマイルストーンに対して行われます。 0からスタートし、GAリリースのチャートでは1になります。

私たちはそれをぶつけます：

  • 大幅な追加/変更（デフォルトでページを追加する、またはNginxを完全に削除するとします。）
  • GitLabやChartの変更を壊すこと（アップグレードするために既存のインストールを手動で操作する必要があります。）
  • GitLabイメージのメジャーアップデート（12.0.0のリリース）

マイナーリリース

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

私たちはそれをぶつけます：

  • GitLabのすべてのマイナーバージョンアップデート
  • リソースの使用量を増加させる可能性のあるChartのデフォルト値の変更（サブチャート/ポッドの追加、追加サービスまたはイングレスの追加）
  • その他の機能的な変更については、もっと知っていただく必要があると思います。

パッチリリース

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

私たちはそれをぶつけます：

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

リリースシナリオ例

チャート版 GitLab バージョン リリースシナリオ
0.2.0 11.0.0 GitLab 11リリースとChartベータ版
0.2.1 11.0.1 GitLabパッチリリース
0.2.2 11.0.1 チャート変更のお知らせ
0.2.3 11.0.2 GitLabパッチリリースとそれに伴うChartの変更
0.3.0 11.1.0 GitLabマイナーリリースと新しいChartの変更
0.4.0 11.1.0 マイナーバージョンアップとして含めることに意味があると思われるChartの変更。
0.2.4 11.0.3 セキュリティリリース
0.3.1 11.1.1 セキュリティリリース(1)
0.4.1 11.1.1 セキュリティリリース(1)
… … …
1.0.0 11.x.0 GitLab マイナーリリース、Chart GA とともに
2.0.0 11.x.x Chartにいくつかのブレークチェンジを導入。
3.0.0 12.0.0 GitLab 12 リリース
  • (1)：セキュリティ・リリースのために同じイメージ・バージョンにアップグレードする必要がある2つのチャート・バージョンがある場合、新しい方をアップデートします。 そうしないと、リリース・ロジックを自動化することが過度に複雑になります。 必要であれば、ユーザは手動でイメージ・バージョンを指定するか、チャートをアップグレードすることで回避できます。

将来の反復

GitLab のバージョンを私たち自身のバージョンとして使うことも考えましたが、私たちはまだ GitLab のリリースと歩調を合わせているわけではありません。今のところ、私たちはチャート固有のバージョンスキームで進めるつもりです。

ブランチとタグ

この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 イメージを使用しています。
    ピック マスターからの追加変更をブランチに取り込みました。
    画像更新 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 リリース

チャートの公開

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

デフォルトでは、新しいリリースイメージがCNGイメージリポジトリにタグ付けされると、CIからこのタスクが自動的に実行されます。

現在、Chart のリリースには、リリースツールレポのhelm-release-tools ブランチが使用されています。

チャートの手動リリース

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

例えば、Chartのバージョン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]
    • Chartのバージョンとアプリのバージョンの両方をリリースし、変更したい場合（例：0.2.1 with GitLab11.0.1)
      • bundle exec rake release:helm:tag[0.2.1,11.0.1]

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