เราอยู่ตรงไหนของแผนที่#

บนแถบ 5 ขั้น Test กับ Deploy/Run สว่างพร้อมกัน

ชิ้นจิ๊กซอว์ที่ 6 คือเรื่องที่ 14 ด่านตรวจและ CI เรื่องที่ 15 ปล่อยของขึ้น production และเรื่องที่ 16 ข้อมูลและการแก้ database

หัวใจของตอนนี้#

ด่านที่คนต้องจำเอง ไม่ใช่ด่าน และของที่ปล่อยออกไปต้องถอยกลับได้เสมอ

ทำไมเรื่องนี้สำคัญ?#

ตอน 6 ให้ทุกงานมีระดับแล้ว

แต่ระดับที่ไม่มีใครบังคับ ก็เป็นแค่ป้าย

ถ้าไม่มีด่านที่เครื่องล็อก กับทางถอย งาน high ตัวเดียวที่หลุดคืนวันศุกร์ก็ทำข้อมูลลูกค้าหายได้

และตอน 9 จะไม่มีอะไรให้ “ถอย”

หลัก 5 ข้อข้างล่างคือวิธีทำให้หัวใจข้อนี้เป็นจริง

ศุกร์ 18:00#

ticket #57 ระดับ high ขอเปลี่ยนชื่อ column amount เป็น total (ตัวอย่าง)

agent-build เขียน migration ที่เพิ่ม total แล้ว drop amount ในขั้นเดียว

test ผ่านหมด เพราะ test database ว่างเปล่า

ต้นนั่งกินข้าวอยู่ กด approve บนมือถือ

18:04 deploy ออกไป code เก่าที่ยังอ่าน amount พังอยู่ 3 ชั่วโมง (ตัวอย่าง)

ไม่มีปุ่มถอย เพราะ column หายไปแล้ว

เรื่องจริงจาก Jason Lemkin

กรกฎาคม 2025 Jason Lemkin ผู้ก่อตั้ง SaaStr เล่าบน X ว่า agent ของ Replit ลบ database ของแอปที่เขากำลังสร้าง

เขา เขียน ให้ลองนึกถึงคนที่ไม่ใช่ dev ที่สร้างแอปมาหลายสัปดาห์ แล้ว “Replit deletes your database without asking”

และ ตอบ คนที่ถามเรื่องสิทธิ์ว่า “I didn’t give it permission or ever know it had permission”

ต้นเหตุที่เขา สรุปทีหลัง คือ “Replit used the >same< database for preview, testing and production. That simply is NOT ok.”

เขาเรียกเรื่องนี้ว่า “database deletion and code freeze ignoring incident” ใน อีกโพสต์

ต้องพูดให้ครบ เขาบอกเองว่า “this was still a demo app” ยังไม่ได้เปิดใช้จริง และ “No revenue lost”

แต่บทเรียนตรงกับต้นเป๊ะ

code freeze ที่บอกไว้ในแชท agent ไม่ได้ถือเป็นด่าน

ด่านที่อยู่ในหัวเรา agent มองไม่เห็น

ป้ายระดับต้องมีฟันยังไง?#

ตารางตอน 6 บอกว่าใครอนุมัติ

แต่ยังไม่มีอะไรหยุดการ merge ถ้าคนนั้นไม่ได้อนุมัติ

ตอน 4 เราเห็นแล้วว่ากฎใน prompt ถูกลืมได้

ด่านคือกฎที่ platform บังคับ ไม่ใช่กฎที่ agent ต้องจำ

หลัก 1: ด่านตามระดับ เครื่องเป็นคนล็อก#

ข้อนี้คือครึ่งแรกของหัวใจตรงๆ ถ้าคนต้องจำ ด่านก็ไม่มีจริง

• low: check ผ่านแล้ว auto-merge
• medium: check ผ่าน + agent-review
• high: ต้องให้ต้นกดเอง

GitHub branch protection มีตัวเลือก “Require pull request reviews before merging”, “Require status checks before merging”, “Require merge queue” และ “Require deployments to succeed before merging” (GitHub Docs)

auto-merge ช่วย “automatically merge changes once all requirements are met”

lauren (@poteto) เล่า ว่า “as of Friday i’ve been automerging my PRs without any review”

แต่ประโยคก่อนหน้าคือ framework ใหม่ที่ “imposes a lot of hard constraints on agents and makes the easy path the best path”

เธอไม่ได้ปิดด่าน เธอย้ายด่านไปอยู่ในเครื่อง

กับเกมที่เธอทำเป็น side project เธอ ตอบ ว่า “did not use CI at all. just got my agents to run the checks before merging.”

ส่วนแอปที่ทำงาน เธอ เล่า ว่ามี verification skills และ “grok bot desktop’s CI is quite optimized and runs in about 5 minutes”

ต้นมีลูกค้าจ่ายเงินแล้ว เลยเลือก CI เพราะเป็นแบบที่ไม่มีใครข้ามได้ รวมถึง agent

หลัก 2: ทำคนเดียว แยกหน้าที่ยังไง#

ด่านที่เจ้าของข้ามได้ตามใจ ก็เป็นด่านที่คนต้องจำเหมือนกัน

NIST อธิบาย separation of duty ว่า “refers to the principle that no user should be given enough privileges to misuse the system on their own”

ต้นทำคนเดียว เลยแยกแบบนี้

ผู้เขียนคือ agent ที่มี identity ของตัวเองจากตอน 5 ผู้อนุมัติคือต้น

งาน high ต้องพัก 30 นาทีก่อนกด และต้องติ๊ก checklist (ตัวอย่าง)

GitHub เขียนไว้ว่า “By default, the restrictions of a branch protection rule don’t apply to people with admin permissions” และ “You can optionally apply the restrictions to administrators”

ต้นเปิดข้อนี้ให้ตัวเอง

พูดตรงๆ ผมยังไม่เจอแหล่งไหนบอกว่าผู้ตรวจยอมรับการอนุมัติตัวเองของคนทำคนเดียว

นี่คือ control ไม่ใช่ peer review ถ้าวันหนึ่งจะทำ SOC 2 ให้หาคนที่สองมา review

หลัก 3: ทางฉุกเฉินที่เขียนไว้ก่อน#

ทางลัดตอนตีสามที่ไม่ได้เขียนไว้ ก็คือด่านที่อยู่ในหัวอีกแบบ

บทความบน dev.to เขียนว่า “A documented emergency change procedure with post-hoc review is an entirely acceptable control. An undocumented one that three engineers know about is a finding.”

และสั้นกว่านั้น “Write the emergency path down.”

ทางฉุกเฉินของต้น 5 ช่อง (ตัวอย่าง)

• ใครข้ามได้: ต้นคนเดียว
• ข้ามยังไง: label hotfix ยังรัน check แต่ไม่ต้องรอพัก
• บันทึกที่ไหน: comment ใน ticket
• ทบทวนภายใน: 24 ชั่วโมง
• ใครทบทวน: ต้น กับ agent-review

หลัก 4: release เล็ก ถอยได้ด้วยปุ่มเดียว#

ครึ่งหลังของหัวใจ ของที่ปล่อยออกไปต้องถอยได้ และทางถอยต้องมีก่อนวันที่ต้องใช้

DORA อธิบาย continuous delivery ว่า “is the ability to release changes of all kinds on demand quickly, safely, and sustainably”

งานชิ้นเล็ก “lets you course correct or revisit assumptions”

Google SRE อยากให้ build ออกมา “in a reproducible, automated way so that releases are repeatable and aren’t “unique snowflakes.””

feature flag ก็ช่วย Martin Fowler เขียน ว่า “Release Toggles allow incomplete and un-tested codepaths to be shipped to production as latent code which may never be turned on”

ถอยของต้นมีสองปุ่ม deploy build ก่อนหน้าซ้ำ หรือปิด flag

หลัก 5: schema ต้องถอยได้#

ข้อมูลคือของที่ถอยยากที่สุด ถ้าไม่วางทางถอยไว้ตั้งแต่ migration แรก หัวใจข้อนี้ก็พัง

Fowler เรียกท่านี้ว่า parallel change “also known as expand and contract” โดย “breaking the change into three distinct phases: expand, migrate, and contract”

DORA บอกว่าทีมที่ทำได้ดี “store their database changes as scripts in version control and manage these changes in the same way they manage production application changes”

กฎของต้น

• migration เป็น high เสมอ
• ห้าม add กับ drop ใน release เดียว
• test กับสำเนาข้อมูลที่หน้าตาเหมือนของจริง
• preview ห้ามใช้ database เดียวกับ production บทเรียนจาก Lemkin ตรงๆ

ตารางด่านของต้นหน้าตาเป็นยังไง?#

ตารางด่าน (ตัวอย่าง)

สูตรถอย 3 บรรทัด

• code: deploy build ก่อนหน้า หรือ revert PR
• schema: expand → migrate → contract ไม่ drop ใน release เดียว
• flag: ปิด feature flag

ticket #57 เล่นใหม่ migration แยกเป็น 3 PR ใน 2 วัน และ drop amount หลังไม่มีใครอ่านมาหนึ่งสัปดาห์ (ตัวอย่าง)

มาตรฐานว่ายังไง

ISO/IEC TR 29110-5-1-2 (ฉบับปี 2011) เขียนว่า Software Implementation ครอบคลุม “software construction, software integration and test, and product delivery activities”

12207 มี Implementation, Integration, Verification และ Transition อยู่ในกลุ่ม Technical processes

SOC 2 หมวด change management ในทางปฏิบัติ คู่มือ SOC 2 readiness เขียนว่า “The approval itself, recorded in the tool, is the evidence.”

ข้อนี้ผมเทียบเอง ประชุม CAB ของบริษัทใหญ่ ก็คือด่านตามระดับกับเวลาพักของต้น ที่บันทึกเองอัตโนมัติ

จิ๊กซอว์ชิ้นที่เติมแล้ว#

ชิ้นที่ 6 ด่านและทางถอย เติมแล้ว

ระดับมีฟัน และทุก release มีทางกลับ

ชิ้นถัดไปคือ code ที่ไม่เน่าเมื่อมี repo มากกว่าหนึ่ง

สิ่งที่ผมได้จากตอนนี้#

ตอนต่อไป#

ต้นเริ่มแอปตัวที่สองให้มิว

repo ใหม่ไม่มีด่านสักตัว และ agent ของมันเขียนลง database ที่ใช้ร่วมกันตรงๆ

ตอนหน้า ทุก repo ใหม่จะเกิดมาพร้อมกฎ ด่าน และทางถอยชุดเดียวกัน และข้อมูลแต่ละชุดจะมีเจ้าของ repo เดียว

คำถามที่พบบ่อย#

auto-merge อันตรายไหม?

ใช้กับ low เท่านั้น ระดับมาจากกฎ path และ check ต้องผ่านก่อนเสมอ

rollback database ได้ไหม?

ส่วนใหญ่ไม่ได้ เลยออกแบบให้เดินหน้าอย่างเดียวด้วย expand/contract

ข้ามด่านได้ไหม?

ได้ทางเดียว คือทางฉุกเฉินที่เขียนไว้ และต้องทบทวนใน 24 ชั่วโมง

ทำคนเดียว อนุมัติตัวเองนับไหม?

นับเป็น control แต่ไม่ใช่ peer review บอกตรงๆ แบบนั้น และหาคนที่สองก่อนทำ SOC 2

Next → ภาค 2 ตอนที่ 8: codebase ที่ไม่เน่า