บูรณาการอย่างต่อเนื่อง: ความถี่ใด

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

ก่อนปิดรายละเอียดบางอย่าง:

• โครงการ Objective-C (iOS 5)
• 10 ผู้พัฒนา
• แต่ละบิลด์ใช้เวลาประมาณ 1 นาทีและรวมถึงการสร้างและทดสอบหน่วย
• เซิร์ฟเวอร์การรวมเป็น Mac Mini ดังนั้นพลังการประมวลผลจึงไม่เป็นปัญหาสำหรับที่นี่
  • เราใช้ Jenkins กับปลั๊กอิน XCode

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

ดังนั้นคุณคิดอย่างไรกับเรื่องนี้?

การล้มเหลวอย่างรวดเร็วเป็นหลักการที่ดี - ยิ่งคุณรู้ว่าบิลด์นั้นพังเร็วเท่าไรคุณก็จะสามารถระบุการกระทำผิดได้เร็วขึ้นและสร้างบิลด์

การสร้างทุกการกระทำเป็นสิ่งที่ถูกต้องที่จะทำ

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

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

ไม่มีจุดในการสร้างทุก ๆ 15 นาทีถ้าไม่มีอะไรเปลี่ยนแปลง แต่อย่างเท่าเทียมกันไม่มีข้อเสีย afaik เจนกินส์จะส่งอีเมลเมื่อล้มเหลวแล้วประสบความสำเร็จและไม่ใช่ทุกอย่างในระหว่าง (เช่น 10 ล้มเหลว)

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

คุณคาดว่า 10 dev ของคุณจะทำมากกว่าหนึ่งครั้งทุกๆสิบห้านาที? ดูเหมือนจะเป็นการประมาณที่ค่อนข้างสูง 10 dev หมายถึงว่าหลังจากทุก ๆ 150 นาทีคนคนเดียวกันก็จะทำอีกครั้ง ดังนั้นในวันเฉลี่ยของคุณ dev แต่ละคนจะทำ 3 ครั้ง โดยส่วนตัวแล้วฉันจะทำอย่างใดอย่างหนึ่ง ~ 2 วัน ... บางครั้งก็ยิ่งน้อยลง

มันจะส่งจดหมายถึงผู้พัฒนามากขึ้นถ้าหากทุกๆ 15 นาทีเท่านั้น นั่นเป็นเพราะมันจะไม่ทราบสำหรับผู้ที่ทำลายการสร้างและทำให้ผู้คนจำนวนมากขึ้น

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

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

แต่ฉันยอมรับว่ามันไม่มีเหตุผลที่จะสร้างหากไม่มีอะไรเปลี่ยนแปลง

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

สำหรับกรณีนี้อาจเป็นความคิดที่ดีที่จะปล่อยให้เซิร์ฟเวอร์ CI ของคุณรอสักครู่หลังจากการคอมมิทครั้งล่าสุดก่อนเริ่มสร้างบิลด์ใหม่ แต่ดูเหมือนว่า 15 นาทีจะเป็นตัวเลขที่สูงมาก 5 นาทีหรือน้อยกว่านั้นน่าจะเพียงพอ

หรือดีกว่า (!) พยายามที่จะแนะนำ devs ของคุณให้ทำงานเฉพาะในส่วนเล็ก ๆ เท่านั้นในเวลาเดียวทำให้ง่ายขึ้นที่จะทำเพียงคอมมิชชันที่ "ใช้งานได้จริง" จากนั้นงานสร้างหลังจากการกระทำทุกอย่างดูเหมือนจะไม่เป็นผล

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

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

หากคุณมีงาน Jenkins ของคุณตั้งค่าให้ทำงานใน Deploys Artifact Deploys (และถ้าคุณทำ ... Bravo) คุณสามารถ prob ขวานสร้างตามกำหนดถ้าหน่วยทดสอบของคุณมั่นคง (หมายถึงพวกเขาไม่ทดสอบการพึ่งพา) และ การทดสอบบูรณาการ / การทำงานไม่ได้เป็นส่วนหนึ่งของงานเจนกินส์

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

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

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

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