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

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

ระบบการสร้างคืออะไร

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

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

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

javac *.java

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

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

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

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

สคริปต์ Shell จะเป็นอย่างไร

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

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

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

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

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

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

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

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

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