คุณจะจัดการเวอร์ชันในโครงการหลายด้านได้อย่างไร

ฉันรู้ว่ามันเป็นคำถามกว้าง ๆ ดังนั้นฉันจะพยายามเจาะจงให้มากที่สุดเท่าที่จะทำได้ คำถามนี้เป็นคำถาม "องค์กร" มากกว่าคำถามทางเทคนิค

เรามีโครงการหลายด้านที่มีองค์ประกอบหลักเหล่านี้:

• เซิร์ฟเวอร์ที่โฮสต์ตรรกะทางธุรกิจหลัก (ตัวแบบข้อมูล)
• BackOffice สำหรับลูกค้าที่ใช้ตรรกะทางธุรกิจหลัก
• แอปพลิเคชัน API (REST) ​​ซึ่งใช้ตรรกะทางธุรกิจหลักเช่นกัน
• มีแอพสมาร์ทโฟน (iOS และ Android) โดยใช้แอปพลิเคชัน API
• มีแอปแท็บเล็ตอีกแอนดรอยด์ที่แตกต่างจากสมาร์ทโฟนที่ใช้แอปพลิเคชัน API เดียวกัน

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

• รหัสของตรรกะทางธุรกิจหลักในเซิร์ฟเวอร์ (ใช้โดย back-office, API และผลข้างเคียงจากแอปมือถือ)
• API เอง (ใช้ทั้งแอพสมาร์ทโฟนและแท็บเล็ต)
• แอพมือถือทั้งหมด (ผ่าน appstore / googleplay)

แน่นอนส่วนฝั่งเซิร์ฟเวอร์ (รหัสตรรกะทางธุรกิจหลักและรหัส API) สามารถเปลี่ยนแปลงได้ทันทีด้วยตัวเอง อย่างไรก็ตามลูกค้าจะต้องดาวน์โหลดแอพมือถือใหม่ใน appstore / googleplay และฉันไม่สามารถแน่ใจได้ว่าพวกเขาทันสมัย

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

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

ในคำเดียวฉันควรจะจัดระเบียบเพื่อให้โครงการหลายด้านของฉันมีชีวิตอยู่ตลอดเวลา?

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

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

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

โพสต์นี้สร้างประเด็นที่น่าสนใจเกี่ยวกับคำถามของคุณ

ในทางปฏิบัติหากคุณมี 3 องค์ประกอบ:

• 2 Consumerers: Front-End และ Mobile App
• 1 ผู้ให้บริการ API: Back-End

คุณสามารถใช้รูปแบบการกำหนดรุ่นทั่วไปของ Mmp (Major.minor.patch) สำหรับแต่ละรายการ แต่ใน URL Back-End ของคุณคุณสามารถใส่อะไรhttp://youhost/M.m/resourceURIก็ได้

เมื่อคุณพัฒนาและการเปลี่ยนแปลงใน API จะไม่ส่งผลต่อสัญญาของคุณกับผู้บริโภคที่คุณรักษาไว้M.mเช่นเดียวกับใน URL จากช่วงเวลาที่คุณจะทำให้การเปลี่ยนแปลงในแบ็กเอนด์ที่มีผลต่อผู้บริโภคของคุณ (ไม่ว่าจะมีการเปลี่ยนแปลงในพฤติกรรมหรือวัตถุที่เป็นที่แตกต่างกัน) คุณใช้M.m+1, หรือM+1.m+1M+1.m

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

คุณสามารถดูคำตอบที่ดีกว่าของฉันได้ที่นี่: การกำหนดเวอร์ชัน REST API บน Stackoverflow

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

1. ทุกองค์ประกอบจะได้รับการเวอร์ชั่นเมื่อมีการเผยแพร่ ซึ่งรวมถึงห้องสมุดระดับต่ำเช่นเดียวกับผลิตภัณฑ์ขั้นสุดท้ายของคุณ
2. ทุกรหัสกระทำจะก่อให้เกิดการสร้างภาพรวม สิ่งนี้จะช่วยให้นักพัฒนาซอฟต์แวร์ของคุณซื่อสัตย์โดยเฉพาะถ้าคุณใช้สิ่งอำนวยความสะดวกเพื่อส่งอีเมลถึงผู้ร้ายที่ทำลายงานสร้าง
3. ทุกบิลด์สามารถเรียกใช้การทดสอบหน่วย สิ่งนี้ช่วยปรับปรุงคุณภาพรหัสอย่างชัดเจน
4. ทุกรุ่นจะถูกติดแท็กดังนั้นหากจำเป็นต้องมีการแก้ไขการผลิตมันเป็นเรื่องง่ายที่จะแยกสาขาจากแท็กและทำการแก้ไข
5. คุณจะต้องรักษาทะเบียนความเข้ากันได้ของบางประเภท (เช่น BackOffice 1.0.23 เข้ากันได้กับ REST API 2.0.267 เป็นต้น) ฉันไม่รู้เครื่องมือที่จะช่วยในเรื่องนี้

ประสบการณ์ของฉันใช้เครื่องมือโอเพ่นซอร์ส: SVN, Maven 2, Jenkins และ Nexus แต่มีทางเลือกทั้งหมดเหล่านี้

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

สำหรับทีมที่ค่อนข้างเล็กสำหรับการพัฒนาและการปรับใช้โมเดลความเข้ากันได้ของไคลเอ็นต์ N-1 ซึ่งทำงานโดย IBM Jazz อาจทำงานได้ค่อนข้างดี

พยายามรักษาไคลเอ็นต์และเซิร์ฟเวอร์ตามหมายเลขเวอร์ชันเดียวกัน [แทนที่จะจัดการเมทริกซ์ของเวอร์ชันอิสระและความสามารถในการใช้งานร่วมกัน]

กำหนดนโยบายที่ไคลเอ็นต์รุ่น Xyy ควรทำงานกับเซิร์ฟเวอร์ทุกรุ่นด้านบน Xyy แต่ต่ำกว่า X + 2.0.0

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

ไคลเอนต์รุ่น 4.x ควรเข้ากันได้กับเซิร์ฟเวอร์เวอร์ชัน 4.x และสูงกว่า แต่ต่ำกว่า 6.0; เซิร์ฟเวอร์ 4.x ควรเข้ากันได้กับไคลเอนต์ทุกรุ่น 3.0 ขึ้นไป แต่น้อยกว่าหรือเท่ากับ 4.x

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

Ref: IBM Jazz Model [ https://www.ibm.com/support/knowledgecenter/en/SSYMRC_6.0.0/com.ibm.jazz.install.doc/topics/c_n-1.html]

ก่อนอื่นฉันจะเริ่มด้วยการกำหนดปัญหาให้แตกต่างกันเล็กน้อย คุณได้ขอซอฟต์แวร์ประเภทใดที่คุณต้องการ "รุ่น" เวอร์ชันเป็นคำที่โอเวอร์โหลดใน CS และอาจมีความหมายต่างกันประมาณ 100 เรื่อง สิ่งหลักที่ฉันจะดูคือ:

1. การควบคุมเวอร์ชัน - การควบคุมเวอร์ชันเป็นเครื่องมือจัดการการกำหนดค่าที่ช่วยให้คุณติดตามภาพรวมและประวัติการพัฒนาของคุณ รหัสทั้งหมดควรอยู่ภายใต้การควบคุมเวอร์ชัน ฉันไม่สนหรอกว่ามันจะเป็นแค่สคริปต์อำนวยความสะดวกที่คุณเพิ่มไปยังโฟลเดอร์ bin ของคุณสิ่งใดก็ตามที่คุ้มค่ากับการใช้เวลาในการเขียนนั้นคุ้มค่ากับสองวินาทีในการเพิ่มซอฟต์แวร์ควบคุมการแก้ไข
2. การจัดการการกำหนดค่า - ฉันจะควบคุมสิ่งที่อยู่ในบิลด์ได้อย่างไร ซอฟต์แวร์ทั้งหมดควรมีการจัดการการกำหนดค่าระดับหนึ่ง ฉันชอบอธิบายให้ผู้จัดการทราบถึงความแตกต่างระหว่างการควบคุมเวอร์ชันและการจัดการการกำหนดค่าเนื่องจากการควบคุมเวอร์ชันเป็นเพียงเครื่องมือในการติดตามประวัติของการพัฒนาในขณะที่การจัดการการกำหนดค่าเป็นแนวทางสำหรับวิธีที่เราสร้างประวัติ ดี.
3. การกำหนดเวอร์ชันซอฟต์แวร์ - การกำหนดชื่อให้กับการเผยแพร่รหัส นี่คือสิ่งที่หลาย ๆ คนยึดถือไว้เมื่อพวกเขาเห็นปัญหาเป็นครั้งแรกเพราะพวกเขาเคยเห็น "MineSweeper 7.1.29290149210" หรืออะไรก็ตามที่พวกเขาซื้อ แต่จริงๆแล้วฉันพบว่านี่เป็นส่วนน้อยที่สุดของปัญหาที่ใหญ่กว่า ความซื่อสัตย์เพียงแค่ใช้แฮชที่สร้างขึ้นโดย 1 และไม่สนใจทุกอย่างที่มนุษย์ไม่สามารถอ่านได้

ดังนั้นเนื่องจากมันคลุมเครือที่สุดและน่าสนใจที่สุดสำหรับฉันฉันแค่จะมุ่งเน้นไปที่ # 2 ไม่มีโซลูชันที่เหมาะกับทุกคนในการจัดการการกำหนดค่า กฎที่ทำงานได้ดีสำหรับทีม 2 หรือ 3 อาจหลวมเกินไปที่จะรักษาสติในโครงการที่ใช้แรงงานหลายร้อยคน กฎที่ทำงานกับทีมใหญ่อาจต้องใช้ค่าใช้จ่ายมากเกินไปสำหรับทีมเล็ก คุณน่าจะต้องปูทางบางอย่างของคุณเองเพื่อให้ได้อะไรกัน แต่ฉันจะใช้รายการต่อไปนี้เป็นวิธีในการพัฒนารายละเอียดสำหรับระบบการจัดการการกำหนดค่าของคุณ:

1. ฉันจะติดตามเวอร์ชัน (และปัญหาที่เกี่ยวข้องกับพวกเขา) ที่ฉันสนับสนุนในตลาดได้อย่างไร
2. ฉันจะตัดสินใจได้อย่างไรว่าเส้นทางการพัฒนาใดพร้อมที่จะปล่อยสู่ระบบการผลิต? (อาจพร้อมสำหรับขั้นตอนอื่นในกระบวนการ)
3. ใครควรมีการควบคุม / จัดการการกำหนดค่าของระบบ เวิร์กโฟลว์สำหรับการเพิ่มรหัสที่จะแจกจ่ายให้กับนักพัฒนาอื่น ๆ คืออะไร?
4. ฉันจะควบคุมการมีปฏิสัมพันธ์ระหว่างชิ้นส่วนที่ตอบโต้ได้อย่างไร? ฉันจะรู้ได้อย่างไรว่าการเปลี่ยนชิ้นส่วนจะทำให้ระบบที่เหลือหยุดทำงานหรือไม่
5. เราจะปรับปรุงระบบการจัดการการกำหนดค่าของเราอย่างไรเมื่อเวลาผ่านไป

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