ในช่วงเวลาหลายปีของการเขียนโปรแกรม Java และ Scala เมื่อเร็ว ๆ นี้ฉันไม่เคยใช้ Ant, Maven, Gradle หรือเครื่องมือสร้างเหล่านี้สำหรับ Java ทุกที่ที่ฉันทำงานมีผู้จัดการสร้างที่ดูแลทุกอย่าง - ฉันรวบรวมภายในเครื่องด้วย IDE สำหรับการพัฒนาและทดสอบหน่วยจากนั้นตรวจสอบในซอร์สโค้ดและแจ้งผู้จัดการสร้างที่ทำสิ่งที่จำเป็น รวบรวมไฟล์ของทุกคนสำหรับสภาพแวดล้อมที่ใช้ร่วมกัน

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

แต่ตลอดฉันคลิกปุ่มสร้างบน IDE และสร้างไฟล์ Jar และใช้งานได้ดี แน่นอนว่าภูมิปัญญาดั้งเดิมแสดงให้เห็นว่าฉัน "ควร" เขียนสคริปต์ Ant / Maven / Gradle ของตัวเองและใช้สิ่งนั้นแทน IDE แต่อะไรคือข้อดีที่เป็นรูปธรรมในสถานการณ์ของฉัน (ทำงานคนเดียว)?

ฉันได้อ่านเกี่ยวกับวิธีการใช้เครื่องมือสร้างเหล่านั้นและดูเหมือนว่าฉันจะเขียน XML หลายร้อยบรรทัด (หรือ Groovy หรืออะไรก็ตาม) เพื่อทำสิ่งที่ IDE ทำในคลิกเดียว (IDE สร้างขึ้น) Ant XML สำหรับโครงการมีมากกว่า 700 บรรทัด) ดูเหมือนว่าจะเกิดข้อผิดพลาดและใช้เวลานานและไม่จำเป็นสำหรับสถานการณ์ของฉัน ไม่ต้องพูดถึงช่วงการเรียนรู้ซึ่งจะใช้เวลาในการทำงานอื่น ๆ ทั้งหมดที่ฉันทำเพื่อให้ผลิตภัณฑ์พร้อมที่จะแสดงให้ผู้คนเห็น

ฉันขอแนะนำให้คุณดูการใช้ Maven เมื่อเทียบกับ Ant หาก IDE ของคุณสามารถสร้างโครงการของคุณได้ในคลิกเดียวก็เป็นไปได้ว่า Maven สามารถสร้างโครงการของคุณได้โดยไม่มีการกำหนดค่าแบบกำหนดเอง

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

ดังนั้นสิ่งที่ฉันทำเพื่อกำจัด drudgery คู่มือนี้คือฉันกำหนดค่าโครงการของฉันเพื่อสร้างด้วย Maven และฉันกำหนดค่าpom.xmlไฟล์ของฉันด้วยข้อมูลทั้งหมดที่จำเป็นในการ (ในกรณีของ Java web-app) ค้นหาและดาวน์โหลด รุ่นที่ถูกต้องของ Tomcat ติดตั้งภายในเครื่องตั้งค่าไฟล์กำหนดค่า Tomcat ที่ถูกต้องปรับใช้การพึ่งพาโปรเจ็กต์ใด ๆ และไฟล์ WAR โครงการของตัวเองจากนั้นเริ่ม Tomcat จากนั้นฉันจะสร้างเชลล์สคริปต์อย่างง่าย (และ.batเวอร์ชันสำหรับ Windows) ที่ใช้ Maven เพื่อสร้างและเริ่มเซิร์ฟเวอร์:

mvn clean install cargo:start -Dcargo.maven.wait=true

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

./startServer.sh #or startServer.bat for Windows

และเพื่อปรับใช้การปรับปรุงสภาพแวดล้อมการผลิตกระบวนการเป็นเพียง:

1. หยุดการทำงานของอินสแตนซ์เซิร์ฟเวอร์หากมี
2. svn update -r<target_release_revision>วิ่ง
3. ./startServer.shวิ่ง

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

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

และแน่นอนคำตอบสำหรับคำถามของคุณคือการจัดการการพึ่งพาอัตโนมัติ แต่ฉันเชื่อว่าคำตอบอื่น ๆ ได้รับการคุ้มครองแล้ว

ตราบใดที่โค้ดของคุณอยู่ในการควบคุมซอร์สการใช้ IDE เพื่อทำให้การแจกจ่ายของคุณนั้นใช้ได้

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

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

มีค่าใช้จ่ายแน่นอนทำไมมันจะคุ้มค่า

• บิลด์ที่ทำซ้ำได้และไม่เชื่อมโยงกับ IDE (หรือเครื่องของคุณหากคุณเรียกใช้ภายนอก) หากเซิร์ฟเวอร์บิลด์รันมันเครื่องอื่น ๆ ก็สามารถรันได้
• ความสนุกเริ่มต้นหลังจากการสร้างและการทดสอบหน่วย (โดยวิธี: คุณแน่ใจหรือว่าคุณทดสอบก่อนที่จะกระทำทุกครั้ง? สร้างเอกสารสร้างติดตั้งรันเครื่องมือวิเคราะห์รหัสที่คุณโปรดปราน
• เซิร์ฟเวอร์ CI ที่คุณชื่นชอบช่วยให้คุณเห็นกราฟของการครอบคลุมรหัสการทดสอบหน่วยล้มเหลว ฯลฯ เมื่อเวลาผ่านไป IDE ของคุณทำเช่นนั้นหรือไม่?

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

ฉันใช้เวลาในการตั้งค่านี้ (สคริปต์การสร้างอาจเป็น300 บรรทัดตามวิธีที่ไม่ได้สัมผัสเป็นเวลาหลายเดือน) และสามารถพูดได้ว่ามันคุ้มค่าแม้แต่คนเดียว สำหรับบุคคลมากกว่าหนึ่งคนจำเป็นต้องมี การมีส่วนร่วมของฉันในกระบวนการสร้าง / นำไปใช้งานประกอบด้วยคำสั่ง "hg commit" และ "hg push"

ประโยชน์ของการสร้างเครื่องมือ

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

สิ่งอำนวยความสะดวกเหล่านี้ช่วยส่งเสริมวงจรการพัฒนาของคุณและช่วยให้คุณ:

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

ถ้าเราใช้สิ่งนี้กับMaven ...

สำหรับบรรดาของคุณในโลก Java และผู้ที่ใช้Mavenโดยการอ่านสิ่งนี้คุณได้เชื่อมโยงกับแต่ละจุดด้วย:

• การประชุมโครงการที่มีโครงสร้างของ Maven
• Maven Archetypes
• การสร้างโครงการจาก SCM และการสร้างเครื่องปฏิกรณ์
• Jenkins / Hudson / Bamboo / การสนับสนุนอื่น ๆ + การสนับสนุนของ Maven สำหรับการทดสอบการรวมระบบ
• m2eclipse, IntelliJ หรือ NetBeans ดั้งเดิมสนับสนุน - หรือ mvnsh สำหรับบรรทัดคำสั่ง
• รุ่น-Maven ปลั๊กอิน
• maven-release-plugin, buildnumber-maven-plugin ปลั๊กอินและรุ่น -maven-plugin

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

ทุกอย่างที่เกี่ยวข้อง:

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

นี่คือเหตุผล 4 อันดับแรกของฉันในการใช้เครื่องมือสร้าง:

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

ในหนังสือ Pragmatic Programmer , Andrew Hunt และ David Thomas กล่าวว่า 'checkout-build-test-deploy' ควรเป็นคำสั่งเดียว (บทที่: โครงการในทางปฏิบัติ) คุณเขียน..

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

จากนั้นฉันแน่ใจว่าทีมของคุณจะเติบโต .. มันสำคัญยิ่งกว่าที่จะมีความสามารถในการปรับใช้การทดสอบอัตโนมัติ

XML (สคริปต์) ขนาดใหญ่ที่คุณเห็นโดยทั่วไปเป็นงานครั้งเดียว ส่วนใหญ่แล้วสคริปต์เดียวกันนี้สามารถใช้ได้กับหลายโครงการ

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

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

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

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

นอกจากนี้ยังช่วยให้คุณสามารถสร้างงานในสภาพแวดล้อมที่ไม่ใช่ GUI เช่นการส่งไปยังเซิร์ฟเวอร์และช่วยให้คุณสามารถเปลี่ยน IDE ได้โดยไม่ต้องกังวลกับการสูญเสียความสามารถในการสร้างซอฟต์แวร์ของคุณ

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

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

เหตุผลที่ดีที่สุดก็คือมันเป็นสิ่งที่ไม่จำเป็นต้องทำด้วยตนเองดังนั้นอย่าทำด้วยตนเอง ทุกอย่างอื่นตกจากที่