ทำไมจึงต้องใช้ระบบการสร้าง

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

ระบบบิลด์คืออะไร

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

ฉันใช้แค่คอมไพเลอร์ไม่ได้ใช่ไหม

ความจำเป็นในการใช้ระบบบิลด์อาจยังไม่ชัดเจนในทันที วิศวกรส่วนใหญ่ไม่ใช้ระบบบิลด์ขณะเรียนรู้การเขียนโค้ด โดยส่วนใหญ่จะเริ่มจากการเรียกใช้เครื่องมือ เช่น gcc หรือ javac จากบรรทัดคำสั่งโดยตรง หรือเทียบเท่าในสภาพแวดล้อมการพัฒนาที่ผสานรวม (IDE) ตราบใดที่ซอร์สโค้ดทั้งหมดอยู่ในไดเรกทอรีเดียวกัน คำสั่งนี้ก็ใช้ได้ดี

javac *.java

วิธีนี้จะสั่งให้คอมไพเลอร์ Java นำไฟล์ต้นฉบับ Java ทุกไฟล์ในไดเรกทอรีปัจจุบันมาแปลงเป็นไฟล์คลาสไบนารี ในกรณีที่ง่ายที่สุด สิ่งที่คุณต้องทำมีเท่านี้

อย่างไรก็ตาม ทันทีที่โค้ดขยายออก ข้อมูลแทรกจะเริ่มต้นขึ้น javac ฉลาดพอที่จะมองหาโค้ดที่จะนําเข้าในไดเรกทอรีย่อยของไดเรกทอรีปัจจุบัน แต่ไม่มีทางที่จะค้นหาโค้ดที่จัดเก็บไว้ในส่วนอื่นๆ ของระบบไฟล์ได้ (อาจเป็นไลบรารีที่แชร์กันจากหลายโปรเจ็กต์) และทราบวิธีสร้างโค้ด Java เท่านั้น ระบบขนาดใหญ่มักประกอบด้วยส่วนต่างๆ ที่เขียนด้วยภาษาโปรแกรมต่างๆ ที่มีเครือข่ายของข้อกําหนดซึ่งกันและกัน ซึ่งหมายความว่าไม่มีคอมไพเลอร์สําหรับภาษาเดียวที่จะสร้างทั้งระบบได้

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

นอกจากนี้ คอมไพเลอร์ยังไม่ทราบวิธีจัดการกับข้อกําหนดภายนอก เช่น ไฟล์ JAR ของบุคคลที่สามใน Java หากไม่มีระบบบิลด์ คุณสามารถจัดการการทำงานนี้ได้โดยดาวน์โหลดทรัพยากร Dependency จากอินเทอร์เน็ต ใส่ไว้ในโฟลเดอร์ lib บนฮาร์ดไดรฟ์ และกำหนดค่าคอมไพเลอร์ให้อ่านไลบรารีจากไดเรกทอรีนั้น เมื่อเวลาผ่านไป การบำรุงรักษาการอัปเดต เวอร์ชัน และแหล่งที่มาของทรัพยากร Dependency ภายนอกเหล่านี้ก็เป็นเรื่องยาก

แล้วสคริปต์ Shell ล่ะ

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

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

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

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

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

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

• คุณตัดสินใจว่าจะทำให้ระบบบิลด์ทำงานอัตโนมัติ ในทางทฤษฎี วิธีการนี้ทำได้ง่ายๆ เพียงแค่ซื้อคอมพิวเตอร์เครื่องใหม่และตั้งค่าเพื่อเรียกใช้สคริปต์บิลด์ของคุณทุกคืนโดยใช้ cron คุณยังคงต้องผ่านกระบวนการตั้งค่าที่ยุ่งยาก แต่ตอนนี้คุณไม่มีสมองของมนุษย์ที่ตรวจหาและแก้ไขปัญหาเล็กๆ น้อยๆ ได้ ทีนี้ ทุกเช้าเมื่อเข้าไปในระบบ คุณเห็นว่าการสร้างเมื่อคืนล้มเหลวเพราะเมื่อวานนักพัฒนาซอฟต์แวร์ได้ทำการเปลี่ยนแปลงที่ใช้กับระบบ แต่ใช้งานไม่ได้ในระบบบิลด์อัตโนมัติ แต่ละครั้งปัญหานี้แก้ไขได้ง่ายๆ แต่เกิดขึ้นบ่อยมากจนคุณอาจต้องเสียเวลาในแต่ละวันไปกับการค้นหาและนำวิธีแก้ปัญหาง่ายๆ เหล่านี้ไปใช้

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

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