Bạn xử lý database migration trong CI/CD như thế nào?

Question

Accepted Answer

**Database migration** (thay đổi schema) là một trong những phần khó nhất của CI/CD — khác với code ứng dụng vốn stateless, database giữ **trạng thái (state)** không thể thay thế hay rollback một cách đơn giản. Xử lý migration cẩn thận (tự động hoá, tương thích ngược, các pattern an toàn) là điều thiết yếu để triển khai đáng tin cậy.

## Vì sao database migration lại khó

```text
Code ứng dụng là stateless (thay thế, rollback thoải mái). DATABASE giữ STATE:
  → không thể chỉ "rollback" một migration đã xoá cột hay biến đổi dữ liệu
    (dữ liệu có thể đã mất) → rollback rủi ro/bất khả thi với thay đổi mang tính phá huỷ
  → trong lúc deploy, code CŨ và MỚI có thể chạy ĐỒNG THỜI (rolling deploy) —
    cả hai phải hoạt động được với schema database tại thời điểm đó
→ Thay đổi schema cần phối hợp cẩn thận với việc deploy code.
```

## Tự động hoá migration trong pipeline

```text
→ Migration được định nghĩa dưới dạng CODE (file migration có version; Flyway, Liquibase, ORM)
→ Chạy migration như một BƯỚC trong pipeline (áp dụng migration pending khi deploy)
→ Migration có version và được áp dụng theo thứ tự, idempotent
→ Test migration ở staging trước khi lên production
```

## Pattern migration an toàn (tương thích ngược)

```text
NGUYÊN TẮC CỐT LÕI: làm migration TƯƠNG THÍCH NGƯỢC để code cũ VÀ mới đều chạy được trong
quá trình chuyển đổi. Dùng pattern EXPAND-CONTRACT (parallel change):
  1. EXPAND → thêm schema mới (vd: thêm cột mới) — code cũ vẫn chạy
  2. MIGRATE → deploy code ghi vào cả hai / đọc cái mới; backfill dữ liệu
  3. CONTRACT → khi mọi code đã dùng schema mới, gỡ bỏ cái cũ (ở một deploy SAU)
→ KHÔNG BAO GIỜ drop/rename trong cùng deploy còn cần nó — tách ra nhiều deploy.
→ Điều này cho phép deploy zero-downtime và rollback an toàn.
```

## Tại sao điều này quan trọng

Hiểu cách xử lý database migration trong CI/CD quan trọng vì **migration là một trong những phần khó và rủi ro nhất của việc deploy tự động**, nên đây là kiến thức thực tiễn có giá trị cho việc giao hàng đáng tin cậy.

Thách thức cốt lõi là, khác với code ứng dụng stateless (có thể thay thế và rollback thoải mái), **database giữ trạng thái** — nên một migration xoá cột hay biến đổi dữ liệu **không thể chỉ rollback đơn giản** (dữ liệu có thể đã mất), khiến các thay đổi phá huỷ trở nên rủi ro hoặc bất khả nghịch, và trong lúc rolling deployment **code cũ và mới chạy đồng thời**, cả hai đều cần hoạt động với schema tại thời điểm đó.

Điều này khiến thay đổi schema cần phối hợp cẩn thận, khác với phần còn lại của CI/CD.

Hiểu cách **tự động hoá migration** (định nghĩa dưới dạng code có version qua các công cụ như Flyway, Liquibase hay ORM migration, chạy như một bước pipeline áp dụng theo thứ tự và idempotent, test ở staging trước) đưa migration vào pipeline tự động một cách an toàn.

Quan trọng nhất, hiểu **các pattern migration an toàn** — làm migration **tương thích ngược** để code cũ và mới đều chạy được trong quá trình chuyển đổi, dùng pattern **expand-contract (parallel change)** (expand: thêm schema mới không phá vỡ code cũ; migrate: chuyển đổi code và backfill dữ liệu; contract: gỡ schema cũ ở deploy sau) và **không bao giờ drop/rename trong cùng deploy còn cần nó** — là kỹ năng then chốt cho phép **deploy zero-downtime và rollback an toàn** bất chấp bản chất stateful của database.

Đây là kiến thức thực tế khó, quan trọng, phân biệt người có thể deploy thay đổi database an toàn với người gây sự cố hoặc mất dữ liệu.

Vì database migration là phần khó, rủi ro và không thể tránh khi deploy ứng dụng có database, và vì xử lý chúng cẩn thận (tự động hoá cộng các pattern tương thích ngược expand-contract) là thiết yếu cho việc deploy zero-downtime đáng tin cậy, nên hiểu database migration trong CI/CD là kiến thức giá trị, quan trọng về mặt thực tiễn — giải quyết một trong những khía cạnh khó nhất của continuous delivery và phản ánh sự trưởng thành cần thiết để deploy ứng dụng stateful an toàn.