วิธีการบรรลุการเปลี่ยนแปลงอย่างราบรื่นจาก "รูปแบบการจัดเก็บ VCS ขนาดใหญ่สำหรับผลิตภัณฑ์ทั้งหมด" เป็นรูปแบบ "ที่เก็บ VCS ขนาดเล็กจำนวนมาก"

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

ในคำตอบของคำถามนี้ฉันต้องการจะดู:

1. ความพยายามที่จะให้คำจำกัดความการทำงานของผลิตภัณฑ์คืออะไรซึ่งจะให้เกณฑ์ที่ใช้งานได้จริงเพื่อวิเคราะห์ผลิตภัณฑ์ใน codebase ที่มีอยู่

2. ตามคำจำกัดความการทำงานนี้ทำอย่างละเอียดแผนที่ดำเนินการแยกจริง เราสามารถทำให้ลดความซับซ้อนของสมมติฐานว่า codebase มีการประมวลผลโดยอัตโนมัติSDLCการดำเนินการอย่างต่อเนื่องบูรณาการและต่อเนื่องการจัดส่ง นั่นคือแต่ละสาขาได้รับการตรวจสอบความถูกต้องโดยการทดสอบอัตโนมัติที่นำไปใช้ใน codebase ปัจจุบันและแต่ละการผสานกับสาขา“ เวทมนต์” บางอย่างจะสร้างสิ่งประดิษฐ์ผลิตภัณฑ์ที่ได้รับการทดสอบและปรับใช้ ( สิ่งประดิษฐ์สินค้าเป็นเช่น tarballs แหล่งที่มาของเอกสาร, ซอฟแวร์ไบนารีเทียบท่าภาพ Amis, unikernels.)

3. แผนดังกล่าวเป็นที่น่าพอใจหากจะอธิบายวิธีการหลีกเลี่ยง

ปัญหาที่เกิดจากการแยก

1. ขั้นตอนการทดสอบอัตโนมัติเกี่ยวข้องกับที่เก็บเสาหินที่มีอยู่แล้วและที่เก็บแยกอย่างไร

2. ขั้นตอนการปรับใช้อัตโนมัติเกี่ยวข้องกับที่เก็บเสาหินที่มีอยู่แล้วและที่เก็บแยกอย่างไร

3. เก็บรหัสไว้สำหรับกระบวนการปรับใช้อัตโนมัติด้วยตนเองที่ไหน

4. ไหนจะถูกเก็บไว้โครงสร้างพื้นฐาน , การตรวจสอบและความพร้อมสูงกลยุทธ์?

5. วิธีการตรวจสอบให้แน่ใจว่านักพัฒนาซอฟต์แวร์ต้องการโค้ดเบสครั้งละหนึ่งรายการเท่านั้น (แต่เป็นไปได้ที่จะใช้สิ่งประดิษฐ์จากโค้ดอื่น ๆ )

6. เครื่องมือเช่นgit-bisectสามารถทำได้อย่างไร

หมายเหตุ: ประโยชน์ของการมีผลิตภัณฑ์ต่อที่เก็บ VCS ผ่านโมเดลพื้นที่เก็บข้อมูล bloat

การมีที่เก็บข้อมูลขนาดเล็กจำนวนมากที่ถือครอง codebase สำหรับผลิตภัณฑ์เฉพาะนั้นมีข้อดีดังต่อไปนี้ในวิธีการ "พื้นที่เก็บข้อมูล bloat":

1. ด้วยพื้นที่เก็บข้อมูลขนาดเล็กมันเป็นเรื่องยากที่จะย้อนกลับการเปิดตัวเมื่อผลิตภัณฑ์ไม่เสถียรเพราะประวัติผสมกับประวัติผลิตภัณฑ์อื่น ๆ

2. ด้วยพื้นที่เก็บข้อมูลขนาดเล็กทำให้ยากต่อการตรวจสอบประวัติโครงการหรือการดึงข้อมูลด้วยที่เก็บขนาดเล็กเรามีแนวโน้มที่จะอ่านข้อมูลนี้มากขึ้น (นี่อาจเฉพาะเจาะจงกับ VCS เช่น git ซึ่งต่างจาก svn เราไม่สามารถชำระเงินย่อยได้!)

3. ด้วยพื้นที่เก็บข้อมูลที่ขยายตัวเราต้องทำการฟ้อนรำของสาขามากขึ้นเมื่อเราพัฒนา หากเรามีที่เก็บข้อมูล N เราสามารถทำงานแบบขนานบนสาขา N หากเรามีที่เก็บเพียง 1 แห่งเราสามารถทำงานในสาขาเดียวหรือมีสำเนางานที่โหลดซึ่งยุ่งยากในการจัดการ

4. ด้วยที่เก็บขนาดเล็กหลายแห่งบันทึกจะให้แผนผังความร้อนของโครงการ พวกเขายังสามารถใช้เป็นพร็อกซีของการกระจายความรู้ในทีมงาน dev: ถ้าฉันไม่ได้ทำ repo X ตั้งแต่ 3 เดือนมันก็ดีที่จะมอบหมายให้ฉันในทีมที่ทำงานเกี่ยวกับ repo X เพื่อให้ฉันตระหนักถึงการพัฒนา ในองค์ประกอบนั้น

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

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

7. ด้วยที่เก็บข้อมูลขนาดเล็กหลายแห่งทำให้ง่ายต่อการมีเจ้าของผลิตภัณฑ์หลายคน

8. ด้วยที่เก็บขนาดเล็กหลายแห่งจะง่ายกว่าที่จะมีมาตรฐานรหัสแบบง่าย ๆ ที่เกี่ยวข้องกับที่เก็บข้อมูลแบบเต็มและสามารถตรวจสอบได้โดยอัตโนมัติ

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

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

ออกแบบ

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

ความมั่นใจ

การเปลี่ยนแปลงจะต้องถูกแยกออกจากกันในแง่ที่ว่าต้องมีการตัดประวัติที่สอดคล้องกันซึ่งให้การเปลี่ยนแปลงนั้นและตัวมันเองเท่านั้นโดยไม่มีการเปลี่ยนแปลงอื่น ๆ (หลังจากการเตรียมหลายเดือน) ด้วยความมั่นใจใครจะอนุมัติและกดปุ่มสีแดง?

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

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

ในความเป็นจริงมันเป็นเรื่องธรรมดามากสำหรับการทดสอบบอล mudballs; โดยปกติแล้วรหัสนั้นมีการเชื่อมโยงอย่างแน่นหนาและน่าจะเป็นไปได้ว่าสำหรับรหัสดั้งเดิมส่วนใหญ่มันไม่ได้พัฒนาด้วยวิธีการทดสอบที่ขับเคลื่อนด้วยไม่ใช่แม้แต่การทดสอบหน่วย

หากรหัสทดสอบดังกล่าวขาดหายไปจะต้องเขียนรหัสนั้นเสียก่อน

กลยุทธ์

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

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

หนี้ทางเทคนิค

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

Reaggregation

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

การทดสอบบูรณาการ

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

PS นี่เป็นร่างภาษาอังกฤษของฉันไม่ดีและฉันจะซ่อมวันหนึ่ง