Zenn
🦝

リリース前テストがある場合のなるべく綺麗で手間がかからないバージョン番号の付け方

2024/12/19に公開
Semantic Versioning
tech

はじめに

リリース前にテストを実施するリリースフローでは、テストで問題が見つかる、ということが必ず発生します。その場合は見つかった問題を修正して再テストを実施するのですが、このときの「問題を修正したバージョン」にどのようなバージョン番号を付けるのが良いのか、という点について、私の考えをまとめた記事です。

前提とするリリースフロー

以下のように、リリース環境へのリリースをする前に、テスト環境でリリース候補のバージョンのテストを実施するようなリリースフローを前提としています。

  1. リリース候補のバージョンを確定する。
  2. リリース候補のバージョンをテスト環境にリリースし、テストを実施する。
  3. テストで問題が見つかった場合は、問題を修正し再テストを実施する。
  4. テストで問題が見つからなかった場合は、リリース環境にリリースする。

基本方針

まず基本的な方針として、 Semantic Versioning 2.0.0 の仕様に沿ってバージョン番号を付けます。世の中には色々なバージョン番号の付け方がありますが、何か特別な理由がないのであれば、出来る限り一般的なやり方に合わせた方が無難です。

https://semver.org/

バージョン番号の付け方

パッチバージョンを上げる

最もシンプルなのが、パッチバージョンを上げるやり方です。具体的には以下のようなバージョン番号を付けることになります。

  1. リリース候補のバージョンを確定し、そのバージョンを 1.0.0 とする。
  2. 1.0.0 をテスト環境にリリースし、テストを実施する。
  3. テストで問題が見つかり、問題を修正したバージョンを 1.0.1 とする。
  4. 1.0.1 をテスト環境にリリースし、再テストを実施する。
  5. 再びテストで問題が見つかり、問題を修正したバージョンを 1.0.2 とする。
  6. 1.0.2 をテスト環境にリリースし、再々テストを実施する。
  7. テストで問題が見つからなかったため、リリース環境に 1.0.2 をリリースする。

特にこのやり方で問題があるわけではないのですが、初期リリースバージョンが 1.0.2 という中途半端なものになるのが綺麗ではありません。また、顧客にリリースしたバージョン番号を伝える必要がある場合などに「何かあった感」がありありなのも気恥ずかしいです。

プレリリースバージョンを使う

初期リリースバージョンを綺麗に 1.0.0 とできるのが、プレリリースバージョンを使うやり方です。具体的には以下のようなバージョン番号を付けることになります。

  1. リリース候補のバージョンを確定し、そのバージョンを 1.0.0-rc.0 とする。
  2. 1.0.0-rc.0 をテスト環境にリリースし、テストを実施する。
  3. テストで問題が見つかり、問題を修正したバージョンを 1.0.0-rc.1 とする。
  4. 1.0.0-rc.1 をテスト環境にリリースし、再テストを実施する。
  5. 再びテストで問題が見つかり、問題を修正したバージョンを 1.0.0-rc.2 とする。
  6. 1.0.0-rc.2 をテスト環境にリリースし、再々テストを実施する。
  7. テストで問題が見つからなかったため、 1.0.0-rc.2 のバージョンを 1.0.0 とする。
  8. リリース環境に 1.0.0 をリリースする。

Semantic Versioningの仕様に沿った最も一般的なやり方ではあるのですが、ここで気になるのが、テストが完了した後のテスト環境のバージョンです。テストが完了した直後のテスト環境のバージョンは当然 1.0.0-rc.2 で、 1.0.0-rc.2 と 1.0.0 はまったく同じバージョンを指したバージョン番号ではあるのですが、テスト環境にリリースされているバージョンが 1.0.0-rc.2 、リリース環境にリリースされているバージョンが 1.0.0 となっていると、この２つのバージョンに何かしらの差があるように見えてしまいます。そのような状況では、例えばリリース環境へのリリースから数日後にまったく別の新しい問題が見つかった場合などに、 1.0.0-rc.2 と 1.0.0 の２つのバージョンで、まったく意味のない再現テストを２回実施してしまう、ということも十分に考えられます。 1.0.0 をテスト環境とリリース環境に同時にリリースしてしまえばそれまでの話ではありますが、テスト環境のバージョン番号を変えるだけのリリース作業など、やらずにすませられるものならやらずにすませたいものです。

ビルドメタデータを使う

初期リリースバージョンがなるべく綺麗で、リリース環境と同じバージョンをテスト環境にもリリースする手間を省くために私が考えたのが、ビルドメタデータを使うやり方です。具体的には以下のようなバージョン番号を付けることになります。

  1. リリース候補のバージョンを確定し、そのバージョンを 1.0.0+rev.0 とする。
  2. 1.0.0+rev.0 をテスト環境にリリースし、テストを実施する。
  3. テストで問題が見つかり、問題を修正したバージョンを 1.0.0+rev.1 とする。
  4. 1.0.0+rev.1 をテスト環境にリリースし、再テストを実施する。
  5. 再びテストで問題が見つかり、問題を修正したバージョンを 1.0.0+rev.2 とする。
  6. 1.0.0+rev.2 をテスト環境にリリースし、再々テストを実施する。
  7. テストで問題が見つからなかったため、リリース環境に 1.0.0+rev.2 をリリースする。

Semantic Versioningの仕様上、ビルドメタデータはあってもなくてもまったく意味がないものですので、このビルドメタデータにテストで見つかった問題の修正に関する情報、言い換えればプロジェクトメンバーにだけ意味のあるものとして伝われば良い情報を格納し、初期リリースバージョンのある程度の綺麗さの確保と、テスト環境へのリリース作業の手間を省くことを実現しています。

最後に

繰り返しになりますが、Semantic Versioningの仕様に沿った最も一般的なバージョン番号の付け方は、プレリリースバージョンを使うやり方です。APIを一般公開するようなプロジェクトであれば、プレリリースバージョンを使うやり方でバージョン番号を付けるのがベストだと思いますが、そうでないプロジェクトなのであれば、Semantic Versioningの仕様の範囲内で、プロジェクトに適したリリースフローが実現できるようにバージョン番号を付ければ良いと考えています。

GitHubで編集を提案

Discussion