15.2 · Environments & branches

15.2.1 · Branch-per-environment pattern

แพลตฟอร์ม VTRC ไม่มี branching strategy กลางที่บังคับใช้ทุก repo — แต่ละทีมเลือก branch naming ของตัวเอง แล้ว "canonical branch" (branch ที่มีโค้ดจริงใช้งาน) มักไม่ตรงกับ default branch ที่ git แสดงให้เห็นตอน clone ครั้งแรก ตารางเต็มอยู่ที่ Canonical Truths — สรุปรูปแบบที่พบ:

รูปแบบ branch naming	Repo ตัวอย่าง	ความหมาย
prod = canonical, master/main ว่างเปล่า	2way-api, 2way-vtrc-api, 2way-meeting-backoffice, ai-recruitment-api, benefit-api, chat-center-api, recruitment-api, recruitment-web, vtrc-common	โค้ดจริงทั้งหมดอยู่ที่ prod — main/master เป็นแค่ placeholder ที่เหลือจากตอนสร้าง repo
uat/UAT = canonical	meeting-backoffice, meeting-backoffice-new, pms-api, workflow-api	ทีมยังพัฒนาอยู่ที่ UAT เป็นหลัก — prod อาจยังไม่มีหรือ merge ไม่ครบ
master = canonical (ตรงกับ default)	2way-batch, 2way-line-service, report-log, sso-api (default main ว่าง, canonical master), vtrc-mobile, vtrc-backoffice, vtrc-web, vtrc-rc-backoffice	รูปแบบดั้งเดิมที่สุด — ไม่มี prod/uat แยก
branch เฉพาะชื่อ service	meeting-vtrc-api (prod-meeting-vtrc-api)	ชื่อ branch ผูกกับชื่อ repo ตรง ๆ ไม่ใช้คำ generic
develop มีโค้ดมากกว่า master (default)	vtrc-backoffice	เอกสารนี้อ้างอิง master เป็น canonical ตาม policy แต่ develop มี commit เพิ่มที่ไม่ได้ตรวจในรอบนี้ — ทีมควรยืนยันว่า develop คือของจริงที่กำลังจะ merge หรือเป็น branch ทดลองที่ทิ้งไว้

15.2.2 · ทำไม pattern นี้เสี่ยง

ไม่มี single source of truth branch ระดับแพลตฟอร์ม

วิศวกรที่ join ทีมใหม่ clone repo แล้วเจอ main/master ว่างเปล่าโดย default — ถ้าไม่รู้ล่วงหน้าว่าต้อง checkout prod/uat/branch เฉพาะชื่อ จะเข้าใจผิดว่า repo ไม่มีโค้ดหรือถูก decommission แล้ว เอกสารนี้ (VTRC Knowledge Manual v2) แก้ปัญหานี้แค่ระดับ documentation — ไม่ได้แก้ที่ต้นเหตุ (repo settings/default branch จริง)

Hotfix branch ที่แยกออกจาก canonical แล้วไม่ merge กลับ

พบ 3 กรณีที่บ่งชี้ pattern นี้ (ไม่ใช่ระบบ hotfix ที่ตั้งใจ แต่เป็น fork/environment ที่แยกกันเดินแล้วไม่ sync กลับ):

1. vtrc-backoffice vs vtrc-backoffice-new — fork ทั้งชุดของกันและกัน (99%+ โค้ดเหมือนกัน) แต่พัฒนาแยกกันคนละ repo ไม่ใช่แค่ branch (Volume 4 index §vtrc-backoffice vs vtrc-backoffice-new)
2. 2way-api/2way-vtrc-api — ทั้งสองอ้างว่าเป็น backend ของ "2way Platform" แต่ 2way-vtrc-api (Express, legacy) กลับเป็น backend หลักที่ 2way-meeting-backoffice เรียกใช้จริงในปัจจุบัน ไม่ใช่ 2way-api (NestJS, ใหม่กว่า) (2way-meeting-backoffice/03-persistence-integrations §Integration 5)
3. benefit.wdHospitals vs vtrc.WDHospitals — ไม่ใช่ branch แต่เป็น schema คู่ขนานที่เกิดจาก pattern เดียวกัน (ระบบใหม่สร้างขึ้นมาโดยไม่ decommission ระบบเดิม — ดู Volume 14)

รูปแบบร่วมของทั้ง 3 กรณี — เมื่อทีมสร้างระบบ/repo ใหม่มาแทนของเดิม มักไม่มี migration path ที่ชัดเจนที่ปิดของเดิมอย่างเป็นทางการ ทำให้ระบบเดิมกับใหม่วิ่งคู่กันไปเรื่อย ๆ โดยไม่มีใครตัดสินใจ "เลิกใช้ตัวเก่า" อย่างเป็นทางการ

Package manager ไม่ตรงกันข้าม branch เดียวกัน

2way-api มี yarn.lock แต่ workspace convention ของทีมคือ npm ตาม scorecard ของ repo (2way-api/index §Stack) — ถ้ามีคนรัน npm install ทับ yarn install โดยไม่ตั้งใจ จะได้ package-lock.json ที่ไม่ sync กับ yarn.lock เดิม

EXPOSE/.env ไม่ตรงกันข้าม environment file

job-scheduler-api มี EXPOSE 3000 ใน Dockerfile ที่ไม่ตรงกับ PORT=9900 ใน .env จริง (Volume 13.2.3) — เป็นความเสี่ยงเดียวกันในเชิงโครงสร้างกับ branch drift: ค่าที่ประกาศไว้ (Dockerfile, .env.example) ไม่ตรงกับค่าที่ deploy จริง ทำให้เอกสาร/โค้ดที่อ่านได้ไม่น่าเชื่อถือ 100% ต้อง cross-check กับ .env จริงเสมอ

15.2.3 · Environment ที่พบต่อ repo

Environment	Repo ที่มีไฟล์ .env แยกชัดเจน	หลักฐาน
dev / uat / prod (3 ไฟล์แยก)	meeting-vtrc-api (.envdev, .envuat, .envprod — ทั้งหมด commit เข้า git ไม่ gitignore)	meeting-vtrc-api/index
uat เท่านั้น (ไม่มี prod ที่ตรวจสอบได้)	pms-api (.env ที่ commit เป็นค่า UAT, NODE_ENV=uat)	pms-api/index
prod เท่านั้น (ไม่มี uat ที่ตรวจสอบได้ใน repo เดียวกัน)	benefit-api, recruitment-api, ai-recruitment-api, vtrc-common, chat-center-api	Vol 6 index ของแต่ละ repo
ไม่มี .env/.env.example เลย	sso-api, 2way-batch, vtrc-ocr-api	Vol 6/5/9 index ของแต่ละ repo

ข้อสังเกต — ไม่มี repo ใดใน Domain Microservices group ที่ commit ทั้ง .env.dev/.env.uat/.env.prod พร้อมกันเหมือน meeting-vtrc-api — ส่วนใหญ่ commit ค่าเดียว (มักเป็น prod หรือ uat ตาม environment ที่ทีมทำงานล่าสุด) แล้วพึ่งพา CI/CD หรือ manual override ตอน deploy จริงสำหรับ environment อื่น (ไม่มีหลักฐานยืนยันวิธีนี้ในโค้ดที่ตรวจสอบได้ — UNVERIFIED)

15.2.4 · คำแนะนำเชิงโครงสร้าง (ไม่ใช่ debt item — เป็นข้อสังเกตระดับ pattern)

1. ตั้ง default branch ของทุก repo ให้ตรงกับ canonical branch จริง (หรืออย่างน้อย README บอกชัดเจนที่ root ของทุก repo — ปัจจุบันมีแค่เอกสารนี้ที่ track ไว้)
2. ทุกครั้งที่สร้างระบบใหม่มาแทนระบบเดิม (เช่น benefit-api แทน vtrc-api withdraw module) ให้มี explicit decommission plan สำหรับของเดิม ไม่ใช่ปล่อยให้วิ่งคู่กันไม่มีกำหนด
3. เพิ่ม CI check ที่ validate ว่า EXPOSE/Dockerfile ตรงกับ .env/.env.example ก่อน merge — ป้องกัน drift แบบที่พบใน job-scheduler-api

ไป 15.3 Scorecard →