build artifact repository とは? ビルドの成果物が置かれる場所
build artifact repository とは、ビルドの成果物、すなわち container image、パッケージ、JAR を、確実にデプロイし再利用できるようにするための、バージョン管理されたストアです。
CI がビルドを生成すると、その artifact は、deploy、downstream ジョブ、rollback がまったく同じバイト列を取得できるよう、アドレス指定可能などこかに置かれる必要があります。build artifact repository がそのストアです。build-once, deploy-many の原則を機能させるものであり、テストしたものがそのまま出荷されることを保証するものです。
何を保存するか
コンパイル・パッケージ化された成果物です。container image、言語パッケージ、バイナリ、library。それぞれにバージョンまたはコンテンツハッシュのタグが付きます。例として container registry、npm や Maven の registry、汎用の artifact ストアがあります。
なぜ CI/CD の中心なのか
- build once, deploy many: すべての環境が同じ artifact を取得する。
- 再現性: バージョンが正確なバイト列に対応する。
- rollback: 以前の artifact を即座に再デプロイする。
- 共有: downstream ジョブやチームが公開されたビルドを利用する。
build once, deploy everywhere
環境ごとに rebuild するのではなく、不変の artifact を1つビルドして公開し、そのまったく同じ artifact を staging から本番へ昇格させます。repository は build と deploy の間でそれを保持するものであり、「rebuild したら差異が出た」という種類のバグをなくします。
不変性と同一性
artifact は不変であるべきです。あるバージョンは常に同じバイト列を指します。image digest のような content-addressed な識別子は、その保証を暗号的なものにするため、デプロイされた artifact がテスト済みのものと一致することを証明できます。
retention と provenance
repository は retention(古い artifact をどれだけ保持するか)も扱い、さらに provenance(artifact がどうビルドされたかの署名付き記録)も扱うようになっています。どちらも、パイプラインがデプロイ前に実行する supply-chain security のチェックに供給されます。
runner での artifact の取得
すべての deploy と多くの build ステップが artifact repository から取得するため、registry のレイテンシがパイプラインの速度に影響します。キャッシュされたレイヤーと registry の一時的エラーへの retry を備えたマネージド runner(Latchkey が提供するもの)は、それらの取得を高速で信頼できるものに保ちます。
重要なポイント
- build artifact repository は、ビルド成果物のためのバージョン管理されたストアである。
- build-once-deploy-many、再現可能なリリース、即時の rollback を可能にする。
- 不変で content-addressed な artifact は、デプロイされたビルドがテスト済みのものと一致することを証明する。