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

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

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

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

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

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

javac *.java

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

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

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

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

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

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

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

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

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

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

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

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

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

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