LESSON 30分

ストーリー

田中VPoE
ビルド・テスト・デプロイの標準化が見えてきたな。次は、ビルドされたアーティファクトの管理を考えよう
あなた
アーティファクトというと、Dockerイメージやパッケージのことですか?
田中VPoE
そうだ。組織に20以上のチームがあると、毎日数百のアーティファクトが生成される。これを体系的に管理しないと、「このイメージはどのコミットからビルドされた?」「このバージョンにはどの変更が含まれている?」がわからなくなる
あなた
確かに、トレーサビリティは重要ですね
田中VPoE
トレーサビリティだけじゃない。セキュリティ、コスト、コンプライアンス — すべてに影響する組織の生命線だ

アーティファクトの種類と管理戦略

組織で管理すべきアーティファクト

種類具体例保管先保持期間
コンテナイメージDocker イメージECR / GCR / GHCR本番: 90日、開発: 30日
パッケージnpm, PyPI, MavenArtifactory / 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 }}"

アーティファクトのメタデータとトレーサビリティ

必須メタデータ

すべてのアーティファクトに以下のメタデータを付与します。

メタデータ説明
versionSemVer バージョン2.3.1
commit-shaビルド元のコミットハッシュabc1234
build-timeビルド日時(UTC)2026-02-21T10:30:00Z
pipeline-urlビルドパイプラインのURLhttps://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 }}

ライフサイクル管理

保持ポリシー

アーティファクトの保持ポリシーを組織で統一し、コスト最適化を図ります。

環境保持期間クリーンアップ
開発/feature7日自動削除
ステージング30日自動削除
本番リリース90日アーカイブ後削除
重要リリース永続手動管理

まとめ

ポイント内容
アーティファクト管理統一レジストリ、メタデータ標準、保持ポリシー
バージョニングSemVer + Conventional Commits で自動化
トレーサビリティコミット→ビルド→デプロイの完全な追跡
セキュリティ署名と検証でサプライチェーンの信頼性確保

チェックリスト

  • アーティファクトの種類と管理戦略を理解した
  • 自動バージョニングの仕組みを理解した
  • アーティファクトの署名と検証の必要性を理解した

次のステップへ

次は「環境管理とプロモーション戦略」です。ビルドされたアーティファクトを、どの環境にどのように昇格させていくかを学びましょう。


推定読了時間: 30分