เอเจนต์ของคุณไม่ได้ทำระบบพัง แต่เป็นไปป์ไลน์ของคุณต่างหากที่ทำ

เอเจนต์ของคุณไม่ได้ทำให้ระบบ production พัง แต่เป็นไปป์ไลน์ของคุณต่างหากที่ทำ

หลายทีมใช้เอเจนต์ในการเปิด pull request พวกเขาใช้ CI เพื่อตรวจสอบ linting, การทดสอบ (tests) และการ build จากนั้นก็มี scheduled job ที่คอยย้ายโค้ดจาก staging ไปยัง production ซึ่งการตั้งค่าแบบนี้จะนำไปสู่ความล้มเหลวในที่สุด

ปัญหาไม่ใช่เอเจนต์ที่ประสงค์ร้าย แต่ปัญหาคือกระบวนการที่ไม่ดี คุณได้ยุบรวมคำถามสองข้อที่แตกต่างกันให้เหลือเพียงด่านตรวจเดียว:

  • สิ่งนี้ผ่าน CI หรือยัง?
  • สิ่งนี้ปลอดภัยพอที่มนุษย์จะเห็นในตอนนี้หรือไม่?

สองสิ่งนี้ไม่ใช่เรื่องเดียวกัน CI ตรวจสอบว่าโค้ดทำงานได้หรือไม่ แต่มันไม่ได้ตรวจสอบว่าฟีเจอร์นั้นพร้อมสำหรับลูกค้าแล้วหรือยัง

หากไปป์ไลน์ของคุณมองว่า "merged" และ "live" คือสิ่งเดียวกัน แสดงว่าคุณกำลังมีปัญหา คุณได้ก้าวเข้าสู่การทำ continuous deployment โดยที่ไม่ได้ตัดสินใจเลือกมันตั้งแต่แรก

คุณต้องแยกสองเหตุการณ์นี้ออกจากกัน (decouple)

คุณสามารถใช้ feature flags เพื่อทำสิ่งนี้ได้ feature flags ก็เป็นเพียงค่า boolean และคำสั่ง if เท่านั้น คุณไม่จำเป็นต้องใช้เครื่องมือราคาแพงในการเริ่มต้น เพียงแค่ใช้ค่า config ง่ายๆ หรือ environment variable ก็เพียงพอแล้ว

การตั้งค่าของผมทำตามกฎเหล่านี้:

  • PR จะ merge เข้าสู่ main แต่ main ไม่ใช่สิ่งที่รันอยู่บนระบบ live
  • มีขั้นตอนการ release แยกต่างหากเพื่อดัน main ไปยัง production branch
  • ผมต้องสั่งให้ไป (go) อย่างชัดเจน ไม่มีการใช้ cron jobs หรือตัวตั้งเวลา
  • การ release จะรอจนกว่า build จะพร้อมให้บริการ (serve traffic)
  • มีการตรวจสอบอัตโนมัติโดยการเรียกไปยัง key endpoints เพื่อยืนยันว่าเว็บไซต์ทำงานได้
  • มนุษย์จะทำการตรวจสอบการเปลี่ยนแปลงด้วยตัวเองเป็นขั้นตอนสุดท้าย

สิ่งนี้จะสร้าง "ด่านตรวจ" (gate) ขึ้นมา ทั้งมนุษย์ เครื่องจักร และมนุษย์อีกคน จะได้รับโอกาสในการปฏิเสธ (say no) ก่อนที่ผู้ใช้จะเห็นอะไรก็ตาม

หากบั๊กยังหลุดไปถึงผู้ใช้ คุณต้องรีบ revert ให้เร็วที่สุด เพื่อทำเช่นนี้ ให้ใช้รูปแบบ expand and contract สำหรับการทำ database migrations:

  • เพิ่มคอลัมน์ใหม่แบบ nullable
  • ทำ backfill ข้อมูล
  • เขียนข้อมูลลงทั้งคอลัมน์เก่าและคอลัมน์ใหม่
  • อ่านข้อมูลจากคอลัมน์ใหม่
  • ลบคอลัมน์เก่าออกเฉพาะในการ release รอบถัดไปเท่านั้น

หากคุณข้ามขั้นตอนนี้ ปุ่ม revert ของคุณจะไร้ประโยชน์ หากการ migration ลบคอลัมน์ที่โค้ดเก่าจำเป็นต้องใช้ คุณจะไม่สามารถ roll back ได้ และระบบจะพังค้างอยู่อย่างนั้น

เอเจนต์ทำให้ความผิดพลาดเหล่านี้เกิดขึ้นเร็วขึ้น มันช่วยขจัดแรงเสียดทานจากการทำงานด้วยมือ (manual friction) ที่เคยช่วยปกปิดกระบวนการที่แย่ของคุณเอาไว้ วินัยที่คุณละเลยไปนั้นไม่ใช่เรื่องที่เลือกได้ แต่มันแค่ถูกปกปิดไว้ด้วยการที่มนุษย์สังเกตเห็นข้อผิดพลาดก่อนเวลา 5 โมงเย็นของวันศุกร์เท่านั้น

เมื่อคุณเอาคนออกจากลูป (loop) วินัยจะกลายเป็นเรื่องที่หลีกเลี่ยงไม่ได้

Source: https://dev.to/mattstratton/your-agent-didnt-break-prod-your-pipeline-did-4g9o