Loading...
ผมไม่ได้นั่งเซ็ตทีละตัว · ผมป้อนของจริงทั้ง 9 โปรเจกต์ให้ AI ไล่หาช่องโหว่ แล้วให้ออกแบบมาตรฐานกลางชุดเดียวมาครอบ · นี่คือสิ่งที่ผมป้อนเข้าไป สิ่งที่ได้กลับมา และวิธีที่ผมตรวจงาน AI ก่อนเชื่อ
ผมไม่ได้นั่งเซ็ตทีละตัว · ผมป้อนของจริงทั้ง 9 โปรเจกต์ให้ AI ไล่หาช่องโหว่ แล้วให้ออกแบบมาตรฐานกลางชุดเดียวมาครอบ · นี่คือสิ่งที่ผมป้อนเข้าไป สิ่งที่ได้กลับมา และวิธีที่ผมตรวจงาน AI ก่อนเชื่อ
อ่านจบแล้วคุณจะได้อะไร · กดข้ามไปอ่านเฉพาะหัวข้อได้เลย
หลังจากผมใช้ AI ช่วยพัฒนาแอปกับ SaaS งานเริ่มออกเร็วขึ้นมาก · โปรเจกต์งอกจากตัวเดียวเป็น 9 ตัวในเวลาไม่นาน
ทั้ง 9 ตัวต่อกับ GitLab หมด · แต่พอเปิดดูจริง ๆ บางตัวมีระบบตรวจอัตโนมัติ บางตัวไม่มี · ไม่มีสองตัวไหนตั้งเหมือนกันเลย
ตอนมี 2-3 ตัว ผมยังจำได้ว่าตัวไหนตั้งไว้ยังไง · พอถึง 9 ตัว ผมตอบไม่ได้แล้วว่าตัวไหนมีด่านกันพลาดบ้าง
แทนที่จะนั่งเปิดทีละตัวแล้วเซ็ตมือ ผมเปลี่ยนวิธี · ผมป้อนโครงสร้างจริงของทั้ง 9 ตัว พร้อมกติกาทีมและเพดานค่าใช้จ่ายให้ AI ไล่วิเคราะห์ แล้วสั่งให้ออกแบบมาตรฐานกลางชุดเดียวกลับมา
เพราะของที่กำลังจะตามมาไม่ใช่แค่ 9 · ผมมีแผนพัฒนาอีก 10 ถึง 30 ตัว · ถ้าไม่วางมาตรฐานตอนนี้ ผมจะต้องมานั่งแก้ตอนที่ของเยอะกว่าเดิม 4 เท่า
ผลที่ได้กลับมาคือ AI ชี้ 5 จุดที่ผมไม่มีด่านกันเลยสักตัว แล้วคืนแบบเต็มมาให้ · ผมไม่ได้เชื่อทันที ผมสั่งให้มันเขียนชุดทดสอบมาพิสูจน์ตัวเองก่อน 10 ข้อ
อัปเดตล่าสุด: 1 สิงหาคม 2026 · สถานะ: ออกแบบเสร็จ ด่านกิ่งงานทดสอบผ่านแล้ว ยังไม่ได้ลงมือกับ GitLab จริง
สรุปสั้นๆ อ่านแค่นี้ก็เข้าใจ
ผมป้อน 4 อย่างให้ AI · โครงสร้าง 9 โปรเจกต์ · กติกาทีมที่ว่าทุกงานต้องผ่าน dev ก่อนเข้า main · ข้อจำกัดว่าคนในทีมไม่ใช่ช่างทุกคน · และเพดานค่าโมเดลที่ห้ามเกิน
AI ไล่ดูเครื่องมือเดิมของผมแล้วชี้ 5 จุดที่ยังไม่มีด่านกัน แล้วออกแบบใหม่ให้ใช้ pipeline (สายพานตรวจและส่งงานที่ตั้งไว้ล่วงหน้า) ชุดเดียว แตกปลายทาง 3 ทาง
แบบใหม่แยก deploy (เอาโค้ดขึ้นไปวางบนเครื่อง) ออกจาก release (เปิดให้ผู้ใช้เห็นและกดใช้ได้)
ตัวที่คุมสองอย่างนี้คือ Feature Flag (สวิตช์เปิดปิดฟีเจอร์ทีละชิ้น)
อีกข้อคือหน้าเว็บที่ผู้ใช้แค่เปิดดู ต้องใช้ token (หน่วยนับข้อความที่ส่งเข้าและออกจากโมเดล AI) เป็นศูนย์
ผมตรวจงานมันด้วยชุดทดสอบด่านกิ่งงาน 10 ข้อ · ผ่านครบ 10 · ส่วนชุดทดสอบของสายพานเต็ม 13 ข้อ ยังไม่ได้รันสักข้อ
อ่านจบแล้วคุณจะได้อะไร · กดข้ามไปอ่านเฉพาะหัวข้อได้เลย
| CI (Continuous Integration — ตรวจโค้ดอัตโนมัติทุกครั้งที่มีคนส่งงาน) |
| CI/CD (ระบบตรวจโค้ดและส่งขึ้นเครื่องอัตโนมัติ) |
| CD (Continuous Delivery — ส่งโค้ดขึ้นเครื่องอัตโนมัติเมื่อตรวจผ่าน) |
| pipeline (สายพานตรวจและส่งงานที่ตั้งไว้ล่วงหน้า) |
| deploy (เอาโค้ดขึ้นไปวางบนเครื่อง) |
| release (เปิดให้ผู้ใช้เห็นและกดใช้ได้) |
| Feature Flag (สวิตช์เปิดปิดฟีเจอร์ทีละชิ้น โดยไม่ต้องส่งโค้ดขึ้นใหม่) |
| token (หน่วยนับข้อความที่ส่งเข้าและออกจากโมเดล AI) |
| branch (กิ่งงานแยก ที่ให้แต่ละคนทำงานโดยไม่ชนกัน) |
| Merge Request (ใบขอรวมโค้ด ที่ต้องมีคนตรวจก่อนอนุมัติ) |
| worktree (พื้นที่ทำงานแยกอีกชุดของโค้ดชุดเดียวกัน) |
| commit (การบันทึกงานหนึ่งครั้งพร้อมข้อความกำกับ) |
| ESLint (เครื่องมือตรวจรูปแบบโค้ด JavaScript) |
| TypeScript (ภาษาที่เพิ่มการตรวจชนิดข้อมูลให้ JavaScript) |
| unit test (ทดสอบชิ้นส่วนย่อยของโค้ดทีละชิ้น) |
| Playwright (เครื่องมือสั่งเบราว์เซอร์ทดสอบเว็บอัตโนมัติ) |
| axe-core (เครื่องมือตรวจการเข้าถึงของคนพิการบนหน้าเว็บ) |
| Lighthouse (เครื่องมือของ Google ที่ให้คะแนนความเร็วเว็บ) |
| Gitleaks (เครื่องมือค้นหารหัสลับที่หลุดอยู่ในโค้ด) |
| Trivy (เครื่องมือสแกนช่องโหว่ในไลบรารีที่ใช้) |
| Semgrep (เครื่องมือค้นรูปแบบโค้ดที่เสี่ยงต่อช่องโหว่) |
| cache (ที่เก็บคำตอบเดิมไว้ใช้ซ้ำ) |
| SonarQube (ระบบให้คะแนนคุณภาพโค้ดระดับทีม) |
| BrowserStack (บริการทดสอบเว็บบนเบราว์เซอร์และอุปกรณ์จริงหลายรุ่น) |
| Percy (บริการจับภาพหน้าจอเทียบก่อนหลัง หาจุดที่หน้าเปลี่ยนผิด) |
| Snyk (บริการตรวจความปลอดภัยของไลบรารีเชิงพาณิชย์) |
| Sentry (บริการเก็บและแจ้งเตือนข้อผิดพลาดที่เกิดกับผู้ใช้จริง) |
| Datadog (บริการเฝ้าดูสุขภาพระบบหลังบ้าน) |
| Review App (หน้าเว็บชั่วคราวของงานชิ้นนั้น เปิดให้ทีมกดดูก่อนรวมโค้ด) |
| Staging (เครื่องซ้อมที่หน้าตาเหมือนของจริง แต่ลูกค้าไม่เห็น) |
| Production (เครื่องจริงที่ลูกค้าใช้งานอยู่) |
| rollback (ย้อนกลับไปใช้รุ่นก่อนหน้า) |
| artifact (ไฟล์งานที่ประกอบเสร็จแล้ว พร้อมเอาขึ้นเครื่อง) |
| lint (ตรวจรูปแบบการเขียนโค้ดอัตโนมัติ) |
| type-check (ตรวจว่าชนิดข้อมูลในโค้ดตรงกันไหม) |
| smoke test (ทดสอบสั้น ๆ ว่าระบบยังเปิดใช้ได้หลังส่งขึ้น) |
| migration (การแก้โครงตารางในฐานข้อมูล) |
| SHA (รหัสประจำตัวของโค้ดแต่ละรุ่น ใช้เทียบว่าของตรงกันไหม) |
| mock (ข้อมูลจำลองที่เตรียมไว้แทนของจริง) |
| golden file (ไฟล์คำตอบมาตรฐานที่ใช้เทียบผล) |
| Batch (การส่งงานเป็นชุดแล้วรอผลทีเดียว) |
| Ollama (เครื่องมือรันโมเดล AI บนเครื่องตัวเอง) |
| wildcard (กฎที่ใช้เครื่องหมายดอกจันครอบชื่อหลายตัวพร้อมกัน) |
| quota (โควตา เพดานการใช้งานต่อคนต่อวัน) |
| rate limit (การจำกัดความถี่ กันคนกดรัว) |
| circuit breaker (สวิตช์ตัดอัตโนมัติเมื่อใช้เกินงบ) |
| fast-forward (วิธีรวมโค้ดที่ทำให้รหัสรุ่นตรงกันเป๊ะ ไม่สร้างรอยต่อใหม่) |
ทีมมาตกลงกันว่าจะเลิกส่งงานเข้า main ตรง ๆ
กติกาใหม่คือทุกคนแยก branch ของตัวเอง แล้วเปิด Merge Request เข้า dev · จาก dev ค่อยเปิด Merge Request เข้า main อีกที
ฟังดูเป็นเรื่องเล็ก · แต่พอผมนั่งดูเครื่องมือที่ผมใช้อยู่ ผมพบว่ามันไม่รู้จักคำว่า dev เลยสักบรรทัด
เครื่องมือของผมรู้จัก branch ที่ต้องป้องกันแค่ 2 ชื่อ คือ main กับ master
กติกาที่ทีมตกลงกันด้วยปาก ไม่มีค่าอะไรเลย ถ้าเครื่องไม่รู้จักกติกานั้น
ผมเจ็บมาก่อนแล้ว 3 แบบ
แบบที่ 1 · งานหลายชิ้นขึ้น production พร้อมกัน แล้วพัง · หาไม่เจอว่าตัวไหนทำพัง เพราะขึ้นพร้อมกันหมด
แบบที่ 2 · ของที่ทดสอบผ่านกับของที่ขึ้นจริงเป็นคนละตัว เพราะ build ใหม่ตอน deploy
แบบที่ 3 · ค่า AI พุ่งโดยไม่รู้ตัว เพราะหน้าเว็บเรียกโมเดลตั้งแต่ผู้ใช้เปิดหน้า ทั้งที่ยังไม่ได้กดอะไรเลย
คนส่วนใหญ่พิมพ์ว่า "ช่วยออกแบบ CI/CD ให้หน่อย" แล้วได้แบบกลาง ๆ ที่เอาไปใช้จริงไม่ได้ · เพราะ AI ไม่รู้ว่าของที่คุณมีหน้าตายังไง ทีมคุณเป็นใคร และคุณรับต้นทุนไหวแค่ไหน
ผมเลยป้อน 4 ก้อนนี้ก่อนจะสั่งอะไรทั้งสิ้น
รายชื่อโปรเจกต์ทั้ง 9 ตัว พร้อมบอกว่าตัวไหนมีไฟล์ตั้งค่าสายพานอยู่แล้ว ตัวไหนยังไม่มี · ไม่ใช่บอกลอย ๆ ว่า "มีหลายโปรเจกต์"
ทีมตกลงกันแล้วว่างานทุกชิ้นต้องผ่านกิ่งรวมงานก่อนเข้ากิ่งหลัก · ข้อนี้ไม่ใช่ความชอบส่วนตัว แต่เป็นข้อบังคับที่แบบต้องรองรับ
ทีมผมไม่ได้เป็นช่างทุกคน · แบบที่ออกมาต้องอธิบายเป็นภาษาคนได้ และต้องมีคำสั่งลัดให้จำแค่ไม่กี่ตัว ไม่ใช่ให้ทุกคนไปท่องขั้นตอน
งานผมมีการเรียกโมเดล AI อยู่ในตัวสินค้า · ผมบอกไปตรง ๆ ว่าหน้าเว็บที่ผู้ใช้แค่เปิดดู ต้องไม่เสียค่าโมเดลแม้แต่บาทเดียว · ข้อนี้เปลี่ยนแบบไปคนละทางกับที่มันเสนอรอบแรก
สิ่งที่ผมห้ามไว้ก็สำคัญไม่แพ้กัน · ผมสั่งชัดว่าห้ามแตะโครงการจริงบน GitLab ห้ามแก้ไฟล์ตั้งค่าของระบบที่ใช้งานอยู่ · รอบนี้ให้ออกแบบอย่างเดียว
| ถ้าป้อนแค่โจทย์ลอย ๆ | ถ้าป้อนครบ 4 ก้อน |
|---|---|
| ได้แบบมาตรฐานตำรา ที่ไม่รู้ว่าของคุณขาดตรงไหน | ได้แบบที่ชี้จุดขาดของคุณเป็นข้อ ๆ |
| เสนอเครื่องมือเสียเงินที่เกินงบ | เสนอเท่าที่งบรับได้ แล้วบอกว่าตัวไหนค่อยจ่ายทีหลัง |
| ต้องมานั่งแก้เองแทบทั้งหมด | แก้เฉพาะจุดที่คุณมีข้อมูลมากกว่ามัน |
ทุกครั้งที่งานเข้ากิ่งหลัก ระบบจะแปะไว้ว่าผ่านด่านตรวจแล้ว ใช้เวลาเท่าไหร่ และเป็นโค้ดรุ่นไหน
ก่อนหน้านี้ผมตอบไม่ได้เลยว่าโค้ดที่อยู่บนเครื่องจริง ตรงกับที่ผมตรวจไว้หรือเปล่า
ทุกครั้งที่งานเข้ากิ่งหลัก ระบบจะแปะไว้ว่าผ่านด่านตรวจแล้ว ใช้เวลาเท่าไหร่ และเป็นโค้ดรุ่นไหน
ก่อนหน้านี้ผมตอบไม่ได้เลยว่าโค้ดที่อยู่บนเครื่องจริง ตรงกับที่ผมตรวจไว้หรือเปล่า
ทุกครั้งที่งานเข้ากิ่งหลัก ระบบจะแปะไว้ว่าผ่านด่านตรวจแล้ว ใช้เวลาเท่าไหร่ และเป็นโค้ดรุ่นไหน
ก่อนหน้านี้ผมตอบไม่ได้เลยว่าโค้ดที่อยู่บนเครื่องจริง ตรงกับที่ผมตรวจไว้หรือเปล่า
ทุกครั้งที่งานเข้ากิ่งหลัก ระบบจะแปะไว้ว่าผ่านด่านตรวจแล้ว ใช้เวลาเท่าไหร่ และเป็นโค้ดรุ่นไหน
ก่อนหน้านี้ผมตอบไม่ได้เลยว่าโค้ดที่อยู่บนเครื่องจริง ตรงกับที่ผมตรวจไว้หรือเปล่า
ทุกครั้งที่งานเข้ากิ่งหลัก ระบบจะแปะไว้ว่าผ่านด่านตรวจแล้ว ใช้เวลาเท่าไหร่ และเป็นโค้ดรุ่นไหน
ก่อนหน้านี้ผมตอบไม่ได้เลยว่าโค้ดที่อยู่บนเครื่องจริง ตรงกับที่ผมตรวจไว้หรือเปล่า
ทุกครั้งที่งานเข้ากิ่งหลัก ระบบจะแปะไว้ว่าผ่านด่านตรวจแล้ว ใช้เวลาเท่าไหร่ และเป็นโค้ดรุ่นไหน
ก่อนหน้านี้ผมตอบไม่ได้เลยว่าโค้ดที่อยู่บนเครื่องจริง ตรงกับที่ผมตรวจไว้หรือเปล่า
ทุกครั้งที่งานเข้ากิ่งหลัก ระบบจะแปะไว้ว่าผ่านด่านตรวจแล้ว ใช้เวลาเท่าไหร่ และเป็นโค้ดรุ่นไหน
ก่อนหน้านี้ผมตอบไม่ได้เลยว่าโค้ดที่อยู่บนเครื่องจริง ตรงกับที่ผมตรวจไว้หรือเปล่า
ทุกครั้งที่งานเข้ากิ่งหลัก ระบบจะแปะไว้ว่าผ่านด่านตรวจแล้ว ใช้เวลาเท่าไหร่ และเป็นโค้ดรุ่นไหน
ก่อนหน้านี้ผมตอบไม่ได้เลยว่าโค้ดที่อยู่บนเครื่องจริง ตรงกับที่ผมตรวจไว้หรือเปล่า
เรียงตามเวลาจริง · ตอนไหนที่มันชี้ถูก ผมเขียนไว้ · ตอนไหนที่ผมต้องสั่งแก้ ผมก็เขียนไว้
ผมเปิด worktree แยกจากฐานงาน แล้วสั่งถามชื่อ branch ปัจจุบัน · คำตอบที่ได้คือค่าว่าง ทั้งที่รหัส commit ตรงกับต้นทางเป๊ะ
แปลว่างานที่ผมกำลังจะเขียน ไม่มีป้ายชื่อให้ตามกลับ · ผมหยุดทันที ไม่เขียนโค้ดต่อ
ผมสร้าง branch เฉพาะงานในพื้นที่เดิม แล้วรันคำสั่งตรวจชุดเดียวกันอีกครั้ง
คราวนี้มีชื่อ branch และยังยืนบนฐาน commit เดิม · ผ่านเกณฑ์ 11 จาก 11 ข้อ ระบบจริงไม่ถูกแตะเลย
ตรวจตัวตนของพื้นที่ทำงานนี้ให้หน่อย บอกมา 3 อย่าง ชื่อ branch ปัจจุบัน · รหัสรุ่นของโค้ด · และมีไฟล์ค้างที่ยังไม่บันทึกไหม ถ้าชื่อ branch ว่าง ให้หยุดแล้วบอกผมทันที ห้ามแก้ไฟล์ต่อ
ก่อนเขียนกฎใหม่ ผมเปิดไฟล์ตัวตรวจก่อนส่งงานที่ใช้อยู่ แล้วไล่ดู 3 อย่าง
หนึ่ง · branch ที่ป้องกันไว้มีแค่ main กับ master · สอง · ปลายทาง merge ใช้ค่าตั้งต้น ถ้าไม่กำหนดจะเลือก main · สาม · ด่าน merge ตรวจ CI ครบ แต่ไม่ได้ตรวจว่า branch ต้นทางคืออะไร
ผมเจอสคริปต์ซิงก์ที่ใช้โหมดลบไฟล์ปลายทาง · ถ้ารันผิดทาง ไฟล์ต้นฉบับหายได้
แล้วผมค้นชุดติดตั้งของทีม หาข้อความที่ติดตั้งตัวตรวจก่อนส่งงาน · ค้นไม่เจอเลย แปลว่าเครื่องที่ติดตั้งใหม่จะไม่มีด่านนี้ติดไปด้วย
ผมวาง 4 environment, pipeline ตามเหตุการณ์, Feature Flag, ตัวคุมค่า AI และ shortcut 3 ตัว
ออกแบบเสร็จครบทุกส่วน · แต่ผมยังไม่ได้แตะ GitLab จริงสักที่ และยังไม่ได้รันชุดทดสอบสักข้อ
ผมเริ่มจากแยกคำสองคำนี้ออกจากกันก่อน เพราะทีมผมเคยใช้ปนกันมาตลอด
| คำ | แปลว่าอะไร | ใครเห็น |
|---|---|---|
| Deploy | เอาโค้ดชุดใหม่ขึ้นไปวางบนเครื่อง production | ยังไม่มีใครเห็น ถ้า Feature Flag ปิดอยู่ |
| Release | เปิดสวิตช์ให้ผู้ใช้เห็นและกดใช้ได้ | ลูกค้าเห็นตามสัดส่วนที่เปิด |
CI/CD คือระบบที่ทำสองอย่างนี้ให้อัตโนมัติ
CI (Continuous Integration — รวมโค้ดแบบตรวจทุกครั้ง) คือทุกครั้งที่มีคนส่งโค้ดเข้ามา ระบบรันตรวจให้เองทันที
CD (Continuous Delivery — ส่งของขึ้นระบบต่อเนื่อง) คือเมื่อตรวจผ่านแล้ว ระบบเอาโค้ดขึ้นเครื่องให้เอง
พอผมแยกสองคำนี้ได้ ผมก็กล้า deploy ทุกวัน · เพราะ deploy ไม่ได้แปลว่าลูกค้าเห็นแล้ว
ผมเจอทั้งสองด้านมากับตัว เลยเขียนให้ครบทั้งสองฝั่ง
| ข้อดีที่ได้จริง | ข้อเสียที่ต้องยอมรับ |
|---|---|
| เจอปัญหาก่อนขึ้นระบบจริง | ต้องลงทุนเวลาตั้งค่าและคอยดูแล |
| ลดงานกดทดสอบซ้ำ ๆ ด้วยมือ | ถ้าออกแบบไม่ดี จะช้าและเตือนพร่ำเพรื่อจนคนเลิกอ่าน |
| รู้ว่าใครส่งรุ่นไหนขึ้นตอนไหน | เครื่องรันงานและบริการเสริมมีค่าใช้จ่าย |
| คนใหม่เข้าทีมแล้วดูงานต่อได้ง่ายขึ้น | ตั้งค่าความลับหรือสิทธิ์ผิด อาจสร้างความเสียหายได้ |
| ปล่อยงานได้ถี่ขึ้นโดยกลัวน้อยลง | มีระบบตรวจ ไม่ได้แปลว่างานมีคุณภาพ ถ้าชุดทดสอบอ่อน |
มีระบบตรวจแล้วไม่ได้แปลว่าปลอดภัย · มันแปลว่าคุณจะรู้ตัวเร็วขึ้นเท่านั้น
คนพายลำเดียวยังส่งของได้ทั้งตลาด เพราะเส้นทางกับจังหวะถูกวางไว้แล้ว · ระบบก็เหมือนกัน
คำว่าเล็กกับเต็ม หมายถึงตรวจละเอียดแค่ไหน · คำว่าเร็วกับช้า หมายถึงใช้เวลานานแค่ไหน
จับคู่กันได้ 4 แบบ · ผมใช้ทั้ง 4 แบบในโครงการเดียว แต่คนละจังหวะ
| โหมด | เหมาะกับ | ข้อดี | ข้อเสีย |
|---|---|---|---|
| เล็ก + เร็ว | ทุกครั้งที่บันทึกงานหรือเปิดใบขอรวมโค้ด | รู้ผลไว ค่าเครื่องต่ำ | อาจไม่เจอปัญหาที่ซ่อนลึก |
| เต็ม + เร็ว | งานสำคัญและมีเครื่องแรงพอ | ตรวจครบและยังได้ผลไว | ค่าใช้จ่ายสูง |
| เล็ก + ช้า | ระบบเก่าที่ยังปรับไม่ได้ | ตั้งง่าย ไม่ต้องรื้อของเดิม | รอนานแต่ตรวจน้อย ไม่ค่อยคุ้ม |
| เต็ม + ช้า | รันกลางคืน หรือก่อนปล่อยรุ่นใหญ่ | ตรวจลึกและครอบคลุม | ใช้เวลาและเครื่องเยอะมาก |
ผมเริ่มจากของฟรีทั้งหมดก่อน แล้วค่อยจ่ายเฉพาะจุดที่ของฟรีทำไม่ได้จริง ๆ
| ของฟรีหรือค่าใช้จ่ายต่ำ | ใช้ทำอะไร |
|---|---|
| ESLint · TypeScript | ตรวจรูปแบบโค้ดและชนิดข้อมูลตามภาษาที่ใช้จริง |
| unit test และชุดทดสอบรวม | ตรวจว่าชิ้นส่วนย่อยยังทำงานถูกหลังแก้โค้ด |
| Playwright | ไล่กดหน้าเว็บตามเส้นทางสำคัญแทนคน |
| axe-core | ตรวจว่าคนพิการเข้าถึงหน้าเว็บได้ไหม |
| Lighthouse | ให้คะแนนความเร็วของหน้าเว็บ |
| Gitleaks · Trivy · Semgrep | ค้นรหัสลับที่หลุด และช่องโหว่ในไลบรารีที่ใช้ |
| cache และการรันขนาน | ลดเวลารอและค่าเครื่อง โดยตรวจเฉพาะส่วนที่เปลี่ยน |
| ของเสียเงิน | จ่ายเพื่ออะไร |
|---|---|
| เครื่องรันงานเพิ่ม | ทำให้ชุดตรวจเต็มจบเร็วขึ้น |
| SonarQube | ให้คะแนนคุณภาพโค้ดระดับทีม |
| BrowserStack | ทดสอบบนเบราว์เซอร์และอุปกรณ์จริงหลายรุ่น |
| Percy | จับภาพหน้าจอเทียบก่อนหลัง หาจุดที่หน้าเปลี่ยนผิด |
| Snyk | ตรวจความปลอดภัยของไลบรารีแบบเชิงพาณิชย์ |
| Sentry · Datadog | เก็บและแจ้งเตือนปัญหาที่เกิดกับผู้ใช้จริง |
4 ชั้น แต่ใช้ .gitlab-ci.yml ชุดเดียว
| ชั้น | ใช้เมื่อ | ลูกค้าเห็นไหม | AI ที่ใช้ | ปิดยังไง |
|---|---|---|---|---|
| CI Only | ทุกครั้งที่เขียนโค้ด | ไม่เห็น | Mock ไม่เรียกโมเดล | จบพร้อม pipeline |
| Review App | เปิด Merge Request | เฉพาะทีม ผ่าน URL ชั่วคราว | Mock หรือคำตอบที่บันทึกไว้ | ปิดอัตโนมัติ |
| Staging | merge เข้า dev แล้ว | ทีมและผู้ทดสอบ | Sandbox มีงบจำกัด | เปิดค้างเท่าที่จำเป็น |
| Production | รุ่นที่อนุมัติแล้ว | ลูกค้าเห็น | Hybrid มีโควตา | rollback ได้ |
ทำไมผมไม่แยกเป็นสองไฟล์ · เพราะสองไฟล์จะค่อย ๆ ต่างกัน · วันหนึ่งของที่ทดสอบจะไม่ใช่ของที่ขึ้นจริง แล้วไม่มีใครรู้ตัว
กลุ่มแรกตรวจความปลอดภัยก่อนเสมอ · ถ้าเจอรหัสลับหลุดอยู่ในโค้ด รอบนั้นหยุดทันที ไม่ต้องเสียเวลาทำต่อ
สองกลุ่มท้ายคือด่านเก็บหลักฐานกับด่านปิดท้าย ที่ผมสั่งเพิ่มเอง เพื่อให้ทุกครั้งที่ผ่าน มีบันทึกไว้ว่าผ่านด้วยอะไร
| เหตุการณ์ | CI ตรวจอะไร | CD ส่งขึ้นที่ไหน | ด่าน AI |
|---|---|---|---|
| Push เข้า feature branch | lint, type-check, unit test | ไม่ deploy | AI token = 0 |
| เปิด Merge Request | Fast CI + build + smoke test | Review App ชั่วคราว | Mock AI |
| Merge เข้า dev | Full CI + integration + security | Staging อัตโนมัติ | Sandbox มีเพดาน |
| สร้าง Release Tag | Full CI + E2E + migration check | เตรียม Production | Live AI ตัวอย่างเล็ก |
| กดอนุมัติ Production | ตรวจ SHA, artifact, health | deploy artifact เดิม | Production budget |
ผมเปิดใช้เพิ่มอีก 5 อย่างเพื่อลดค่าเครื่อง
interruptible ยกเลิกรอบตรวจเก่าเมื่อมีการส่งงานใหม่ทับ · cache ไม่โหลดของเดิมซ้ำ
needs รันงานที่ไม่ต้องรอกันแบบขนาน · resource_group กันการส่งขึ้นเครื่องซ้อนกัน
ถ้าให้ทุกงานวิ่งเรียงกันทีละตัว รอบหนึ่งจะกินเวลาเป็นสิบนาที
ผมเลยสั่งให้จัดใหม่ · งานที่ไม่ต้องรอผลของกันและกัน ให้ปล่อยวิ่งขนานกันไปเลย · รอบจริงจึงจบใน 3 ถึง 4 นาที
ถ้าให้ทุกงานวิ่งเรียงกันทีละตัว รอบหนึ่งจะกินเวลาเป็นสิบนาที
ผมเลยสั่งให้จัดใหม่ · งานที่ไม่ต้องรอผลของกันและกัน ให้ปล่อยวิ่งขนานกันไปเลย · รอบจริงจึงจบใน 3 ถึง 4 นาที
ถ้าให้ทุกงานวิ่งเรียงกันทีละตัว รอบหนึ่งจะกินเวลาเป็นสิบนาที
ผมเลยสั่งให้จัดใหม่ · งานที่ไม่ต้องรอผลของกันและกัน ให้ปล่อยวิ่งขนานกันไปเลย · รอบจริงจึงจบใน 3 ถึง 4 นาที
ถ้าให้ทุกงานวิ่งเรียงกันทีละตัว รอบหนึ่งจะกินเวลาเป็นสิบนาที
ผมเลยสั่งให้จัดใหม่ · งานที่ไม่ต้องรอผลของกันและกัน ให้ปล่อยวิ่งขนานกันไปเลย · รอบจริงจึงจบใน 3 ถึง 4 นาที
ถ้าให้ทุกงานวิ่งเรียงกันทีละตัว รอบหนึ่งจะกินเวลาเป็นสิบนาที
ผมเลยสั่งให้จัดใหม่ · งานที่ไม่ต้องรอผลของกันและกัน ให้ปล่อยวิ่งขนานกันไปเลย · รอบจริงจึงจบใน 3 ถึง 4 นาที
และตั้งอายุ artifact ให้หมดเวลาเอง ไม่ต้องมาไล่ลบทีหลัง
ใช้ Feature Flag (สวิตช์เปิดปิดฟีเจอร์) · เปิดหรือปิดของทีละชิ้นได้โดยไม่ต้อง deploy ใหม่
โค้ดอยู่บนเครื่องจริงแล้ว แต่ผู้ใช้ 0 เปอร์เซ็นต์มองเห็น
ผมใช้ของจริงบนเครื่องจริง · จะเจอปัญหาที่ Staging ไม่มีวันเจอ เช่นข้อมูลจริงที่รูปแบบเพี้ยน
ดู error กับต้นทุนต่อคนในแต่ละขั้น · ตัวเลขนิ่งค่อยขยับ
ถ้าตัวเลขเพี้ยน ผมปิด Flag กลับได้ในไม่กี่วินาที ไม่ต้องรอ deploy รอบใหม่
ตอนคุยกับทีม ผมพบว่าทุกคนพูดคำว่า token คนละความหมาย
| Token | คืออะไร | เปลืองเงินแบบไหน |
|---|---|---|
| AI Token | ข้อความที่ส่งเข้าและออกจากโมเดล AI | คิดค่า API ตามปริมาณ |
| Runner Minute | เวลาเครื่องที่รัน CI | ค่าเครื่องหรือโควตา GitLab |
| Access Token | รหัสให้ระบบเข้าถึง GitLab หรือ API | ไม่ใช่หน่วยเงิน แต่หลุดแล้วเสียหายหนัก |
ข้อสรุปที่ทำให้ผมโล่งใจคือ CI/CD ปกติไม่ต้องใช้ AI สักครั้ง
ค่าโมเดลเกิดตอนชุดทดสอบหรือตัวผลิตภัณฑ์เรียกโมเดลจริงเท่านั้น
ตรงนี้คือส่วนที่คนข้ามกันมากที่สุด · แบบที่ AI คืนมาอ่านแล้วดูดีเสมอ เพราะมันเขียนหนังสือเก่ง · แต่อ่านรู้เรื่องกับใช้ได้จริงเป็นคนละเรื่อง
ผมใช้ 3 ชั้นนี้ทุกครั้ง
ผมไม่รับแบบเปล่า ๆ · ต้องมีชุดทดสอบแนบมาด้วยว่าถ้าของทำงานถูก ผลจะออกมาหน้าตาแบบไหน · ถ้ามันเขียนชุดทดสอบไม่ได้ แปลว่ามันยังไม่เข้าใจโจทย์จริง
ผมรันชุดทดสอบด่านกิ่งงานเอง ไม่ให้มันรายงานผลให้ฟัง · ผลออกมาผ่าน 10 จาก 10 ข้อ · ตัวเลขนี้ผมเห็นกับตา ไม่ใช่มันบอก
ชั้นนี้สำคัญที่สุด · ผมสั่งให้ลองส่งงานผิดทางดู เช่น ยิงจากกิ่งงานเข้ากิ่งหลักตรง ๆ · ถ้าด่านปล่อยผ่าน แปลว่าด่านนั้นเป็นแค่ของประดับ
ชุดทดสอบ 10 ข้อที่ผมใช้ ครอบทางเดินของงานทุกเส้นที่เป็นไปได้
| สิ่งที่ทดสอบ | ต้องได้ผลว่า |
|---|---|
| ส่งจากกิ่งงานเข้ากิ่งรวมงาน | ผ่าน |
| ส่งจากกิ่งงานเข้ากิ่งหลักตรง ๆ | ถูกบล็อก |
| ส่งจากกิ่งรวมงานเข้ากิ่งหลัก | ผ่าน |
| เขียนทับกิ่งรวมงานโดยไม่เปิดใบขอรวม | ถูกบล็อก |
| เขียนทับกิ่งหลักโดยไม่เปิดใบขอรวม | ถูกบล็อก |
| ส่งงานด่วนแก้ของพัง ตอนที่ยังไม่เปิดสิทธิ์ | ถูกบล็อก |
| ส่งงานด่วนแก้ของพัง ตอนเปิดสิทธิ์แล้ว | ผ่าน |
| โครงการเก่าที่ยังไม่เปิดใช้กติกานี้ | ไม่ถูกแตะเลย |
| ย้อนจากกิ่งหลักกลับเข้ากิ่งรวมงาน | ถูกบล็อก |
| โครงการที่ใช้ชื่อกิ่งหลักแบบเก่า | ใช้กติกาเดียวกัน |
ข้อที่ 8 คือข้อที่ผมสั่งเพิ่มเอง · แบบรอบแรกไม่มีข้อนี้ · มันออกแบบให้กติกาใหม่มีผลกับทุกโครงการทันที ซึ่งจะทำให้ 9 ตัวเดิมของผมส่งงานไม่ได้ทั้งหมดในวันเดียว · ผมเลยสั่งให้เพิ่มสวิตช์เปิดทีละโครงการ แล้วเขียนข้อทดสอบมายืนยันว่าโครงการที่ยังไม่เปิด จะไม่ถูกแตะ
นี่คือจุดที่คนกับ AI ต่างกัน · มันเก่งเรื่องออกแบบให้ครบตามตำรา แต่ผมเป็นคนเดียวที่รู้ว่าถ้าของ 9 ตัวหยุดพร้อมกันวันจันทร์ ใครเดือดร้อน
ส่วนที่ต้องพูดตามตรง · ชุดทดสอบของสายพานเต็มอีก 13 ข้อ ผมยังไม่ได้รันสักข้อ · เพราะต้องต่อกับ GitLab จริงถึงจะรันได้ และรอบนี้ผมหยุดไว้ที่แบบ
ผมเตรียม mock response กับ golden file ไว้ แล้วให้ระบบตอบจากไฟล์แทนการเรียกโมเดล
ตรวจ JSON Schema ความยาว ช่องบังคับ และคำต้องห้าม · จำลอง error กับ timeout ด้วย
Playwright ดัก API ที่วิ่งออกไปข้างนอกแล้วคืนข้อมูลจำลองได้ ของจริงจึงไม่ถูกเรียกสักครั้ง
เลือกเคสสำคัญ 10 ถึง 30 เคส ตั้งงบสูงสุดต่อรอบ แล้วรันแบบ Batch
เกินงบให้หยุด ห้าม retry ไม่จำกัด · เอกสาร OpenAI ระบุว่างาน Batch ประมวลผลภายใน 24 ชั่วโมง และลดราคาครึ่งหนึ่งจากราคาปกติ
เทียบราคาต่อปริมาณเท่ากัน เฉพาะงานที่รอผลได้ภายใน 24 ชั่วโมง
รันโมเดลบนเครื่องตัวเองได้ · แต่ผมต้องพูดให้ครบว่าค่าใช้จ่ายไม่ได้หายไป
มันย้ายจากค่า token ไปเป็น CPU, GPU, RAM, ค่าไฟ และเวลาดูแลเครื่อง · คุณภาพต้องเทียบกับ golden set ก่อนใช้จริง
กฎข้อแรกที่ผมล็อกไว้สั้นมาก · ผู้ใช้เปิดหน้าเว็บเฉย ๆ ต้องใช้ AI token เท่ากับ 0
โมเดลถูกเรียกเมื่อผู้ใช้กดปุ่มที่ต้องใช้ AI เท่านั้น · ผังข้างล่างคือทางเดินทั้งหมด
โหมดที่ผมให้ผู้ใช้เลือกมี 5 แบบ · ตั้งชื่อด้วยผลลัพธ์ ไม่ใช่ชื่อโมเดล เพราะผู้ใช้อยากเลือกผลลัพธ์
| โหมดหน้าจอ | เบื้องหลังทำอะไร | เหมาะกับใคร |
|---|---|---|
| ประหยัด | Cache แล้วกฎ แล้วโมเดลเล็ก | ผู้ใช้ฟรีและงานทั่วไป |
| สมดุล | Cache แล้วโมเดลเล็ก ขยับเป็นใหญ่เมื่อจำเป็น | ค่าเริ่มต้นของ Production |
| ละเอียด | โมเดลคุณภาพสูง บริบทเยอะ | งานสำคัญและผู้จ่ายเงิน |
| ทำเบื้องหลัง | เข้าคิว Batch แล้วแจ้งเมื่อเสร็จ | รายงานจำนวนมาก |
| เก็บในเครื่อง | โมเดลที่รันบนเครื่องตัวเอง | ข้อมูลอ่อนไหว |
ตัวคุมต้นทุนที่ผมใส่ไว้ 8 อย่าง · Cache คืนคำตอบเดิม · สร้างคำตอบยอดนิยมล่วงหน้า · เลือกขนาดโมเดลตามงาน · จำกัดความยาวข้อความ · retry ได้ครั้งเดียว · โควตารายวันต่อคน · จำกัดความถี่กันกดรัว · ส่งเฉพาะข้อมูลที่จำเป็น ไม่ส่งเอกสารทั้งก้อน
เส้นสีที่วิ่งขนานกันคือกิ่งงานของแต่ละคน · ทุกเส้นต้องลงมารวมที่กิ่งกลางก่อน แล้วค่อยขึ้นกิ่งหลักพร้อมกันทีเดียว
ถ้าปล่อยให้ยิงเข้ากิ่งหลักตรง ๆ ได้ ของที่ยังไม่ผ่านตาใครจะไปโผล่บนเครื่องจริงทันที
กติกาคือทุกงานผ่าน dev ก่อนเสมอ · ห้ามลัดเข้า main ตรง ๆ
| Branch | Push ตรง | รับ Merge จาก | ใคร merge ได้ | ปลายทาง Deploy |
|---|---|---|---|---|
| feature/* | เจ้าของ branch | เขียนเอง | ตามผู้ดูแลโครงการ | Review App |
| dev | No one | feature/* | Developer และ Maintainer | Staging |
| main หรือ master | No one | dev เท่านั้น | Maintainer หรือ Release Owner | Production |
| Release Tag | No one | สร้างจาก main | Release Owner | Production ตามเลขรุ่น |
GitLab แนะนำให้ development branch ตั้ง Allowed to merge เป็น Developer และ Maintainer ส่วน Allowed to push เป็น No one
คำว่า No one ต้องตั้งจริง ห้ามปล่อยว่าง · การไม่ตั้งค่าไม่เหมือนการปิดสิทธิ์ชัด ๆ
Branch Protection กัน push ตรงได้ แต่กันไม่ได้ตอนมีคนเปิด MR จาก feature เข้า main แล้วคนตรวจเผลอกดผ่าน
ผมเลยเพิ่ม release-source-gate · ถ้าปลายทางคือ main ต้นทางต้องเป็น dev เท่านั้น ไม่ตรงให้ pipeline ล้ม
ด่านที่ผมบังคับเพิ่ม · pipeline ต้องเขียวก่อน merge · คนเปิด MR ห้ามอนุมัติงานตัวเอง · ห้าม force push ที่ dev และ main · การแก้ .gitlab-ci.yml migration auth และ payment ต้องมีคนตรวจเฉพาะทาง
ตอน merge จาก dev เข้า main ผมใช้ Fast-forward · main จะชี้ไป commit เดียวกับ dev
ผลคือรหัสรุ่นที่ทดสอบบนเครื่องซ้อม ตรงกับที่ขึ้นเครื่องจริงเป๊ะ
ไฟล์งานชิ้นเดิมถูกเลื่อนขึ้นไปใช้ ไม่มีการประกอบของใหม่ที่ไม่เคยทดสอบ
ร้านที่เปิดทุกเช้าไม่ได้ชนะเพราะเก่งกว่า แต่ชนะเพราะทำเหมือนเดิมได้ทุกวัน
3 ตัว · ผมเคยคิดจะทำมากกว่านี้ แล้วตัดทิ้ง เพราะเกิน 3 คือไม่มีใครจำ แล้วทุกคนกลับไปทำมือ
ตรวจว่าอยู่บน feature branch จริง รัน Fast CI ตรวจขอบเขตไฟล์ ตรวจ secret แล้วเปิด MR โดยบังคับปลายทางเป็น dev · จบด้วยการคืน URL ของ Review App
ตรวจว่าต้นทางเป็น dev และชุดตรวจเต็มผ่านแล้ว
ตรวจว่ารหัสรุ่นบนเครื่องซ้อมตรงกับรุ่นที่จะปล่อย แล้วส่งขึ้นเครื่องจริงโดยยังปิดสวิตช์ไว้
ถ้าผลตรวจสุขภาพระบบไม่ผ่าน ให้ย้อนกลับรุ่นเดิมทันที
อ่านอย่างเดียว ห้ามแก้อะไร · ไล่ดูทีละโครงการว่ามี dev ไหม ล็อกแล้วหรือยัง มีด่านกันทางลัดไหม มี Feature Flag ไหม และมีตัวคุม AI token ไหม
Shortcut พวกนี้เรียกสคริปต์ตรวจจริงเป็นหลัก · ให้ AI แปลผลเป็นภาษาคนเฉพาะตอนมีปัญหา
เหตุผลมี 2 ข้อ · งาน branch เป็นงานเปราะที่ห้ามตีความผิด · และการให้สคริปต์ตรวจแทนช่วยลดค่า AI token ไปในตัว
ตรวจโครงการนี้แบบอ่านอย่างเดียว ห้ามแก้ไฟล์ ห้าม merge ห้าม deploy คืนตาราง 9 ช่อง Dev Exists, Dev Protected, Direct Push Blocked, Feature→Dev Gate, Dev Staging, Dev→Main Gate, Fast-forward, Production Approval, Hotfix Policy ทุกช่องต้องแนบหลักฐานจริงเป็น URL, SHA หรือ pipeline id เข้าถึงข้อมูลไม่ได้ให้ตอบว่า UNKNOWN ห้ามตอบว่าไม่มี
ตรวจว่าระบบนี้มีตัวคุมค่า AI ครบไหม ตอบมีหรือไม่มี พร้อมไฟล์และเลขบรรทัด 1 หน้าเว็บที่เปิดเฉย ๆ เรียกโมเดลหรือไม่ 2 มี Cache ไหม และ cache key ผูกกับ user กับสิทธิ์หรือเปล่า 3 มี Model Routing ไหม 4 มี daily quota กับ rate limit ไหม 5 มี budget circuit breaker ไหม 6 ชุดทดสอบใช้ Mock หรือเรียกโมเดลจริง ห้ามเดา ไม่มีหลักฐานให้เขียนว่าไม่มีข้อมูล
ไฟล์ตั้งค่า ผมขยายของเดิมที่ทีมใช้อยู่ แทนการสร้างไฟล์ใหม่
{
"branch_flow": {
"integration_branch": "dev",
"production_branch": "main",
"release_source_only": "dev",
"direct_push_forbidden": ["dev", "main"],
"hotfix_enabled": false
}
}| เรื่อง | วิธีที่คนส่วนใหญ่ทำ | วิธีที่ผมเลือก | เหตุผล |
|---|---|---|---|
| ไฟล์ CI | แยก 2 ไฟล์ ทดสอบกับ production | ไฟล์เดียว แยกด้วย rules | สองไฟล์จะค่อย ๆ ต่างกัน จนของที่ทดสอบไม่ใช่ของที่ขึ้นจริง |
| การกันทางลัด | ล็อก Branch Protection พอ | ล็อก บวก release-source-gate | Protection กันแค่ push ตรง กัน MR ลัดไม่ได้ |
| การขึ้น Production | build ใหม่ตอน deploy | เลื่อน artifact เดิมด้วย fast-forward | ของที่ขึ้นจริงต้องเป็นชิ้นเดียวกับที่ทดสอบผ่าน |
| ค่า AI | เรียกโมเดลตั้งแต่โหลดหน้า | เปิดหน้า เท่ากับ 0 token | คนเข้าเว็บมากกว่าคนกดใช้ฟีเจอร์หลายเท่า |
| Shortcut | สร้างคำสั่งย่อยเยอะตามงาน | 3 ตัวเท่านั้น | เกิน 3 คือไม่มีใครจำ |
ผมไม่เขียนแต่ด้านดี · 4 ข้อนี้คือราคาที่ผมจ่ายจริง
หนึ่ง · เส้นทางยาวขึ้นหนึ่งช่วงเสมอ · งานเล็กที่เคยขึ้นได้ใน 10 นาที ต้องผ่าน dev ก่อน
สอง · รอบที่แล้วผมเสียเวลาไปหนึ่งรอบเต็มกับเรื่อง branch ไม่มีชื่อ ก่อนได้เขียนโค้ดจริงสักบรรทัด
สาม · Feature Flag ที่ไม่มีเจ้าของจะกลายเป็นขยะค้างระบบ · ผมต้องกำหนดเจ้าของกับวันหมดอายุตั้งแต่วันที่สร้าง
สี่ · ที่หนักสุดคือ ทั้งหมดนี้ยังเป็นแบบ · ผมยังไม่ได้พิสูจน์กับ 9 โครงการจริงเลยแม้แต่ตัวเดียว
| Phase | สถานะ | แปลเป็นภาษาคน |
|---|---|---|
| แยก Deploy กับ Release | 1/1 | ล็อกแนวคิดแล้ว |
| ออกแบบ Environment | 4/4 | มี CI, Review App, Staging, Production |
| ออกแบบตัวคุม Token | 8/8 | มี Mock, Cache, Routing, Budget, Quota, Batch |
| ออกแบบ Branch Protection | 3/3 | ปิด direct push และกำหนดผู้ merge |
| ชุดทดสอบบังคับ | 0/13 | ยังไม่ได้รันสักข้อ |
| ตรวจ GitLab จริง | 0/9 | ยังไม่ได้เปิดตรวจสักโครงการ |
แยกที่ปลายทาง ไม่ใช่แยกไฟล์ · งานพัฒนาใช้ Fast CI แล้วขึ้น Review App · งานเปิดจริงใช้ Full CI แล้วกดอนุมัติด้วยมือ
ได้ ต้องใช้สองชั้นคู่กัน · Branch Protection ปิด direct push และ release-source-gate ตรวจต้นทางของ MR · ขาดชั้นที่สองเมื่อไร คนเปิด MR ลัดได้ทันที
รายงาน UNKNOWN ห้ามเขียนว่าไม่มี · คำว่าไม่มีแปลว่าตรวจแล้วและไม่พบ ซึ่งคนละเรื่องกับเข้าไม่ถึงข้อมูล
อันตราย เพราะ release ครั้งเดียวจะพาหลายฟีเจอร์ขึ้นพร้อมกัน · ทางแก้คือใส่ Flag แยกรายฟีเจอร์ แล้ว deploy บ่อยขึ้นโดยยังปิด Flag
ต้องมีเส้นทางแก้ด่วนแยกไว้ ใช้เฉพาะตอน production ล่ม ต้องมีคนอนุมัติ · แล้วต้อง merge main กลับเข้า dev ทันทีหลังจบเหตุ ไม่งั้น fast-forward รอบหน้าจะทำไม่ได้
เลิกพูดคำว่าปล่อยของรวม ๆ · เปลี่ยนเป็น deploy แล้ว กับ release แล้ว · ความเข้าใจผิดในทีมหายไปครึ่งหนึ่ง
หน้าเว็บที่เปิดเฉย ๆ ต้องเรียกโมเดล 0 ครั้ง · กฎข้อเดียวนี้ตัดค่าใช้จ่ายก้อนใหญ่ที่สุดออกไป
ถ้าสัปดาห์นี้แก้ได้จุดเดียว ให้เพิ่มด่านที่บล็อก MR เข้า main ที่ต้นทางไม่ใช่ dev · คุ้มที่สุดต่อแรงที่ลงไป
เปิดโครงการของคุณแล้วถามว่า ถ้าวันนี้มีคนเปิด MR จาก feature เข้า main ระบบจะหยุดเขาไหม · ตอบไม่ได้แปลว่ายังไม่มีด่าน
ตอนต่อไปของบันทึกนี้
เมื่อผมรันชุดทดสอบครบ 13 ข้อ และตรวจครบ 9 โครงการ ผมจะกลับมาเขียนพร้อมตารางผลจริงว่าโครงการไหนขาดด่านไหน
เรือที่แล่นเร็วที่สุดไม่ใช่ลำที่ไม่มีด่าน แต่คือลำที่ด่านอยู่ถูกที่ จนไม่มีใครต้องหยุดเรือกลางทะเล
สมัครสมาชิก One Man Fleet เพื่อเข้าถึง Content, Template และ Community คุณภาพสูง
สมัครสมาชิก
หลาย Project บน Server เดียว ทีมหลายคน clone แยก กิน Disk มหาศาล → ใช้ Bare Repo + Worktree แชร์ .git เดียว ประหยัด Disk ~80% + wt helper script ทีมสร้าง worktree ได้ใน 30 วินาที
สร้าง onemanfleet.com ทั้งระบบด้วย AI — 30+ หน้า, 40+ API, 14 database tables ค่า server ไม่ถึง 1,000 บาท/เดือน บทความนี้เปิดโครงสร้างทั้งหมดด้วย Interactive Diagram