คุณควรเปลี่ยนมาใช้รุ่นบิลด์เมื่อไหร่

หนึ่งในแนวทางปฏิบัติที่กำหนดไว้ในการจัดส่งอย่างต่อเนื่องของ Jez Humble คือคุณควรสร้างแพ็คเกจหนึ่งและจากนั้นปล่อยให้แต่ละสภาพแวดล้อมที่คุณปรับใช้เพื่อให้การนำไปใช้งานและสิ่งประดิษฐ์ได้รับการทดสอบหลายครั้งก่อนที่จะทำการผลิต

ฉันสนับสนุนแนวคิดนี้อย่างเต็มที่

ในทางกลับกันการสร้างโหมดดีบักที่ให้การติดตามสแต็กกับหมายเลขบรรทัดมีประโยชน์อย่างมากในสภาพแวดล้อมการทดสอบเช่นเดียวกับความสามารถในการดีบักแบบรีโมท แต่คุณต้องการส่งบิลด์ให้กับการผลิต

ดังนั้นสำหรับผู้ที่ปฏิบัติตามหลักการแรกคุณจะสลับจากการดีบั๊กเป็นรีลีสบิลด์ในจุดใด

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

หมายเหตุ: ฉันรู้ว่านี่ใช้ไม่ได้กับภาษาที่แปลความจริงเพราะโดยปกติแล้วคุณสามารถปัดสวิตช์ในการตั้งค่าแทนการทำในเวลาบิลด์

ดังนั้นสำหรับผู้ที่ปฏิบัติตามหลักการแรกคุณจะสลับจากการดีบั๊กเป็นรีลีสบิลด์ในจุดใด

เราสลับ แต่เนิ่นๆเมื่อซอร์สโค้ดมีหมายเลขเวอร์ชันและถูกส่งไปยังคิวการสร้าง Debian เราอยู่ในสถานการณ์ที่โชคดีในการทำซอฟต์แวร์ทางวิทยาศาสตร์ด้วยอินพุตและเอาต์พุตที่ระบุอย่างดีและการโต้ตอบของระบบเพียงเล็กน้อยดังนั้นค่าใช้จ่ายในการทำซ้ำสถานการณ์ข้อผิดพลาดค่อนข้างต่ำ

นี่เป็นคำตอบทั่วไปของฉัน: จุดเปลี่ยนการสร้างขึ้นอยู่กับต้นทุนการทำซ้ำสำหรับข้อผิดพลาดเป็นส่วนใหญ่ หากสิ่งเหล่านี้สูงมากฉันก็จะทำการส่ง debug builds เพื่อทดสอบลูกค้า ในขณะที่มีความเสี่ยงของความล้มเหลวในการสร้างสำหรับการสร้างการผลิตนี้อาจยังถูกกว่าการใช้จ่ายสัปดาห์ในการทำสำเนากรณีทดสอบ

ดังนั้นสำหรับผู้ที่ปฏิบัติตามหลักการแรกคุณจะสลับจากการดีบั๊กเป็นรีลีสบิลด์ในจุดใด

ทันทีที่เราไปที่ QA เราจะเปลี่ยนเป็นรุ่นบิลด์ แต่เมื่อใดก็ตามที่เราสร้างรุ่นวางจำหน่ายกระบวนการสร้างของเราก็จะสร้างรุ่นที่แก้จุดบกพร่องของ dll สิ่งนี้ทำให้เราสามารถดรอป debug dll ลงในสภาพแวดล้อม QA ได้อย่างรวดเร็วและรับข้อมูลเพิ่มเติมหากจำเป็น

ทั้งรุ่นที่วางจำหน่ายและตรวจแก้จุดบกพร่องของ DLLs ถูกสำรองและเก็บรักษาไว้เป็นเวลาหลายปี

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

การปรับใช้นี้ยังคงอยู่ในการผลิตดังนั้นนี่ไม่ใช่โหมด 'ดีบัก' แต่ก็ถือว่าการทดสอบนั้นทำได้ดี

แน่นอนว่าเมื่อปิดโหมดดีบักการดีบักอย่างรวดเร็วของรหัส (ในไซต์) อาจเป็นเรื่องยาก แต่หากรีลีสล้มเหลวการผลิตจะสลับกลับไปสู่รีลีสหลัง

อย่างไรก็ตามเราพยายามรักษาหรือสร้างสภาพแวดล้อมที่เหมือนกันซึ่งสามารถสร้างสภาพแวดล้อมดังกล่าวเพื่อทดสอบอีกครั้ง (ฉันรู้ว่านี่ไม่ใช่เรื่องง่ายที่จะทำ) แต่บางครั้งสิ่งที่เราต้องการคือทำซ้ำธุรกรรม / อินพุต

ประเด็นก็คือไม่ควรปล่อยโหมดการดีบักเท่าที่เคยมีในการผลิต แม้ว่าฉันจะไม่บอกว่านี่เป็นกฎ

อีกสิ่งหนึ่งก็คือการเปิดตัวยังคงถูกเรียกว่ารุ่นทดลองจนกว่าจะได้มีการสร้าง

มีวิธีปฏิบัติอื่น ๆ อีกสองสามอย่างเพื่อให้แน่ใจว่ากระบวนการสร้างตัวเองไม่ผิดพลาด ดูสิ่งนี้: วิธีง่ายๆในการปรับปรุงคุณภาพการเผยแพร่ในสภาพแวดล้อม RAD

เรามีเครื่องผู้พัฒนาของเราตั้งค่าเพื่อสร้างการตรวจแก้จุดบกพร่องสร้าง แต่เมื่อ devs ส่งมอบรหัสแพ็คเกจการปรับใช้จะถูกสร้างขึ้นในสภาพแวดล้อมการรวมอย่างต่อเนื่องของเรา (TeamCity) และที่สร้างขึ้นสำหรับการเปิดตัว ดังนั้นเมื่อใดก็ตามที่เราตัดสินใจที่จะปรับใช้กับ QA เราจะนำแพ็คเกจการปรับใช้ล่าสุดจากเซิร์ฟเวอร์ CI และผลักดันมันออกมาดังนั้นจึงมักจะเปิดตัวเว้นแต่จะอยู่ในเครื่อง dev

BTW สำหรับบางภาษาแม้เมื่อสร้างเพื่อวางจำหน่ายคุณยังสามารถสร้างสัญลักษณ์แก้ปัญหาได้ ตัวอย่างเช่นใน. NET มีการตั้งค่า "pdb-only" ซึ่งอนุญาตการปรับให้เหมาะสม แต่ยังคงสร้างไฟล์ดีบั๊ก เห็นได้ชัดว่าการดีบั๊กรุ่นที่ใช้กับการวางตลาดนั้นมีความซับซ้อนกว่าเพราะมันไม่ได้เทียบเคียงกับสายการผลิต แต่มันก็ยังมีประโยชน์ในการเหน็บแนม