เร็ว vs. ปลอดภัย: การถกเถียงครั้งใหญ่เรื่องการ Deploy งานจุดประเด็นการพูดคุยเกี่ยวกับแนวทางปฏิบัติ DevOps สมัยใหม่

BigGo Editorial Team
เร็ว vs. ปลอดภัย: การถกเถียงครั้งใหญ่เรื่องการ Deploy งานจุดประเด็นการพูดคุยเกี่ยวกับแนวทางปฏิบัติ DevOps สมัยใหม่

การพูดคุยล่าสุดเกี่ยวกับกลยุทธ์การ deploy งานภายใน 10 วินาที ได้จุดประเด็นการถกเถียงอย่างดุเดือดในชุมชนนักพัฒนา โดยชี้ให้เห็นถึงความตึงเครียดระหว่างความเร็วในการ deploy กับความปลอดภัยในแนวทางปฏิบัติ DevOps สมัยใหม่

กรณีที่เน้นความเร็ว

บทความในบล็อกที่สนับสนุนการ deploy แบบเร็วจี๋โดยใช้เครื่องมือพื้นฐานอย่าง bash, rsync และ service managers ได้รับการตอบรับจากนักพัฒนาที่รู้สึกท่วมท้นกับระบบ CI/CD ที่ซับซ้อน หลายคนได้แชร์ประสบการณ์การใช้วิธี deploy แบบรวดเร็วคล้ายๆ กัน โดยผู้ใช้คนหนึ่งกล่าวว่า:

บริษัทของผมก็เคย deploy แบบนี้ 100% เลย เรามีหลายเซิร์ฟเวอร์ ใช้ rsync โค้ดไปยังแต่ละเซิร์ฟเวอร์และรีสตาร์ท IIS ทำงานได้ดี การ deploy ไปยังฟาร์มเซิร์ฟเวอร์ใช้เวลาแค่ 1-2 นาที - notwhereyouare

ข้อกังวลด้านความปลอดภัยและการคัดค้าน

อย่างไรก็ตาม ผู้เชี่ยวชาญด้าน DevOps ที่มีประสบการณ์ได้แสดงความกังวลที่สำคัญเกี่ยวกับวิธีการนี้ หลายคนเน้นย้ำว่าระบบ CI/CD สมัยใหม่มีขึ้นด้วยเหตุผลที่ดี:

  • การจัดการการเชื่อมต่อและการปิดระบบอย่างนุ่มนวล
  • การตรวจสอบและทดสอบโค้ด
  • การบันทึกการตรวจสอบ
  • การควบคุมแบบร่วมมือกัน
  • สภาพแวดล้อมการ deploy ที่สม่ำเสมอ

ดังที่ผู้ใช้ from-nibly กล่าวไว้อย่างกระชับว่า: DevOps คือการใส่ความฝืดในจุดที่ถูกต้อง ไม่ใช่การกำจัดมันออกไปทั้งหมด

ทางสายกลาง

นักพัฒนาหลายคนได้แชร์วิธีการที่สมดุลระหว่างความเร็วและความปลอดภัย ผู้ใช้ 0xbadcafebee ได้อธิบายถึงการทำให้ CI/CD deploy เสร็จภายใน 30 วินาทีผ่านการปรับแต่งต่างๆ เช่น:

  • การนำ artifact กลับมาใช้ใหม่
  • การแคชอย่างชาญฉลาด
  • การใช้ self-hosted runners
  • การทดสอบแบบขนาน
  • การ build container ที่ได้รับการปรับแต่ง

ทางเลือกสมัยใหม่

ในขณะที่บางบริษัทยังคงใช้วิธีการ deploy แบบเรียบง่ายได้อย่างประสบความสำเร็จ บริษัทอื่นๆ ก็พบวิธีปรับแต่งเครื่องมือสมัยใหม่ให้ดีขึ้น ตัวอย่างเช่น การ deploy บน Kubernetes สามารถเร็วขึ้นอย่างมีนัยสำคัญเมื่อตั้งค่าอย่างเหมาะสมด้วยการกำหนด surge settings และการจัดการการยุติ

ต้นทุนที่แท้จริงของความเร็ว

การอภิปรายเผยให้เห็นว่าเวลาในการ deploy ไม่ได้เกี่ยวกับการถ่ายโอนโค้ดและรีสตาร์ทเท่านั้น ดังที่ผู้ใช้ mikeocool ชี้ให้เห็น สิ่งที่ใช้เวลามากที่สุดในการ deploy สมัยใหม่มักจะเป็น:

  1. การ build JavaScript
  2. การรันชุดการทดสอบที่ครอบคลุม

บทสรุป

แม้ว่าการ deploy ที่รวดเร็วดั่งสายฟ้าจะน่าดึงดูดใจ แต่ฉันทามติของชุมชนชี้ให้เห็นว่าจำเป็นต้องมีการตรวจสอบความปลอดภัยและกระบวนการบางระดับสำหรับสภาพแวดล้อมการผลิต กุญแจสำคัญอยู่ที่การหาความสมดุลที่เหมาะสมสำหรับขนาดและความต้องการขององค์กรของคุณ แทนที่จะรับเอาแนวทางใดแนวทางหนึ่งมาใช้โดยทั่วไป

การถกเถียงยังคงพัฒนาต่อไปในขณะที่ทีมต่างๆ มองหาวิธีรักษาความปลอดภัยในการ deploy โดยไม่ต้องสละประสิทธิภาพและความพึงพอใจของนักพัฒนา