すべてのアーティファクトに名前と番号が必要な理由
チームは毎日コードをビルドする。金曜日になると、リポジトリには7つの異なるアーティファクトが並ぶ。どれがテスト済みで、どれにホットフィックスが含まれ、どれを本番に出すべきか、誰も覚えていない。「どのビルドをデプロイすればいい？」という質問に、返ってくるのは肩をすくめるだけの反応だ。
これこそ、明確な命名がないアーティファクトは、もはやアーティファクトではなく、単なるファイルに過ぎないと気づく瞬間である。適切な命名と番号付けの仕組みがなければ、パイプラインは確実性ではなくノイズを生み出す。
ラベルのないアーティファクトの問題
アーティファクトに明確な識別子がないと、すべてのデプロイが推測ゲームになる。チームはタイムスタンプやフォルダ名、あるいは記憶に頼り始める。「火曜日の午後のビルドに修正が入っていたはず」——そういう考え方は危険だ。間違ったバージョンをデプロイしたり、テストもされていないものにロールバックしたり、最悪の場合、どれが最新か誰にもわからず壊れたアーティファクトを本番に流してしまう。
核心は単純だ：アーティファクトを一意に識別できなければ、確実にデプロイすることはできない。そして確実にデプロイできなければ、自信を持ってリリースすることもできない。
アーティファクトを識別可能にするもの
すべてのアーティファクトには、名前と番号の2つが必要だ。名前はアーティファクトが何かを示し、番号はその何番目のバージョンかを示す。この2つを組み合わせることで、チーム全員が曖昧さなく参照できる一意の識別子が生まれる。
名前は通常、アプリケーション名やコンポーネント名である。番号はバージョンだ。これらを組み合わせると、payment-service-2.1.3 のような文字列になる。この文字列は、ただ一つのアーティファクトを指し示す。先週のものではない。似た名前のものでもない。まさにその一つだけだ。
バージョニングは飾りではない
バージョニングは、アーティファクト識別子の番号部分に意味を与える仕組みである。単なるカウンターではない。優れたバージョニングスキームは、アーティファクト自体について何かを教えてくれる。変更の性質、リスクレベル、以前のバージョンとの関係を伝える。
最も広く使われているのはセマンティックバージョニングだ。ドットで区切られた3つの数字、MAJOR.MINOR.PATCH で構成される。各数字には明確な意味がある。
- MAJOR は、後方互換性を壊す変更を行ったときに増える。既存のユーザーがコードやワークフローを変更する必要がある場合、それはメジャーバージョンアップである。
- MINOR は、従来の方法でも動作する新機能を追加したときに増える。ユーザーは何も壊さずにアップグレードできる。
- PATCH は、新機能を導入せず、既存の機能も壊さないバグ修正に対して増える。
バージョン 2.1.3 を見れば、そのアプリケーションが2回のメジャーな互換性破壊、1回の機能追加、3回のバグ修正を経ていることがわかる。小さな文字列にこれだけの情報が詰まっている。
イミュータビリティはバージョニングから始まる
バージョン番号は単なるラベルではない。契約である。一度アーティファクトがビルドされ、バージョンがタグ付けされたら、そのバージョンは決して変わってはならない。同じコードを再ビルドすれば、同じアーティファクトが得られるはずだ。何かが変わったなら、バージョンも変わらなければならない。
これこそがアーティファクトをイミュータブル（不変）にする所以である。バージョン 2.1.3 は常に同じバイナリ、同じコンテナイメージ、同じパッケージを指す。今日ダウンロードしても、来週でも、6ヶ月後でも同じだ。アーティファクトは同一である。この確実性こそが、ステージングでテストしたものを、本番にまったく同じものをデプロイできる基盤となる。
バージョニングとリリースは別物
よくある間違いは、バージョニングとリリースを同じ概念として扱うことだ。これらは異なる。バージョニングはアーティファクトにラベルを付けること。リリースは、そのアーティファクトをユーザーが利用できるようにするかどうかを決定することである。
バージョン 2.2.0-beta をビルドし、テスト用にステージングにデプロイすることもできる。そのバージョンはアーティファクトとして存在するが、リリースではない。テスト後、2.2.0 として本番リリースする判断をするかもしれない。あるいは問題が見つかり、代わりに 2.2.1 をビルドするかもしれない。
この分離が柔軟性を生む。アーティファクトのビルドとバージョン付与は頻繁に行い、リリースは確信が持てたときだけ行えばよい。バージョン番号はアーティファクトの同一性を追跡し、リリース判断はその準備状態を追跡する。
パイプラインへの実践的な影響
明確な命名とバージョニングの仕組みが整えば、いくつかのことが容易になる。
トレーサビリティが自動化される。 本番でバグが報告されたら、その環境で動作しているバージョンを確認する。そのバージョンにどのような変更が含まれているかを調べる。以前の安定バージョンと比較する。これらすべてが可能なのは、すべてのアーティファクトに一意の識別子があり、それがソースコードとビルドプロセスにリンクしているからだ。
ロールバックが正確になる。 以前どのバージョンが動いていたかを推測する必要はない。先週どのバージョンが動いていたか正確にわかり、その同じアーティファクトを再デプロイできる。アーティファクトはイミュータブルなので、まったく同じバイナリをデプロイすることになり、再ビルドによって動作が変わる心配はない。
コミュニケーションが明確になる。 「最新のビルドをデプロイして」ではなく、「payment-service 2.1.3 を本番にデプロイして」と言えば、全員がその意味を正確に理解する。DBAはどのデータベースマイグレーションが来るか、QAチームはどのテストが実行されたか、運用チームは何を監視すべきかがわかる。
アーティファクト命名のためのシンプルなチェックリスト
初めてアーティファクトの命名ルールを設定するなら、以下のチェックリストを参考にするとよい。
- すべてのアーティファクトに、アプリケーション名またはコンポーネント名と一致する名前が付いている。
- すべてのアーティファクトに、一貫したスキームに従ったバージョン番号が付いている。
- バージョン番号はビルド時に割り当てられ、その後変更されない。
- アーティファクトリポジトリは、タイムスタンプやフォルダではなく、名前とバージョンでアーティファクトを保存する。
- チームはバージョニング（ラベル付け）とリリース（利用可能にすること）の違いを理解している。
- バージョニングスキームが変更の性質（メジャー、マイナー、パッチ）を伝えている。
まとめ
アーティファクトの命名とバージョニングは、官僚的な作業ではない。信頼性の高いデプロイの基盤である。これがなければ、パイプラインは不確実性を生み出す。適切に実装すれば、すべてのアーティファクトは明確なアイデンティティを持ち、すべてのデプロイには明確なターゲットがあり、すべてのロールバックには明確な目的地がある。アーティファクトに名前を付け、一貫して番号を振り、イミュータブルにせよ。そうすれば、自信を持ってデプロイできる。