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

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

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

เราใช้การทดสอบหน่วยด้วย SimpleTest และติดตามการตั้งชื่อไฟล์และฐานข้อมูลทั้งหมด ฯลฯ

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

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

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

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

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

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

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

เราจัดการกับปัญหานี้ด้วยการทำให้โค้ดของเราเป็นแบบโมดูลาร์

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

เราพยายามเขียนรหัสใหม่เพื่อย้ายไปยังเวอร์ชั่นใหม่ของ Spring แต่นั่นพิสูจน์ได้ยากมาก ดังนั้นวิธีการของเราคือการเริ่มสร้างคุณสมบัติใหม่ของเว็บไซต์เป็นโมดูลในแอปพลิเคชันที่แยกจากกันโดยใช้เฟรมเวิร์กล่าสุดเช่น Spring 3.x, Hibernate 3.6 เป็นต้น

ตอนนี้เรามีเว็บแอปพลิเคชั่นสองตัวที่ทำงานบน URL พื้นฐานเดียวกันและเราใช้โมดูล mod_proxy ของ Apache เพื่อจัดสรรแต่ละพา ธ ไปยังแอปพลิเคชันที่เหมาะสม ตัวอย่างเช่น "/ members" ไปที่แอปพลิเคชันเก่าและ "/ ไดเรกทอรี่" จะไปที่แอปพลิเคชันใหม่ อย่างไรก็ตามผู้เยี่ยมชมไซต์จะไม่มีความคิดว่าพวกเขากำลังใช้แอปพลิเคชันอื่น พวกเขาดูเหมือนกันกับผู้ใช้ทั้งหมด

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

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

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

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

และนี่คือสิ่งที่ทำให้ฉันทุกครั้ง

ทุกครั้งหรือ คุณจะต้องทำการเลือกที่ไม่ดีอย่างน่าทึ่ง ต้องมีตัวอย่างหนึ่งที่ไม่เกิดขึ้น

เมื่อ devs เริ่มเล่นกับของเล่นเงาใหม่

นั่นเป็นคำใบ้ หลีกเลี่ยงของเล่นใหม่ที่เป็นประกายเมื่อใช้โครงการโอเพ่นซอร์ส หลีกเลี่ยงการปล่อย 1.0

คุณจะรับมือกับการเปลี่ยนแปลงที่สำคัญในโครงการโอเพ่นซอร์สที่คุณใช้อย่างไร

ขั้นตอนที่ 1 เลือกโครงการโอเพ่นซอร์สอย่างระมัดระวังมาก เปรียบเทียบโครงการที่แข่งขันกันสองโครงการขึ้นไปเสมอ

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

ขั้นตอนที่ 3 โอบกอดหลักการออกแบบของ "การผูกปลาย" และ "การเชื่อมต่อแบบหลวม" พยายามที่จะป้องกันจากการเปลี่ยนแปลงโครงการโอเพนซอร์ส

ขั้นตอนที่ 4 ทำการเปรียบเทียบต้นทุน / ผลประโยชน์อย่างชัดเจนระหว่างโครงการโอเพ่นซอร์สกับ "การพลิกกลับของคุณ" ในบางครั้งการสร้างโซลูชันของคุณเองอาจดีกว่าการจัดการกับโซลูชันโอเพนซอร์ส

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

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