Day 11: Database-as-Code with Flyway / Liquibase Migration Mechanics (การบริหารจัดการ Stored Units ในรูปแบบ Database-as-Code, กลไก Versioned vs. Repeatable Migrations, การตรวจจับ Schema Drift, และการรวมระบบเข้ากับ CI/CD Pipeline)

Phase 3 เริ่มที่คำถามว่าโค้ดในฐานข้อมูลจะอยู่กับทีมได้อย่างไร — เก็บใน Git รีวิวได้ และ deploy ผ่าน pipeline ไม่ใช่ให้คนแอบเข้าไปแก้บน production ด้วยมือ

โดยรวมวันนี้คือการจัดการสคริปต์ฐานข้อมูลด้วย Flyway แยกโครงสร้างตารางกับ stored code ออกจากกัน แล้วนำเข้าสู่ CI/CD เพื่อขจัดปัญหาคนแอบไปแก้ฐานข้อมูลด้วยมือ (schema drift)

ช่วยให้ทีมโปรแกรมเมอร์หลายคนทำงานบนฐานข้อมูลเดียวกันได้อย่างเป็นระบบ โดยไม่ต้องกลัวว่าโค้ดจะทับกันหรือหายไป

หลังจากที่เราได้สร้าง Stored Units ประสิทธิภาพสูงทั้ง 4 เสาหลัก (UDFs, Procedures, Triggers, Materialized Views) สำเร็จแล้ว คำถามคลาสสิกที่สถาปนิกและผู้บริหารมักจะถามเสมอคือ "เราจะดูแลโค้ดพวกนี้อย่างไรเมื่อมีนักพัฒนา 20 คน? จะควบคุมไม่ให้คนแอบเข้าไปแก้ฟังก์ชันบน Production ได้อย่างไร? และจะกู้คืนระบบกลับสู่ State เดิมได้เร็วแค่ไหนหาก Deploy พัง?"

⚖️ การเปรียบเทียบเชิงสถาปัตยกรรม: Versioned Migration vs. Repeatable Migration ใน Flyway

การทำ Database-as-Code ต้องเริ่มตั้งแต่การเข้าใจโครงสร้างไดเรกทอรีของสคริปต์, การตั้งชื่อไฟล์ที่ถูกต้องตามมาตรฐาน Flyway, และการเขียนสคริปต์ Stored Units ใน Repeatable Migration ให้มีคุณสมบัติ Idempotent (รันซ้ำกี่ครั้งก็ได้ผลลัพธ์ถูกต้องเสมอ):

db/migration/
├── V1__create_core_tables.sql       <-- [1] Versioned: รันครั้งแรกครั้งเดียว ห้ามแก้ไฟล์นี้ตลอดกาล
├── V2__add_orders_indexes.sql       <-- [2] Versioned: รันต่อจาก V1 ตามลำดับหมายเลขเวอร์ชัน
├── R__01_udf_calculations.sql       <-- [3] Repeatable: รันใหม่ทุกครั้งที่มีการแก้โค้ด UDF ใน Git
├── R__02_stored_procedures.sql     <-- [4] Repeatable: รันใหม่ทุกครั้งที่มีการแก้ Procedure ใน Git
└── R__03_audit_triggers.sql        <-- [5] Repeatable: รันใหม่ทุกครั้งที่มีการแก้ Trigger ใน Git

🏋️‍♂️ แบบฝึกหัดไต่ระดับการเขียนจริง (จากระดับเริ่มต้น ➔ Enterprise CI/CD Migration Pattern)

-- db/migration/V1__init_schema.sql
-- 🎯 กฎเหล็ก: Versioned Migration ต้องขึ้นต้นด้วย V__ และรันเพียงครั้งเดียวตามลำดับถาวร

-- [1] สร้างตารางบัญชีเงินฝาก
CREATE TABLE accounts (
    account_id   BIGSERIAL PRIMARY KEY,
    account_no   VARCHAR(20) UNIQUE NOT NULL,
    balance      NUMERIC(15,2) NOT NULL DEFAULT 0.00,
    status       VARCHAR(10) NOT NULL DEFAULT 'ACTIVE',
    created_at   TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP
);

-- [2] สร้างตารางบันทึกประวัติธุรกรรม
CREATE TABLE transaction_logs (
    log_id       BIGSERIAL PRIMARY KEY,
    account_id   BIGINT REFERENCES accounts(account_id),
    amount       NUMERIC(15,2) NOT NULL,
    type         VARCHAR(20) NOT NULL,
    created_at   TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP
);

-- db/migration/R__01_stored_units.sql
-- 🎯 กฎเหล็ก: Repeatable Migration ต้องขึ้นต้นด้วย R__ และทุกคำสั่งต้องเป็น Idempotent (รันซ้ำได้ไม่พัง)

-- [1] Stored Function แบบ Idempotent (ใช้ CREATE OR REPLACE)
CREATE OR REPLACE FUNCTION fn_get_account_balance(p_account_id BIGINT)
RETURNS NUMERIC
LANGUAGE sql
STABLE
AS $$
    SELECT balance FROM accounts WHERE account_id = p_account_id;
$$;

-- [2] Stored Procedure แบบ Idempotent พร้อม Explicit Transaction Control
CREATE OR REPLACE PROCEDURE pr_deposit_funds(
    p_account_id BIGINT,
    p_amount     NUMERIC
)
LANGUAGE plpgsql
AS $$
BEGIN
    UPDATE accounts SET balance = balance + p_amount WHERE account_id = p_account_id;
    INSERT INTO transaction_logs (account_id, amount, type) VALUES (p_account_id, p_amount, 'DEPOSIT');
    COMMIT;
END $$;

🔴 Level 3: Refactoring CI/CD Database Deployment Pipeline (เปรียบเทียบ Manual Ad-hoc vs Repeatable Pattern)

เปรียบเทียบโค้ดเดิมที่สร้างไฟล์ Versioned ใหม่ไปเรื่อยๆ จนซอร์สโค้ดกระจัดกระจาย กับโค้ดใหม่ที่จัดการผ่าน Repeatable Migration รวมศูนย์:

-- ❌ หายนะของการแก้ Stored Procedure ด้วย Versioned Migration:
-- V3__update_proc_v1.sql
-- V4__update_proc_v2.sql
-- V5__fix_bug_proc.sql
-- V6__add_param_proc.sql

-- ผลลัพธ์: มีไฟล์สคริปต์สะสมเป็นร้อยๆ ไฟล์ใน Git!
-- นักพัฒนาคนใหม่เข้ามา ไม่รู้ว่าไฟล์ไหนคือ Logic ล่าสุดที่รันอยู่บน Production
-- และประวัติ Git History ของแต่ละฟังก์ชันกระจัดกระจายข้ามหลายไฟล์จน Review ไม่ได้!

-- db/migration/R__02_core_financial_procedures.sql
-- 🎯 ใช้ Repeatable Migration รวม Stored Units ที่เกี่ยวข้องไว้ในไฟล์เดียว
-- เมื่อแก้ Bug ให้แก้ในไฟล์นี้ตรงๆ Flyway จะคำนวณ Checksum ใหม่และ Deploy ให้อัตโนมัติ!

-- [Statement 1] จัดการกรณีที่มีการเปลี่ยน Parameter Signature ด้วย DROP IF EXISTS
DROP PROCEDURE IF EXISTS pr_transfer_funds_enterprise(BIGINT, BIGINT, NUMERIC);

-- [Statement 2] ประกาศ Stored Procedure ฉบับล่าสุด (Idempotent 100%)
CREATE OR REPLACE PROCEDURE pr_transfer_funds_enterprise(
    p_src_acc   BIGINT,
    p_dst_acc   BIGINT,
    p_amount    NUMERIC
)
LANGUAGE plpgsql
AS $$
DECLARE
    v_src_bal NUMERIC;
BEGIN
    -- [บรรทัดที่ 1-3] ตรวจสอบยอดเงินต้นทางพร้อมล็อกแถว
    SELECT balance INTO v_src_bal FROM accounts WHERE account_id = p_src_acc FOR UPDATE;

    IF v_src_bal < p_amount THEN
        RAISE EXCEPTION 'ยอดเงินในบัญชีต้นทางไม่เพียงพอ (คงเหลือ: %, ต้องการ: %)', v_src_bal, p_amount;
    END IF;

    -- [บรรทัดที่ 4-6] ทำการหักเงินและเพิ่มเงินเชิงเซต
    UPDATE accounts SET balance = balance - p_amount WHERE account_id = p_src_acc;
    UPDATE accounts SET balance = balance + p_amount WHERE account_id = p_dst_acc;

    -- [บรรทัดที่ 7-8] บันทึก Transaction Logs
    INSERT INTO transaction_logs(account_id, amount, type) VALUES (p_src_acc, -p_amount, 'TRANSFER_OUT');
    INSERT INTO transaction_logs(account_id, amount, type) VALUES (p_dst_acc, p_amount, 'TRANSFER_IN');

    -- 🎯 [บรรทัดที่ 9] สั่ง COMMIT ปิด Transaction ภายใน Procedure
    COMMIT;
END $$;

แบบทดสอบวัดระดับความเข้าใจ Day 11: Database-as-Code with Flyway / Liquibase Migration Mechanics (Versioned vs Repeatable, Schema Drift, Checksum Validation, Idempotency) และข้อสอบสะสมทบทวนครบทั้ง Days 1–10 คลิกเลือกคำตอบ ก, ข, ค, หรือ ง เพื่อดูผลลัพธ์และคำอธิบายอย่างละเอียดทันที

🎉 ยินดีด้วยครับ! คุณได้เริ่มต้นก้าวแรกของ Phase 3 (DevOps, Maintainability & Architectural Boundaries) เรียบร้อยแล้ว

บทเรียน Day 11: Database-as-Code with Flyway / Liquibase Migration Mechanics ได้ยกระดับการจัดการซอร์สโค้ดฐานข้อมูลเข้าสู่ยุค Database-as-Code โดยการแบ่งสคริปต์ออกเป็น Versioned Migrations (V__*.sql) สำหรับโครงสร้าง DDL และ Repeatable Migrations (R__*.sql) สำหรับ Stored Units (UDFs, Procedures, Triggers) ซึ่งช่วยขจัดปัญหา Schema Drift และทำให้การ Deploy สคริปต์ฐานข้อมูลเข้าสู่ระบบ CI/CD เป็นเรื่องอัตโนมัติ 100%