# Production Deployment Checklist

Checklist นี้ใช้สำหรับอัปเกรดระบบ CCW จากเครื่อง Dev ขึ้นเครื่อง Production ที่อยู่บน Cloud server

ใช้คู่กับ:

- [Release Checklist](./release-checklist.md)
- [Smoke / UAT Runbook](./smoke-uat-runbook.md)
- [CI / Pipeline Gate](./ci-pipeline-gate.md)
- [Deployment Copy Excludes](./deployment-copy-excludes.md)

## Goal

ยืนยันว่าไฟล์ที่อัปขึ้น Production จะไม่ทำให้ระบบล้มจากความต่างของ environment ระหว่าง Dev กับ Cloud server

## สิ่งที่เปลี่ยนแล้วและมีผลกับ Production

- ระบบอ่านค่า database จาก `.env` หรือ environment variables แล้ว
- ระบบมี one-time runtime schema bootstrap หลัง deploy
- session และ login throttle ใช้ไฟล์ใต้ `storage/`
- direct access ไป `storage/` ต้องถูก block ที่ web server
- flow สำคัญหลายจุดเปลี่ยนเป็น `POST + CSRF + duplicate-submit guard`

## Pre-Deploy

- [ ] สำรองฐานข้อมูล Production ก่อนทุกครั้ง
- [ ] สำรองไฟล์ config สำคัญของ Production เช่น `.env`, web server config, cron/job config
- [ ] ยืนยันว่า artifact หรือไฟล์ที่เตรียม deploy มาจาก source ล่าสุดที่ผ่าน gate แล้ว
- [ ] รัน `scripts\pre_release_gate.ps1` ให้ผ่านบนเครื่อง Dev หรือ runner ที่ทีมใช้

## Production Environment Readiness

### Database Config

- [ ] บน Production ต้องมี `.env` หรือ environment variables สำหรับ:
  - `CCW_DB_HOST`
  - `CCW_DB_PORTS` หรือ `CCW_DB_PORT`
  - `CCW_DB_NAME`
  - `CCW_DB_USER`
  - `CCW_DB_PASS`
- [ ] อย่า copy `.env` จากเครื่อง Dev ขึ้นไปตรง ๆ
- [ ] ตรวจว่า PHP บน Production เปิด `mysqli` แล้ว

### File / Directory Permissions

- [ ] web server/PHP user ต้องเขียนได้ที่:
  - `storage/sessions`
  - `storage/settings`
  - `storage/uploads/payment_slips`
- [ ] ถ้าใช้ data maintenance/backup บน Production ให้เขียนได้ที่:
  - `storage/database_backups`
  - `storage/maintenance_exports`
- [ ] ถ้าเขียนไม่ได้ จะเสี่ยงกับ:
  - session/login มีปัญหา
  - login throttle ไม่ทำงาน
  - bootstrap marker ไม่ถูกบันทึก
  - payment slip upload ใช้งานไม่ได้

### Web Server Security

- [ ] ถ้าใช้ Apache ให้มี [storage/.htaccess](/C:/xampp82/htdocs/CCW/storage/.htaccess:1)
- [ ] ถ้าใช้ IIS ให้มี [storage/web.config](/C:/xampp82/htdocs/CCW/storage/web.config:1)
- [ ] ถ้าใช้ Nginx ต้องเพิ่ม rule block `storage/` เอง

ตัวอย่างแนวคิดสำหรับ Nginx:

```nginx
location ~* ^/CCW/storage/(sessions|settings|database_backups|maintenance_exports)(/|$) {
    deny all;
    return 403;
}

location ^~ /CCW/storage/uploads/payment_slips/ {
    deny all;
    return 403;
}
```

### HTTPS / Reverse Proxy

- [ ] ถ้า Production อยู่หลัง load balancer หรือ reverse proxy ที่ terminate SSL ด้านหน้า ให้ตรวจว่า PHP ฝั่งแอปเห็น request เป็น secure จริง
- [ ] ถ้า PHP เห็นเป็น HTTP ตลอด:
  - session cookie จะไม่ถูก mark เป็น `Secure`
  - install/PWA behavior บางส่วนจะมองว่าไม่ใช่ secure context
- [ ] ถ้าจำเป็น ให้ตั้งค่าฝั่ง proxy/web server ให้ส่ง `HTTPS=on` หรือให้ PHP เห็น `SERVER_PORT=443`

### Database Privilege สำหรับ Deploy รอบนี้

- [ ] DB user ของ Production ต้องมีสิทธิ์พอสำหรับ one-time bootstrap อย่างน้อยช่วง deploy นี้
- [ ] สิทธิ์ที่อาจจำเป็น:
  - `ALTER`
  - `CREATE INDEX`
  - `UPDATE`
- [ ] เหตุผลคือระบบจะเช็ก/เพิ่ม schema และ reporting indexes หนึ่งรอบถ้า marker ยังไม่ current

## ก่อน Upload Files

- [ ] ยืนยันว่า artifact ที่จะอัปไม่มีข้อมูล runtime จาก Dev ปนขึ้นไป
- [ ] ห้ามเอาไฟล์ใน `storage/` จาก Dev ไปทับ Production ยกเว้นไฟล์ protection ที่ตั้งใจใช้
- [ ] ถ้าใช้การ copy/sync folder จริง ให้ไล่ตาม [Deployment Copy Excludes](./deployment-copy-excludes.md)

รายการที่ไม่ควรเอาจาก Dev ไปทับ:

- [ ] `storage/sessions/*`
- [ ] `storage/settings/login_throttle.json`
- [ ] `storage/settings/runtime_schema_bootstrap.json`
- [ ] `storage/uploads/payment_slips/*`
- [ ] `storage/database_backups/*`
- [ ] `storage/maintenance_exports/*`

หมายเหตุ:

- `storage/.htaccess` และ `storage/web.config` ควรอยู่บน Production
- แต่ไฟล์ข้อมูล runtime ภายใน `storage/` ควรเป็นของ Production เอง

## Deploy Order

1. [ ] ถ้ามี maintenance window ให้เปิดตามแนวปฏิบัติของทีม
2. [ ] upload code ขึ้น Production
3. [ ] ระวังอย่าทับ `.env` ของ Production
4. [ ] ระวังอย่าทับ `storage/uploads` และไฟล์ runtime สำคัญของ Production
5. [ ] ถ้ามี opcode cache / PHP-FPM / IIS recycle ให้ reload ตามมาตรฐานของเครื่องจริง
6. [ ] เปิดหน้าเว็บครั้งแรกหลัง deploy ด้วย admin 1 รอบ

## First Request Expectations

สิ่งที่ “อาจเกิดขึ้นได้และยังถือว่าปกติ” หลัง deploy:

- [ ] request แรกช้ากว่าปกติเล็กน้อย
- [ ] มีการสร้าง `storage/settings/runtime_schema_bootstrap.json`
- [ ] ผู้ใช้บางคนอาจต้อง login ใหม่ 1 ครั้ง

สิ่งที่ “ไม่ควรเกิด”:

- [ ] หน้า login ขึ้น `Connection failed`
- [ ] หน้าอื่นล้มด้วย 500 ซ้ำ ๆ
- [ ] `runtime_schema_bootstrap.json` ไม่ถูกสร้าง แต่ทุก request ยังช้า/มี error ต่อเนื่อง

## Immediate Post-Deploy Checks

- [ ] ล็อกอิน admin ได้
- [ ] เปิด `dashboard`, `booking`, `queue`, `quick_service`, `member`, `manage_system`, `sale_report` ได้
- [ ] รัน:

```powershell
powershell -ExecutionPolicy Bypass -File scripts\post_deploy_spot_check.ps1
```

- [ ] ถ้ามี restricted probe account ให้รัน branch-scope probe ด้วย
- [ ] ตรวจว่า `storage/settings/runtime_schema_bootstrap.json` ถูกสร้างและ version current
- [ ] ตรวจว่า payment slip เดิมยังเปิดผ่าน endpoint ได้
- [ ] ตรวจ error log ของ web server/PHP ทันทีหลัง deploy

## Functional Risk Checks

- [ ] ถ้ามีผู้ใช้เปิดหน้าเก่าค้างไว้ก่อน deploy อาจเจอ POST/CSRF หมดอายุ ให้ผู้ใช้ refresh 1 ครั้งแล้วลองใหม่
- [ ] ถ้ามี integration เก่าที่ยิง `GET` เข้าหน้า process โดยตรง ต้องทบทวน เพราะหลาย flow ถูกเปลี่ยนเป็น `POST`
- [ ] ถ้าใช้ branch scope หรือ role restriction หนัก ให้ตรวจด้วย restricted account จริงอีก 1 รอบ

## Stop / Rollback When

- [ ] ระบบต่อฐานข้อมูลไม่ได้หลัง deploy
- [ ] session/login ใช้งานไม่ได้
- [ ] bootstrap ทำไม่สำเร็จและเกิด error ซ้ำ
- [ ] payment slip upload หรือ view slip ใช้งานไม่ได้เพราะ permission/path
- [ ] branch access หรือ queue/payment flow หลักล้ม

## Recommended Minimum Verification Before Handing Back To Users

1. [ ] login
2. [ ] dashboard
3. [ ] queue
4. [ ] job details
5. [ ] payment / slip view
6. [ ] post-deploy spot check

## Notes

- smoke scripts, CI wrappers, browser automation scripts และ docs ไม่กระทบลูกค้าโดยตรงถ้าแค่อัปไฟล์ขึ้นเว็บ
- สิ่งที่กระทบ Production จริงคือ config, permission, schema bootstrap, web server rule, และ runtime storage path
- ถ้าเตรียม 5 จุดนี้ครบ ความเสี่ยงหลักจะลดเหลือแค่ request แรกหลัง deploy ช้าขึ้นชั่วคราว
