10Environments & การ Deploy

"production" ไม่ใช่ที่เดียวที่โค้ดไป โค้ดเดินผ่านหลายสภาพแวดล้อม (environment) ก่อนถึงผู้ใช้จริง บทนี้คือวิธีจัดสภาพแวดล้อมเหล่านั้นให้เป็นทางเดินที่มีด่านป้องกัน

10.1 บันไดของ environment

• dev / preview — deploy อัตโนมัติทุก branch/PR ไว้ลองของ พังได้ ไม่กระทบใคร
• staging — ตั้งให้เหมือน production มากที่สุด (ข้อมูล โครงสร้าง การตั้งค่าใกล้เคียง) เพื่อจับปัญหาที่จะเกิดบนจริง ก่อนมันเกิดจริง
• production — ของจริง มีด่านป้องกันแน่นหนาที่สุด

10.2 Environment protection — ด่านก่อน production

แพลตฟอร์มให้ผูกกฎป้องกันกับแต่ละ environment สิ่งเหล่านี้คือ "ประตูอนุมัติ" จากบทที่ 9 ในรูปธรรม:

• required reviewers — ต้องมีคนที่กำหนดกดอนุมัติ ก่อน job ที่ deploy เข้า prod จะเริ่มทำงาน
• wait timer — หน่วงเวลาก่อน deploy ให้มีช่วงยกเลิกได้ทัน
• branch restriction — เฉพาะ main (หรือ tag ที่กำหนด) เท่านั้นที่ deploy เข้า prod ได้
• scoped secrets — secret ของ prod ผูกกับ environment นี้ pipeline จาก branch อื่นแตะไม่ได้

jobs:
  deploy-prod:
    needs: build
    runs-on: ubuntu-latest
    environment: production      # ผูกกับ environment "production" — กฎป้องกันมีผลทันที
    steps:
      - uses: actions/download-artifact@v4
        with: {name: dist}
      - run: ./deploy.sh production
        env:
          DEPLOY_KEY: ${{ secrets.PROD_DEPLOY_KEY }}

เมื่อ job นี้ผูก environment: production ที่มี required reviewer แล้ว มันจะ หยุดรอ ที่หน้า Actions จนกว่าจะมีคนกดอนุมัติ — นี่แหละคือ "ปุ่มที่มนุษย์กด" ในบทที่ 9 ที่ทำงานจริง

🧭 ทำไม staging ต้องเหมือน prod — บั๊กที่แพงที่สุดคือบั๊กที่ "โผล่เฉพาะบน prod" — มักเกิดเพราะ staging ต่างจาก prod (เวอร์ชัน, ข้อมูล, ตัวแปร) ยิ่ง staging เหมือน prod เท่าไร โอกาสที่ prod จะเซอร์ไพรส์ยิ่งน้อยลงเท่านั้น ลงทุนทำ staging ให้เหมือนคุ้มเสมอ

✅ สรุปบทที่ 10 — โค้ดไต่บันได dev → staging → production · staging ตั้งให้เหมือน prod เพื่อจับบั๊กก่อนถึงผู้ใช้ · ผูก job กับ environment: เพื่อเปิดกฎป้องกัน: required reviewer, wait timer, branch restriction, scoped secret · job ที่ผูก environment ที่ต้องอนุมัติจะหยุดรอคนกด — ปุ่มของบทที่ 9 ในทางปฏิบัติ