เกี่ยวกับเรา
ที่ 1C เราไม่เพียงพัฒนาแพลตฟอร์มเท่านั้น
การเข้า
เรามักใช้ maven เป็นระบบ build สำหรับแอปพลิเคชัน Java และในบทความสั้น ๆ นี้ เราอยากจะพูดถึงหนึ่งในปัญหาที่เราต้องเผชิญในกระบวนการจัดระเบียบการพัฒนา และเกี่ยวกับแนวทางที่ช่วยให้เราเอาชนะสิ่งนี้ได้ ปัญหา.
ข้อกำหนดเบื้องต้นและขั้นตอนการทำงาน
เนื่องจากการพัฒนาเฉพาะในโปรเจ็กต์ Maven ของเรา เราจึงใช้โมดูล การขึ้นต่อกัน และโปรเจ็กต์ย่อยค่อนข้างมาก จำนวนไฟล์ pom ในหนึ่งทรีสามารถมีได้เป็นสิบหรือหลายร้อยก็ได้
ดูเหมือนว่า: ไม่ใช่เรื่องใหญ่ พวกเขาสร้างมันขึ้นมาครั้งเดียวและลืมมันไป หากคุณต้องการเปลี่ยนแปลงหรือเพิ่มบางสิ่งในไฟล์ทั้งหมดในคราวเดียว มีเครื่องมืออำนวยความสะดวกมากมายในตัวแก้ไขและ IDE การเปลี่ยนแปลงปกติของ pom.xml ที่พบบ่อยที่สุดคืออะไร? เราเชื่อว่าการเปลี่ยนแปลงในเวอร์ชันโครงการและการขึ้นต่อกัน บางทีบางคนอาจต้องการโต้แย้งเรื่องนี้ แต่นี่คือสถานการณ์ของเราอย่างแน่นอน เหตุผลก็คือว่า เรากำลังพัฒนาไลบรารี่ของเราเองจำนวนมากไปพร้อมๆ กันกับเคอร์เนล และเพื่อให้ผลลัพธ์การสร้างและการทดสอบทำซ้ำได้อย่างต่อเนื่อง การใช้สแน็ปช็อตดูเหมือนจะไม่ใช่แนวทางที่สะดวกสำหรับเรา ด้วยเหตุนี้ จึงจำเป็นต้องเพิ่มหมายเลขเวอร์ชันในโปรเจ็กต์ในแต่ละบิลด์
นอกจากนี้ ในบางครั้ง นักพัฒนาจำเป็นต้องสร้างสาขาของไลบรารีของตนเอง และตรวจสอบฟังก์ชันการทำงานเทียบกับการขึ้นต่อกันทั้งหมด ซึ่งเขาจะต้องเปลี่ยนเวอร์ชันของไลบรารีทั้งหมดด้วยตนเอง
วิธีแก้ปัญหาเบื้องต้น
ด้วยการเปลี่ยนแปลงเวอร์ชันบ่อยครั้งและหลายเวอร์ชัน ฉันจึงต้องการลดความซับซ้อนและทำให้กระบวนการภายใน CI เป็นอัตโนมัติ นี่คือจุดที่ปลั๊กอินที่สะดวกและเป็นที่รู้จักมาช่วยเหลือ รุ่น -maven-plugin - เชื่อมต่อและเปิดใช้งาน
mvn -N เวอร์ชัน:set -DnewVersion=2.0.1
และ Maven จะทำทุกอย่างเท่าที่ควร: มันจะวิ่งผ่านลำดับชั้นจากบนลงล่างแทนที่ทุกเวอร์ชัน - สวยงาม! ตอนนี้สิ่งที่เหลืออยู่คือส่งคำขอดึง เพื่อนร่วมงานจะตรวจสอบการเปลี่ยนแปลง และคุณสามารถเข้าร่วม Trunk ได้อย่างรวดเร็ว อย่างรวดเร็ว? ไม่ว่ามันจะเป็นอย่างไร สองสามร้อย pom.xml เพื่อตรวจสอบและไม่นับโค้ด นอกจากนี้ไม่มีใครปลอดภัยจากข้อขัดแย้งในการผสานกับไฟล์ที่เปลี่ยนแปลงจำนวนมากเช่นนี้ ควรสังเกตว่าในกระบวนการ CI การเปลี่ยนแปลงเวอร์ชันจะเกิดขึ้นโดยอัตโนมัติพร้อมกับการเปลี่ยนแปลงฟังก์ชันการทำงาน และไม่แยกจากกัน
คุณสมบัติใหม่
เราก็สงบสติอารมณ์ได้สักพักหนึ่งและเมื่อลาออกไปแล้วเราก็ใช้ชีวิตแบบนั้นจนกระทั่งผู้ชายจาก
mvn -Drevision=2.0.0 ล้างแพ็คเกจ
ค่าคุณสมบัติของระบบมีความสำคัญมากกว่าค่าที่กำหนดไว้คุณสมบัติ>.
พ่อแม่
4.0.0
org.apache
อาปาเช่
18
org.apache.maven.ci
ci-ผู้ปกครอง
เป็นมิตรกับ CI ครั้งแรก
${revision}${sha1}${changelist}
...
1.3.1
-สแน็ปช็อต
ลูกหลาน
4.0.0
org.apache.maven.ci
ci-ผู้ปกครอง
${revision}${sha1}${changelist}
org.apache.maven.ci
Ci-เด็ก
...
หากคุณต้องการสร้างเวอร์ชัน 2.0.0-SNAPSHOT ให้ใช้เลย
mvn -Drevision=2.0.0 ล้างแพ็คเกจ
หากคุณต้องการเผยแพร่ เพียงรีเซ็ต SNAPSHOT
mvn -Dchangelist= แพ็คเกจที่สะอาด
*ตัวอย่างข้างต้นนำมาจาก
ความเป็นจริงที่รุนแรง
ทุกอย่างจะดีและดีต่อสุขภาพ ถึงเวลาที่จะรู้สึกพึงพอใจ แต่ไม่ใช่ ปรากฎว่าวิธีนี้ใช้ไม่ได้กับการติดตั้งและปรับใช้ เนื่องจากจะไม่ถูกแทนที่ในคำอธิบายของสิ่งประดิษฐ์ที่เผยแพร่ในพื้นที่เก็บข้อมูล ${แก้ไข} เกี่ยวกับความหมายของมัน และมาเวนจะไม่เข้าใจอีกต่อไปว่ามันเกี่ยวกับอะไร
org.apache
อาปาเช่
${แก้ไข}
แสงสว่างที่ปลายอุโมงค์
เราจำเป็นต้องมองหาวิธีแก้ไขปัญหา สามารถกอบกู้สถานการณ์ได้
การเพิ่มปลั๊กอินให้กับโครงการ
org.codehaus.mojo
แผ่ปลั๊กอิน maven
1.1.0
จริง
แก้ไข CiFriendliesOnly
เรียบ
ทรัพยากรกระบวนการ
เรียบ
เรียบ.สะอาด
ทำความสะอาด
ทำความสะอาด
Done!
จบด้วยดี
จากนี้ไป เพื่อที่จะเปลี่ยนเวอร์ชันของโปรเจ็กต์ทั้งหมดและแจ้งให้ผู้อ้างอิงทั้งหมดทราบ เราเพียงแค่ต้องแก้ไของค์ประกอบการแก้ไข> เฉพาะรากเท่านั้น pom.xml. มีไฟล์เหล่านี้ไม่ถึงร้อยหรือสองไฟล์ที่มีการเปลี่ยนแปลงแบบเดียวกันที่มาถึงการตรวจสอบ แต่มีเพียงหนึ่งไฟล์ ก็ไม่ต้องใช้หรอก รุ่น -maven-plugin.
ที่มา: will.com