ストーリー
アーティファクトの種類と管理戦略
組織で管理すべきアーティファクト
| 種類 | 具体例 | 保管先 | 保持期間 |
|---|---|---|---|
| コンテナイメージ | Docker イメージ | ECR / GCR / GHCR | 本番: 90日、開発: 30日 |
| パッケージ | npm, PyPI, Maven | Artifactory / GitHub Packages | 公開: 永続、内部: 90日 |
| バイナリ | 実行可能ファイル | S3 / GCS | 本番: 90日 |
| Helm チャート | Kubernetes マニフェスト | OCI Registry / ChartMuseum | 本番: 永続 |
| Terraform モジュール | IaC モジュール | Terraform Registry | 永続 |
統一されたレジストリ戦略
組織のアーティファクト管理アーキテクチャ:
┌─────────────────┐
│ 統一レジストリ │
│ (GitHub Packages)│
└───────┬─────────┘
┌──────────┼──────────┐
↓ ↓ ↓
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Container │ │ npm/PyPI │ │ Helm │
│ Images │ │ Packages │ │ Charts │
└──────────┘ └──────────┘ └──────────┘
バージョニング戦略
Semantic Versioning の組織標準
組織全体でSemantic Versioning(SemVer)を採用します。
MAJOR.MINOR.PATCH
- MAJOR: 後方互換性のない変更
- MINOR: 後方互換性のある機能追加
- PATCH: 後方互換性のあるバグ修正
例: 2.3.1 → 2.4.0(新機能追加)
2.4.0 → 3.0.0(破壊的変更)
自動バージョニング
コミットメッセージから自動的にバージョンを決定する仕組みを導入します。
| Conventional Commits プレフィックス | バージョン影響 |
|---|---|
fix: | PATCH |
feat: | MINOR |
feat!: / BREAKING CHANGE: | MAJOR |
chore:, docs:, style: | バージョン変更なし |
# GitHub Actions: 自動バージョニング
- name: Determine Version
id: version
uses: org/auto-version@v1
with:
strategy: "conventional-commits"
- name: Tag and Push
run: |
git tag "v${{ steps.version.outputs.version }}"
git push origin "v${{ steps.version.outputs.version }}"
アーティファクトのメタデータとトレーサビリティ
必須メタデータ
すべてのアーティファクトに以下のメタデータを付与します。
| メタデータ | 説明 | 例 |
|---|---|---|
version | SemVer バージョン | 2.3.1 |
commit-sha | ビルド元のコミットハッシュ | abc1234 |
build-time | ビルド日時(UTC) | 2026-02-21T10:30:00Z |
pipeline-url | ビルドパイプラインのURL | https://github.com/org/repo/actions/runs/123 |
branch | ビルド元のブランチ | main |
コンテナイメージのラベリング
# OCI Image Spec準拠のラベル
LABEL org.opencontainers.image.version="${VERSION}"
LABEL org.opencontainers.image.revision="${COMMIT_SHA}"
LABEL org.opencontainers.image.created="${BUILD_TIME}"
LABEL org.opencontainers.image.source="${REPO_URL}"
アーティファクトの署名と検証
サプライチェーンの信頼性確保
ビルドされたアーティファクトが改ざんされていないことを保証するために、署名と検証の仕組みを導入します。
| ツール | 用途 | 対象 |
|---|---|---|
| Cosign | コンテナイメージ署名 | Docker イメージ |
| Sigstore | 署名の透明性ログ | 全アーティファクト |
| SLSA | ビルドの来歴証明 | 全アーティファクト |
# コンテナイメージの署名
- name: Sign Image
uses: sigstore/cosign-installer@v3
- name: Sign
run: |
cosign sign --yes \
${{ env.REGISTRY }}/${{ env.IMAGE }}:${{ env.VERSION }}
ライフサイクル管理
保持ポリシー
アーティファクトの保持ポリシーを組織で統一し、コスト最適化を図ります。
| 環境 | 保持期間 | クリーンアップ |
|---|---|---|
| 開発/feature | 7日 | 自動削除 |
| ステージング | 30日 | 自動削除 |
| 本番リリース | 90日 | アーカイブ後削除 |
| 重要リリース | 永続 | 手動管理 |
まとめ
| ポイント | 内容 |
|---|---|
| アーティファクト管理 | 統一レジストリ、メタデータ標準、保持ポリシー |
| バージョニング | SemVer + Conventional Commits で自動化 |
| トレーサビリティ | コミット→ビルド→デプロイの完全な追跡 |
| セキュリティ | 署名と検証でサプライチェーンの信頼性確保 |
チェックリスト
- アーティファクトの種類と管理戦略を理解した
- 自動バージョニングの仕組みを理解した
- アーティファクトの署名と検証の必要性を理解した
次のステップへ
次は「環境管理とプロモーション戦略」です。ビルドされたアーティファクトを、どの環境にどのように昇格させていくかを学びましょう。
推定読了時間: 30分