การสร้างรายวันสำคัญอย่างไร [ปิด]

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

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

เป้าหมายคือการหาเวลาที่สิ่งก่อสร้างแตกก่อนขั้นตอนการทดสอบขั้นสุดท้ายเพื่อค้นหาพวกเขาโดยเร็วที่สุด

เพียงตั้งค่าเพื่อสร้างสาขาการพัฒนาหลักของคุณ

เราใช้มันในที่ทำงาน (แม้ว่าเราจะสร้างรายชั่วโมง) และบ่อยครั้งที่เราลืมที่จะติดตั้งเราพบปัญหาเกี่ยวกับเพียงไม่กี่ชั่วโมงก่อนที่จะปล่อย

ต้องการเพิ่มบิตในส่วนนี้ (และ @GoodEnoughs):

แต่ดูเหมือนว่าจะเป็นความรำคาญเล็กน้อยสำหรับการควบคุมเวอร์ชันแบบกระจาย

ไม่ต้องกังวล - บิลด์ของ "เซิร์ฟเวอร์" จะบอกคุณว่าลำตัวของคุณจะสร้างและผ่านการทดสอบมากหรือน้อยจากการทำความสะอาด (น้อยกว่าคือจำนวนของการกำหนดค่าที่คุณต้องทำในสภาพแวดล้อมของคุณ)

ฉันใคร่ครวญสวิตช์ไปที่ DVCS แต่ถึงแม้จะทำเสร็จแล้วคุณจะลากการรวมอย่างต่อเนื่องของฉันจากมือที่ตายแล้วของฉัน

ยกตัวอย่างง่ายๆ - คุณกำลังพัฒนาฟีเจอร์ "a" เขากำลังพัฒนาฟีเจอร์ "b" แจกจ่ายหรือไม่ในบางจุดคุณต้องต่อมันเข้าด้วยกัน - ถ้าคุณยอมรับคุณลืมเพิ่มไฟล์ที่แอปจะสร้าง บนเครื่องของคุณ แต่จะไม่อยู่ที่อื่น ดังนั้นเมื่อคุณผลักดันการสร้างไปที่ "ลำตัว" ของคุณการรวมอย่างต่อเนื่องจะทำให้เกิดขึ้นและการสร้างจะล้มเหลวและคุณจะรู้และหวังว่าก่อนที่จะมีใครดึงรหัสที่ไม่สมบูรณ์ดังนั้นคุณจะสามารถทำตามขั้นตอนได้

หากคุณกำลังทำงานในโครงการที่มีนักพัฒนาหลายคนคุณจะต้องสามารถกำหนดได้ว่ารุ่นวางจำหน่ายมาจากไหน - มีผลบังคับใช้ - สิ่งนี้เกิดขึ้นจริงไม่ว่าการควบคุมเวอร์ชันของคุณจะทำงานอย่างไร

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

นั่นเป็นสิ่งที่ค่อนข้างแข็งแกร่งหรือไม่? ไม่ทราบ - แต่เซิร์ฟเวอร์การสร้างของฉันเป็นหนึ่งในสิ่งเหล่านั้นที่ฉันมีฉันไม่ต้องการคืน

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

ในสมัยของระบบควบคุมแหล่งกลางฉันจะสนับสนุนการสร้างอย่างต่อเนื่องที่ทำงานทุก ๆ 5-10 นาทีเมื่อมีการเปลี่ยนแปลงอะไรในซอร์สโค้ด เนื่องจากข้อผิดพลาดในการคอมไพล์มีศักยภาพในการชะลอทีมส่วนใหญ่ สำหรับองค์กรที่ใช้ระบบควบคุมแหล่งจ่ายแบบกระจายการสร้างอย่างต่อเนื่องอาจไม่จำเป็นมากนักเนื่องจากผู้พัฒนาแตะที่รหัสฐาน 'ดั้งเดิม' น้อยกว่าโดยตรง

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

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

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

งานสร้างรายวันไม่เป็นไร คุณต้องการพวกเขาอย่างแน่นอนหากคุณไม่มีอะไรอื่นนอกจากพูดตามตรงฉันคิดว่าการทดสอบของ Joel นั้นล้าสมัยไปแล้วเล็กน้อย

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

หากเวลาในการสร้างหรือการใช้งานมากเกินไปให้พิจารณายกเลิกการเลือกปัญหาเหล่านี้กับดิสก์ทางกายภาพหรือซอฟต์แวร์ ram, การเชื่อมต่ออินเทอร์เน็ตที่เร็วขึ้น, การสร้างการเทียบเคียงกัน ฯลฯ เวลาที่คุณจะประหยัดโดยการระบุตัวแบ่งการสร้างอย่างรวดเร็ว .

งานสร้างรายวันไม่สำคัญ งานสร้างรายวันที่ประสบความสำเร็จอยู่เสมอคือ (หรือสิ่งที่มันเสียเพียงหนึ่งชั่วโมง) การมี CI เมื่องานสร้างเสียหาย 70% ของเวลานั้นไม่มีประโยชน์มากนักเพราะถ้าสิ่งที่ใช้งานไม่ได้ส่วนใหญ่จะไม่ช่วยให้คุณระบุข้อผิดพลาดได้

ฉันคิดว่ามันควรจะสร้างทุกวันทดสอบและปรับใช้กับเซิร์ฟเวอร์การแสดงละคร

แนวคิดเบื้องหลัง 'การสร้างรายวัน' คือการมีสิ่งที่พร้อมเสมอซึ่งผู้ทดสอบและผู้จัดการโครงการสามารถทำงานได้เพื่อให้ทุกคนมีความคิดเกี่ยวกับสถานะที่แท้จริงของโครงการ

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