กลยุทธ์แพคเกจและรุ่นในสภาพแวดล้อมที่เก็บหลาย

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

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

กระบวนการปล่อยเกี่ยวข้องกับการตัดสาขาที่วางจำหน่ายจากสาขาการพัฒนา (ต้นแบบในกรณีส่วนใหญ่) ของที่เก็บ git แต่ละอัน สิ่งนี้จะมอบให้กับการประกันคุณภาพที่เรียกใช้การทดสอบและลงชื่อออกในชุดของสิ่งประดิษฐ์

ตัวอย่างเช่นนี่เป็นที่เก็บคอมไพล์ทั่วไปที่มีสาขาย่อยที่เกี่ยวข้อง:

 0-0-0-0-0-0-0-0-0-0 (master)
   |           |
   0           0
 (rel-1)       |
               0
            (rel-2)

ฉันพยายามที่จะหารูปแบบของแพคเกจที่มาจากสาขาการพัฒนา เราไม่ต้องการติดแท็กสาขาหลักของแต่ละ repo และ จำกัด แท็กเพื่อปล่อยสาขาเท่านั้น แต่เราควรจะสามารถค้นหาแพ็คเกจที่ปรับใช้ในเครื่องทดสอบโดยใช้ซีแมนทิกส์ yum / rpm มาตรฐาน เวอร์ชันการพัฒนาจะมีลักษณะอย่างไรเมื่อสาขาหลักไม่มีแท็ก ฉันเข้าใจว่าgit describeสามารถให้การแสดงเวอร์ชั่นประกอบที่มีประโยชน์แก่ฉันได้ แต่ทำงานได้ดีเมื่อติดแท็กจุดปล่อยต่างๆในสาขา

แก้ไข 1: เพื่อตอบสนองต่อคำตอบของ @ Urban48

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

สาขาคุณลักษณะของเราจะถูกตัดจากต้นแบบเสมอและผ่านการทดสอบสำหรับนักพัฒนาจำนวนหนึ่งก่อนที่จะรวมกับต้นแบบที่พวกเขาได้รับการตรวจสอบความเสถียรของ CI-CD

โปรแกรมแก้ไขด่วนจะทำในสาขาโปรแกรมแก้ไขด่วน (ตัดจากสาขาที่วางจำหน่าย) และปรับใช้กับการทดสอบผลกระทบน้อยที่สุดในการผลิต

กลยุทธ์การกำหนดรุ่นของเราสำหรับสาขาที่วางจำหน่ายและโปรแกรมแก้ไขด่วนมีดังนี้ดังนี้ semver ปล่อยสาขาในระหว่างรอบการเดินทางผ่าน QA รุ่นเช่นv2.0.0-rc1, v2.0.0-rc2และในที่สุดหลังจาก QA v2.0.0เข้าสู่ระบบปิดกลายเป็น

บางครั้งที่เราทำเผยแพร่ประสำหรับคุณสมบัติขนาดเล็กที่มีการรวมกับสาขาปล่อย (แล้วจะโท) v2.1.0ซึ่งรุ่นกลายเป็น และโปรแกรมแก้ไขด่วนถือว่าv2.1.1รูปแบบ

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

อืมฉันมีตัวอย่าง. net ซึ่งอาจเป็นผู้ไม่เชื่อเรื่องพระเจ้า

ฉันจะทำบทสรุปโดยย่อ

• git repo ต่อองค์ประกอบที่มีกลยุทธ์การแยก gitflow

• ทั้งหมดมุ่งมั่นที่จะพัฒนาทริกเกอร์สร้างเมืองของทีม

• การสร้าง Teamcity แก้ไขเวอร์ชันด้วยผู้ใช้หลักรอง + หมายเลขบิลด์ใน AssemblyInfo.cs เช่น 1.1.hotfix.build

• teamcity ทริกเกอร์การบรรจุภัณฑ์ nuget โดยใช้หมายเลขเวอร์ชันเดียวกันสำหรับไลบรารีที่เผยแพร่ของ nuget

• octopus ปรับใช้ build สร้างเป็น qa สำหรับการทดสอบด้วยตนเอง (สมมติว่าผ่านการทดสอบทั้งหมด)

• หากทุกอย่างดีให้ปรับใช้เวอร์ชันเพื่อการผลิตผ่านปลาหมึกด้วยตนเอง

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

สิ่งสำคัญคือการสร้างทุกรุ่นที่ไม่ซ้ำกันผ่านกระบวนการกลางบางอย่าง

ถ้างั้นคุณก็อยู่ในสถานการณ์ของ 'hmm ฉันอยากได้เวอร์ชั่นอะไร' มากกว่า 'omg ฉันได้เวอร์ชั่นอะไรแล้ว?'

แก้ไข: ความคิดเห็นอีกครั้ง

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

มุมมองของฉันคือคุณต้องพูดถึงกลยุทธ์การแยกสาขาของคุณ

• ห้ามใช้ฟีเจอร์เวอร์ชั่น (หรือ dev)
• ทำเวอร์ชันต้นแบบ
• ใช้แพ็คเกจจากต้นแบบเท่านั้น

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

ปรัชญานิดหน่อยก่อน ..
(ฉันตั้งสมมติฐานบางอย่างเกี่ยวกับขั้นตอนการทำงานของคุณโปรดแก้ไขฉันถ้าฉันผิด)

1. การทดสอบรันย้อนหลัง :

   Branch out maserto to feature branch จากนั้นเปลี่ยนเป็นสิ่งประดิษฐ์สำหรับทดสอบโดย QA
   ปัญหาคือ : เกิดอะไรขึ้นถ้าการทดสอบล้มเหลวก็masterอาจจะเสีย!

   ผลข้างเคียง:

   • มันทำให้นักพัฒนาไม่ไว้วางใจ master

   • เมื่อคุณแยกออกจากต้นแบบเพื่อปล่อยสาขาจะเกิดอะไรขึ้นถ้าการเผยแพร่ก่อนหน้านี้แตก? มันหยุดการรวมคุณสมบัติใหม่ของคุณจนกว่าจะมีการแก้ไขต้นแบบอีกครั้ง

   • เมื่อมีการแก้ไขข้อบกพร่องในสาขาที่วางจำหน่ายผสานกลับไปmasterอาจสร้างความขัดแย้งผสาน (และเราไม่ชอบความขัดแย้ง)

2. การรวมและแก้ไขรหัสขนาดเล็ก :

   มันยากที่จะติดตามรหัสทั้งหมดที่รวมเข้าด้วยกันmasterเช่นการแก้ไขเล็ก ๆ หรือการเปลี่ยนแปลงที่ไม่ได้เป็นส่วนหนึ่งของคุณสมบัติบางอย่าง

   ผลข้างเคียง:

   • นักพัฒนาไม่แน่ใจว่าเขาควรจะแก้ไขปัญหาเล็กน้อยในตอนนี้หรือหลังจากนั้น

   • ฉันควรแก้ไขปัญหาเล็ก ๆ ตัวใหม่นี้ด้วยหรือไม่

   • ณ จุดใดเวลาหนึ่งมันไม่ชัดเจนว่าสถานะของmasterสาขาคืออะไรและรหัสใดที่ลอยอยู่ในนั้น

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

ความคิดของฉันสำหรับกระบวนการทำงานคอมไพล์มีดังนี้:

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

ตอนนี้คุณสามารถควบคุมสิ่งที่กำลังจะเกิดขึ้นได้ดีขึ้น
ตอนนี้มันง่ายมากที่จะแยกรุ่นพัฒนาและรุ่นที่เสถียร

คุณสามารถสร้างสิ่งประดิษฐ์จากสาขาฟีเจอร์เหล่านั้นสำหรับ QA
หากทุกอย่างเรียบร้อยให้รวมคุณลักษณะนั้นกลับไปmasterและเลือกคุณลักษณะ / แก้ไขข้อผิดพลาด / แก้ไขปัญหาร้อนนี้ในสาขาการวางจำหน่าย

versioning เวอร์ชัน
ฟีเจอร์ Branch สามารถใช้ชื่อแบบแผนบางอย่างเช่น1.2.3-rc.12345

รุ่นที่อยู่ในreleaseสาขาจะใช้งานได้1.2.3 ( 1.2.3> และ1.2.3-rc.12345ยังมีสิ่งหนึ่งที่ไม่ต้องกังวลอีก)

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

ฉันหวังว่ามันจะช่วยคุณในทางใดทางหนึ่งฉันยินดีที่จะหารือเกี่ยวกับกรณีขอบที่คุณสามารถมาด้วย

ps:
ฉันขอโทษสำหรับภาษาอังกฤษไม่ใช่ภาษาหลักของฉัน

กระบวนการของคุณดูเหมือนซับซ้อนและได้รับแท็กจำนวนเล็กน้อยดูเหมือนจะหลีกเลี่ยงไม่ได้

ความคิดสองประการอยู่ในใจ:

1. คุณถือว่าสาขา "ต้นแบบ" เป็นสิ่งที่เรามักจะมีในสาขา "พัฒนา" สิ่งนี้ทำให้สาขาข้อความสกปรกมาก

2. เมื่อ QA เสร็จสิ้นงานของพวกเขาคุณสามารถมีเซิร์ฟเวอร์ build / CI เพื่อสร้างรายงาน (เช่นไฟล์ข้อความ) ที่มีแท็กของ repos ทั้งหมดที่ใช้งานอยู่ ตอนนี้คุณจะมีไฟล์ที่มีเวอร์ชันซึ่งสามารถโพสต์ไปที่ repo ได้ จากนั้นคุณแท็กสาขาด้วยรุ่นที่วางจำหน่ายเท่านั้นและหากคุณต้องการตรวจสอบเวอร์ชันของส่วนประกอบแต่ละรายการคุณสามารถตรวจสอบรายงานได้