วิธีที่เป็นจริงในการจัดการกับซอฟต์แวร์แก้ไขเฉพาะลูกค้าคืออะไร?

16

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

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

กลยุทธ์การแยกสาขาของเราเป็นเช่นนี้ (อ้างอิงจากVisual Studio TFS Branching Guideถึงแม้ว่าเราจะใช้ Subversion) ป้อนคำอธิบายรูปภาพที่นี่

version-control business release-management

— Vimes
แหล่งที่มา

หากคุณใช้hgหรือgitฉันอาจแนะนำให้คุณดูการใช้ Patch Queues ( Mercurial Queues ExtensionหรือGed แบบซ้อน ) แต่ฉันไม่รู้ว่า TFS มีอะไรที่คล้ายกันหรือไม่

— Mark Booth

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

— Vimes

2

โซลูชันทางธุรกิจคือ: อย่าทำ

— JeffO

@JeffO การโทรที่ดี =) ไม่ว่าในกรณีใด ๆ มีวิธีใดบ้างที่คุณสามารถใช้สวิตช์ข้อมูลที่ขับเคลื่อนด้วยข้อมูลได้?

— Patrick Hughes

1

@JohnB - ขออภัยฉันไม่รู้ แต่ถ้าคุณมีซอร์สแพตช์ระบบการสร้างของคุณจะสามารถทำการทดสอบอัตโนมัติได้รวมถึงการรักษาแพตช์ของลูกค้าต่อไปนอกsvnหมายความว่าพวกเขาไม่ได้ยุ่งกับเวิร์กโฟลว์ปกติของคุณ ถ้าแพทช์คิวลักษณะเหมือนพวกเขาอาจจะมีประโยชน์คุณสามารถลองพวกเขาออกมาใช้Git-SVNหรือhgsubversion การใช้ส่วนหน้าของ DVCS เพื่อทำให้เวิร์กโฟลว์ที่ยุ่งยากsvnนั้นอาจช่วยกระตุ้นให้ผู้คนพิจารณาที่จะย้ายไปค้าส่ง DVCS เพื่อรับผลประโยชน์อื่น ๆ ทั้งหมด

— Mark Booth

5

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

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

— Charles Lambert
แหล่งที่มา

5

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

— Loren Pechtel
แหล่งที่มา

สิ่งนี้สามารถทำงานได้สำหรับการปรับแต่งง่าย ๆ แต่สิ่งที่ซับซ้อนกว่านั้นอาจทำให้ผลิตภัณฑ์อึดอัดและไม่แน่นอนสำหรับลูกค้าทั้งหมด

— FrustratedWithFormsDesigner

3

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

— maple_shaft

2

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

— Steve Hill

1

@maple_shaft - แต่คุณคิดว่าจะถามคำถามว่า "คุณเคยใช้การแยกรหัสเพื่อนำความเป็นสากลมาใช้" หรือไม่?

— psr

3

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

— psr

3

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

หากในระยะยาวคุณจะพบว่าประหยัดถ้าคุณปรับซอฟต์แวร์ให้เหมาะสมกับความต้องการของลูกค้าผ่านการกำหนดค่า (หรือการตั้งค่า ฯลฯ )

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

เรื่องสั้นสั้น ในระยะยาวแก้ไขในทางเทคนิคจัดการระยะสั้นกับมัน

แน่นอนว่ามันมีจุดที่มันจะโยนเหรียญ หากคุณอยู่ที่จุดนั้นฉันจะทำสิ่งที่นักพัฒนาต้องการ

— ElGringoGrande
แหล่งที่มา

2

เราใช้การโค่นล้มเช่นกัน - และเราเจอสถานการณ์ที่แน่นอนเช่นนี้

นี่คือประเด็นสำคัญที่ต้องจำ:

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

ฉันได้พยายามรวบรวมความคิดเหล่านี้เข้าด้วยกันเพื่อแสดงใน แผนภาพด้านล่าง :

— Dipan Mehta
แหล่งที่มา

1

วิธีการเกี่ยวกับการแนะนำกลไกการขยายในรหัสของคุณ?

รหัสหลักของคุณมี:

class Foo
{
}

เมื่อโปรแกรมเปิดตัวโปรแกรมจะตรวจสอบความเทียบเท่า DLL / คุณธรรมในโฟลเดอร์เริ่มต้นของโปรแกรมนั้นเพื่อปรับแต่งในเครื่อง หากพบหนึ่งรายการจะโหลดและอาจมี Foo รุ่นเฉพาะ บริษัท

class FooForABC : Foo
{
}

FooForABC ดำเนินการพฤติกรรมเช่นเดียวกับ Foo แต่แทนที่ฟังก์ชั่นตามความจำเป็นเพื่อให้พฤติกรรมที่เฉพาะเจาะจงที่ ABC ต้องการ เทคนิคควรมีความยืดหยุ่นเพียงพอที่จะรองรับสถานการณ์ที่คุณต้องการสนับสนุน

— Winston Ewert
แหล่งที่มา