ฉันจะสร้างกรณีสำหรับ "การจัดการการพึ่งพา" ได้อย่างไร

9

ขณะนี้ฉันกำลังพยายามสร้างกรณีสำหรับการใช้การจัดการการพึ่งพาสำหรับการสร้าง (ala Maven, Ivy, NuGet) และสร้างที่เก็บภายในสำหรับโมดูลที่ใช้ร่วมกันซึ่งเรามีองค์กรมากกว่าโหล จุดขายหลักของเทคนิคการสร้างนี้คืออะไร? สิ่งที่ฉันมี:

  • ทำให้กระบวนการแจกจ่ายและนำเข้าโมดูลที่ใช้ร่วมกันโดยเฉพาะการอัพเกรดเวอร์ชั่น
  • ต้องมีการขึ้นต่อกันของโมดูลที่ใช้ร่วมกัน
  • ลบที่ใช้ร่วมกันโมดูลจากการควบคุมแหล่งเร่งและลดความซับซ้อนจ่ายเงิน / เช็คอิน(เมื่อคุณมีการใช้งานกับ 20 + ห้องสมุดนี้เป็นปัจจัยที่แท้จริง)
  • อนุญาตให้ควบคุมหรือรับรู้ถึงสิ่งที่ libs ของบุคคลที่สามที่ใช้ในองค์กรของคุณ

มีจุดขายใดที่ฉันขาดหายไปหรือไม่? มีการศึกษาหรือบทความใดบ้างที่ให้ตัวชี้วัดการปรับปรุง?

dependency-management 
— C. Ross
แหล่งที่มา
1
ฉันคิดว่าคุณถูกจับ
— Mike Partridge
4
ฉันจะไม่หวนคืนเวลาหลายชั่วโมงในชีวิตของฉันที่สูญเสียไปกับการตั้งค่า Maven ที่แตกสลาย ฉันเชื่อมั่นว่าไม่ว่าจะมีความตั้งใจดีในคลังใหญ่แล้วในที่สุดมันก็จะกลายเป็นความยุ่งเหยิงไร้ชีวิตชีวาที่ดูดชีวิตของคุณออกไปจนกว่าคุณจะเป็นโพรงกลวง
— MrFox
1
@suslik สนใจที่จะอธิบายอย่างละเอียดเกี่ยวกับการตั้งค่า "Maven ที่เสียหาย" คืออะไร
— Andrew T Finnell
1
@AndrewFinnell สมมติว่ามี 5 กลุ่มที่ทำงานในโครงการที่คุณต้องดึงเพื่อให้คอมไพล์ของคุณคอมไพล์และเนื่องจากการประสานงานที่ไม่ดีทุกคนจบลงด้วยการขึ้นอยู่กับไลบรารี่รุ่นต่างๆ จากนั้นปรากฎว่าหนึ่งในโครงการไม่ได้หมายถึง 'ปล่อย' แต่ (ไม่มีใครบอกได้ว่า maven!) คุณมีการพึ่งพาที่คุณต้องพึงพอใจ นี่ไม่ใช่ 'ควรจะเกิดขึ้น แต่การแก้ปัญหาอัตโนมัติทำให้ง่ายเกินไป หากทุกคนมี / libs dir เพื่อรักษาใน svn มันจะบังคับให้คนหยุดและถามคำถามก่อนที่จะออกจากมือ
— MrFox
2
@MrFox นั่นเป็นเพราะการประสานงานไม่ดีไม่ใช่การแก้ปัญหาการพึ่งพา Maven ฉันเคยประสบสถานการณ์เดียวกันและฉันไม่ใช่แฟนของ Maven แต่ฉันคิดว่าเครื่องมือไม่ควรแก้ปัญหาที่เกี่ยวข้องกับมนุษย์เช่นการเปิดตัวก่อนกำหนดการขาดการสื่อสารขาดการทดสอบการบำรุงรักษาที่ไม่ดี ฯลฯ
— scriptin

คำตอบ:

8

ฉันไม่แน่ใจ 100% ในแง่บวก นี่คือข้อเสียเล็กน้อย

  1. บ่อยครั้งที่คุณต้องเพิ่มการอ้างอิงไปยังเซิร์ฟเวอร์ / ปลายทางของบุคคลที่สามที่อาจไม่เสถียร

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

    สิ่งนี้ได้รับการแก้ไขเช่นเดียวกับ OP หากคุณดึง deps จากสำเนาที่เก็บไว้ในเซิร์ฟเวอร์ที่คุณใช้

  2. ยากสำหรับ noobs

    ฉันทำงานกับนักเรียนศิลปะที่มีประสบการณ์น้อยมาก พวกเขาสร้างงานศิลปะด้วย Processing, arduino, Unity3D และได้รับความรู้ด้านเทคโนโลยีน้อยมาก พวกเขาต้องการใช้ HTML5 / JavaScript ที่ฉันเขียน ขั้นตอนเพราะความร่มรื่น

    1. ดาวน์โหลด Zip of repo จาก GitHub (สังเกตว่าอยู่ด้านขวาของทุก repo บน GitHub เพราะพวกเขาไม่รู้ Git)
    2. ดาวน์โหลดและติดตั้งโหนด (เพื่อให้เราสามารถเรียกใช้ npm เพื่อติดตั้ง bower)
    3. ติดตั้ง git หรือ msysgit (เนื่องจาก bower ต้องการและไม่ได้ติดตั้งในเครื่องของนักเรียนหลายคน)
    4. ติดตั้ง bower ( npm install -g bower)
    5. bower install (ในที่สุดก็จะได้รับการอ้างอิงของเรา)

    สามารถลบขั้นตอนที่ 2-5 ได้ทั้งหมดหากเราเพียงตรวจสอบไฟล์ไปยัง repo github ของเรา ขั้นตอนเหล่านั้นน่าจะฟังง่ายสำหรับคุณและฉัน สำหรับนักเรียนที่พวกเขาสับสนมากและพวกเขาต้องการที่จะรู้ว่าทุกขั้นตอนที่ไหนและสิ่งที่พวกเขามีซึ่งอาจเป็นการเรียนรู้ที่ดีอาจเป็นไปได้ แต่ทั้งหมดตั้งฉากกับหัวข้อของชั้นเรียนและลืมไปอย่างรวดเร็ว

  3. มันเพิ่มอีกขั้นตอนหนึ่งเมื่อดึง

    มันเกิดขึ้นหลายครั้งที่ฉันทำgit pull origin masterแล้วทดสอบรหัสของฉันและใช้เวลา 5 ถึง 10 นาทีในการจำว่าฉันต้องพิมพ์bower install เพื่อรับ deps ล่าสุด ฉันแน่ใจว่านั่นแก้ปัญหาได้ง่ายด้วยเบ็ดดึงสคริปต์

  4. มันทำให้การคอมไพล์ยากขึ้น

    หาก 2 สาขาแตกต่างกันคุณจะเมา ฉันคิดว่าคุณสามารถพิมพ์ทุกครั้งหลังbower install git checkoutมากสำหรับความเร็ว

สำหรับข้อดีของคุณฉันคิดว่ามีตัวอย่างที่เคาน์เตอร์ให้กับแต่ละคน

ทำให้กระบวนการแจกจ่ายและนำเข้าโมดูลที่ใช้ร่วมกันโดยเฉพาะการอัพเกรดเวอร์ชั่น

อะไรนะ แน่นอนว่าไม่ใช่เรื่องง่ายที่จะเผยแพร่ การดึงหนึ่ง repo แทนที่จะเป็น 20 นั้นไม่ง่ายและมีแนวโน้มที่จะล้มเหลว ดู # 1 ด้านบน

ลบโมดูลที่ใช้ร่วมกันออกจากการควบคุมแหล่งที่มาเร่งความเร็วและลดความซับซ้อนการเช็คเอาต์ / เช็คอิน (เมื่อคุณมีแอพพลิเคชั่นที่มีไลบรารี่มากกว่า 20 ไลบรารี่นี่เป็นปัจจัยที่แท้จริง)

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

คุณสามารถแก้ปัญหานั้นได้โดยการคัดลอก repos แยกต่างหากจากนั้นคุณชี้โครงการของคุณให้เป็นสำเนา จากนั้นคุณใช้การแก้ไขใด ๆ กับสำเนาของคุณ แน่นอนคุณสามารถทำได้ถ้าคุณเพียงแค่คัดลอกแหล่งที่มาลงใน repo ของคุณ

อนุญาตให้ควบคุมหรือรับรู้ถึงสิ่งที่ libs ของบุคคลที่สามที่ใช้ในองค์กรของคุณ

ดูเหมือนว่าจะพิสูจน์ได้ เพียงต้องการที่จะนำ devs ห้องสมุดของบุคคลที่ 3 <ProjectRoot>/3rdparty/<nameOfDep>ในโฟลเดอร์ของตัวเองภายใต้ เป็นเรื่องง่ายที่จะเห็นว่ามีการใช้ libs ของบุคคลที่สามอย่างไร

ฉันไม่ได้บอกว่าไม่มีผลบวก ทีมสุดท้ายที่ฉันอยู่ได้> 100 คู่กรณี 3 คน ฉันแค่ชี้ให้เห็นว่ามันไม่ใช่ดอกกุหลาบทั้งหมด ฉันกำลังประเมินว่าฉันควรกำจัดความกลัวด้วยความต้องการของฉันหรือไม่

— G-Man
แหล่งที่มา
ว้าวคะแนนโหวตติดลบและไม่ใช่เหตุผลเดียวสำหรับพวกเขา ทำได้ดีมาก! :(
— gman
ฉันไม่เคยใช้ bower มาก่อน แต่ความต้องการในinstallทุกครั้งที่คุณเช็คเอาต์ดูเหมือนข้อบกพร่องในการออกแบบ ควรตรวจสอบการกำหนดค่าเมื่อสร้างโครงการ: หากมีการเปลี่ยนแปลงควรสร้างใหม่ตั้งแต่ต้น นอกจากนี้การย้าย repos นั้นไม่เกี่ยวข้องกับ Maven เนื่องจากมันดึงสิ่งประดิษฐ์จากที่เก็บ Maven ซึ่งเก็บสิ่งประดิษฐ์ไม่ใช่ repos จริงที่มีรหัส คุณสามารถเปลี่ยนแปลงได้artifactIdและgroupIdในสิ่งประดิษฐ์รุ่นถัดไปของคุณหากคุณเผยแพร่ในที่เก็บ Maven ดังนั้นคะแนน # 1 และ # 4 ของคุณส่วนใหญ่จะไม่เกี่ยวข้องกับ Maven โดยเฉพาะ # 3 สามารถแทนที่ด้วยmvn clean(บางครั้ง)
— scriptin
ในขณะที่เป็นจริง # 2 ไม่ใช่ข้อเสีย - เป็นการแลกเปลี่ยน แน่นอนคุณต้องเรียนรู้เครื่องมือของคุณ! ตัวอย่างเช่น Git นั้นค่อนข้างยากที่จะเข้าใจ แต่ฉันจะไม่ยอมแพ้เพราะไม่มีพวกปีศาจ
— scriptin
1

ลองดูที่แอพ The Twelve Factor

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

หากคุณปฏิบัติตามขั้นตอนการปล่อย Maven (พัฒนาสแนปชอตจนกว่าจะมีการปล่อยอย่างเป็นทางการแล้วอย่าพยายามเขียนทับรุ่นก่อนหน้านี้ให้ใช้ตัวจัดการพื้นที่เก็บข้อมูลที่เหมาะสมเช่น Nexus หรือ Artifactory) จากนั้นคุณควรมีกระบวนการสร้าง

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

แต่ละข้อด้านบนสร้างขึ้นบนแกนหลักที่ Maven ทุกวันนี้มันเป็นการตัดสินใจที่ไม่ต้องคิดอะไรมาก

— Gary Rowe
แหล่งที่มา
ฉันดูแอพ The Twelve Factor แต่ก็เป็นที่ถกเถียงกันมากและมีความเกี่ยวข้องเพียงเล็กน้อยเท่านั้น การผลัก Maven ไม่ได้ช่วยฉันอธิบายว่าทำไมเราจึงต้องฉีดยา โดยรวมแล้วคำตอบนี้ไม่ได้ช่วยให้ฉันขาย Dependency Injection เพียงแค่บอกสิ่งต่างๆมากมายที่ฉันต้องทำสำหรับกระบวนการสร้างของฉัน
— C. Ross
2
Dependency Injection (รูปแบบการออกแบบ) ไม่ใช่ Dependency Management (รูปแบบการสร้าง) คุณได้ครอบคลุมประเด็นที่สำคัญที่สุดทั้งหมดในคำถามของคุณแล้ว หากทีมของคุณยังคงต้องการความเชื่อมั่นหลังจากได้ยินสิ่งเหล่านี้จากนั้นดูว่าการจัดการการพึ่งพาใดจะนำไปสู่ความเชื่อมั่นสุดท้าย
— Gary Rowe
0

และรายการ # 1 ใน 10 อันดับแรกของเราคือ ...

(ม้วนกลอง)

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

— Ross Patterson
แหล่งที่มา
2
มันแตกต่างจากการตรวจสอบในการพึ่งพาอย่างไร ในความเป็นจริงหากคุณไม่ได้ตรวจสอบการพึ่งพาคุณจะเสี่ยงต่อการมีบุคคลที่สามทำลาย distro ของคุณ ฉันเคยเกิดเหตุการณ์นี้มากกว่าหนึ่งครั้งที่บางคนไม่พอใจที่ชี้ไปที่คนซื้อที่ถูกลบหรือเปลี่ยนชื่อ ถ้าฉันเพิ่งคัดลอกแหล่งที่มาลงใน repo ของเราปัญหานั้นก็หายไป
— gman
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.