ความรับผิดชอบของ Build Script และ Build Server

ฉันต้องการคำชี้แจงเกี่ยวกับความรับผิดชอบของ Build Script และ Build Server

ฉันอ่านบทความหลายเรื่องบนอินเทอร์เน็ตเกี่ยวกับการรวมและสร้าง รวมไปถึง

• รหัส F5 ไม่ใช่กระบวนการสร้าง
• The Build Server: Heart Monitor ของโครงการของคุณ
• งานสร้างรายวันเป็นเพื่อนของคุณ

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

ตามที่ฉันเข้าใจจากการวิจัยของฉัน (และโปรดแก้ไขให้ฉันที่นี่ด้วยเนื่องจากเป็นสิ่งที่ฉันถาม) อุดมคติควรเป็นดังนี้:

• ทุกโครงการมีสคริปต์การสร้าง
• สคริปต์นี้สร้างโครงการ
• สคริปต์นี้ทำให้แน่ใจว่ามีการสร้างการอ้างอิงก่อนหน้านี้

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

อย่างไรก็ตามความรับผิดชอบของ Build Server คือ:

• ตรวจสอบพื้นที่เก็บข้อมูล
• ทริกเกอร์การสร้าง
• การทดสอบทริกเกอร์และเครื่องมือ QA อื่น ๆ
• ทำให้สิ่งประดิษฐ์พร้อมใช้งาน

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

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

คุณช่วยอธิบายวัตถุประสงค์และอธิบายความรับผิดชอบให้ชัดเจนขึ้นได้ไหม?

สิ่งเหล่านี้เป็นมุมฉาก:

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

สคริปต์การสร้างเป็นเพียงสคริปต์เดียวที่อาจมีจำนวนมาก - เช็คเอาท์, สร้าง, ทดสอบ, แพ็คเกจ - แต่คุณสามารถมีกลไกแบบ all-in-one ที่ควบคุมโดย params บรรทัดคำสั่ง - มันขึ้นอยู่กับสภาพแวดล้อมของคุณ

เซิร์ฟเวอร์การสร้างหรือเซิร์ฟเวอร์รวมอย่างต่อเนื่องมากกว่าเป็นกลไกอัตโนมัติที่รับผิดชอบในการกำหนดเวลา / เรียกการตรวจสอบและการรายงานการชำระเงิน -> สร้าง -> ทดสอบ -> แพคเกจ -> เวที -> ปรับใช้ไปป์ไลน์ คุณสามารถใช้ cron / Task Scheduler หากคุณไม่มีอะไรซับซ้อนกว่ามือ แต่ตอนนี้มีเครื่องมือที่ยอดเยี่ยมมากมายเช่น Jenkins, Cruise Control, TeamCity เป็นต้น

เป็นสิ่งสำคัญที่คุณสามารถเรียกใช้บิลด์ได้โดยไม่ต้องใช้เซิร์ฟเวอร์ CI ในกรณีที่ไม่ว่าง / ออฟไลน์ / ไม่สามารถเข้าถึง / ไม่สามารถใช้งานได้ดังนั้นตรรกะในการรับบิลด์ / ทดสอบ / สิ่งที่ต้องทำนั้นต้องอยู่ด้านนอก ระบบ CI แต่สามารถเรียกใช้งานได้โดยพารามิเตอร์จาก Branch / build type / version / architecture ฯลฯ