artifact management ใน CI/CD คืออะไร?

Question

Accepted Answer

**Artifacts** คือผลลัพธ์ของกระบวนการ build (compiled binaries, packages, Docker images) ที่ถูกนำไป deploy **Artifact management** — การจัดเก็บ การทำ versioning และการ promote artifacts เหล่านี้ผ่าน registry/repository — สำคัญต่อการ deploy ที่น่าเชื่อถือและติดตามได้

## artifacts คืออะไร

```text
The BUILD produces ARTIFACTS — the deployable outputs:
  → Docker IMAGES, compiled binaries, JARs/WARs, npm packages, zip bundles, etc.
→ These are what actually get DEPLOYED (not the source code directly).
```

## artifact repositories/registries

```text
Artifacts are stored in REPOSITORIES/REGISTRIES (versioned, central storage):
  → Container registries: Docker Hub, AWS ECR, GitHub/GitLab Container Registry
  → Package repositories: npm registry, Maven, PyPI, Artifactory, Nexus
→ The pipeline BUILDS an artifact, PUSHES it to the registry, and DEPLOYS from there.
```

## หลักการสำคัญ: build ครั้งเดียว deploy ทุกที่

```text
Build the artifact ONCE, then promote the SAME artifact through environments:
  build → artifact v1.2.3 → deploy to STAGING → (tested) → deploy SAME v1.2.3 to PROD
  ✓ what you TESTED in staging is EXACTLY what you deploy to production (no rebuild)
  ✗ rebuilding per environment risks differences (different deps, build env) → bugs
→ Versioned, immutable artifacts ensure consistency and traceability.
```

## ประโยชน์และแนวปฏิบัติ

```text
✓ VERSIONING — each artifact tagged with a version → know exactly what's deployed
✓ TRACEABILITY — trace a deployed artifact back to its commit/build
✓ ROLLBACK — redeploy a previous artifact version easily
✓ IMMUTABILITY — artifacts don't change once built (consistent, reproducible)
✓ Retention/cleanup policies; scan artifacts for vulnerabilities
```

## ทำไมจึงสำคัญ

การเข้าใจ artifact management มีคุณค่า เพราะ **artifacts คือสิ่งที่ถูกนำไป deploy จริง** และการจัดการมันให้ดีสำคัญต่อการ deploy ที่น่าเชื่อถือ ติดตามได้ และสม่ำเสมอ ดังนั้นจึงเป็นความรู้ CI/CD ที่มีประโยชน์ **Artifacts** (ผลลัพธ์ที่ deploy ได้ของการ build — Docker images, binaries, packages) คือสิ่งที่ถูก deploy (ไม่ใช่ source code โดยตรง) และการจัดเก็บมันใน **registry/repository ที่มี versioning** (container registries, package repositories) คือวิธีที่ pipeline จัดการมัน: build artifact, push ไปที่ registry และ deploy จากที่นั่น

**หลักการสำคัญ — build ครั้งเดียว deploy ทุกที่** — สำคัญเป็นพิเศษ: การ build artifact **ครั้งเดียว** และ promote **artifact เดียวกันนั้น** ผ่าน environment ต่าง ๆ (staging แล้วจึง production) ทำให้มั่นใจว่า **สิ่งที่คุณ test คือสิ่งที่คุณ deploy พอดี** (ไม่มีการ rebuild แยกตาม environment ที่อาจทำให้เกิดความแตกต่างจาก dependency หรือ build environment ที่ต่างกัน ซึ่งก่อให้เกิด bug) — เป็นแนวปฏิบัติพื้นฐานสำหรับการ deploy ที่น่าเชื่อถือและสม่ำเสมอ ที่ป้องกันปัญหาประเภท "มันใช้ได้ใน staging" ที่เกิดจากการ rebuild

การเข้าใจ **ประโยชน์** — **versioning** (รู้ว่าอะไรถูก deploy พอดี) **traceability** (ติดตาม artifact ที่ deploy ย้อนกลับไปยัง commit และ build ซึ่งมีคุณค่าสำหรับการ debug และ audit) **rollback ง่าย** (re-deploy artifact เวอร์ชันก่อนหน้า) และ **immutability** (artifacts ไม่เปลี่ยนแปลงเมื่อ build แล้ว ทำให้ทำซ้ำได้) รวมถึงแนวปฏิบัติ เช่น การ scan หาช่องโหว่ — สะท้อนว่า artifact management ที่เหมาะสมสนับสนุนการดำเนินงานที่น่าเชื่อถืออย่างไร

เนื่องจาก artifacts คือหน่วยที่ถูก deploy จริง และการจัดการมันให้ดี (versioning หลักการ build-once-deploy-everywhere traceability immutability) สำคัญต่อการ deploy ที่สม่ำเสมอ ติดตามได้ และน่าเชื่อถือ และเนื่องจากการเข้าใจ artifacts, registries และโดยเฉพาะหลักการ build-once มีคุณค่าต่อการส่งมอบที่ดี การเข้าใจ artifact management จึงเป็นความรู้ CI/CD ที่มีคุณค่าและเกี่ยวข้องกับการปฏิบัติจริง — เป็นส่วนสำคัญของการส่งมอบที่น่าเชื่อถือ ซึ่งทำให้มั่นใจในความสม่ำเสมอระหว่างสิ่งที่ test และ deploy เปิดทางให้ traceability และ rollback และสะท้อนแนวปฏิบัติการ deploy ที่เติบโตเต็มที่