Patch หรือ Core Hack

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

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

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

ซึ่งนำไปสู่คำถามของฉัน

คุณแยกความแตกต่างระหว่างแฮ็คหลักและแพทช์ได้อย่างไร

app/etc/applied.patches.listแพทช์วีโอไอพีที่จัดทำโดยการสนับสนุนจะผนวกเข้าสู่ระบบของแปลกไป ฉันไม่รู้ว่าแพทช์ "สคริปต์" นั้นได้ทำมานานแค่ไหนแล้วหรือยัง โปรแกรมแก้ไข CE ดูเหมือนจะทำเช่นนี้

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

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

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

มันจะเป็นการง่ายในทางทฤษฎีที่จะใช้ชุดข้อมูลแก้ไขทั้งหมดที่มีอยู่ในหน้าดาวน์โหลด CE ฯลฯ กับทุกรุ่นที่ใช้งานได้ของ CE และตรวจสอบกับสิ่งเหล่านั้น (FYI เราไม่ใช้ diff สำหรับรอบแรก - เราใช้ hashing ใน ส่วนหนึ่งเพราะเราสร้างเทคโนโลยีนี้เป็นเครื่องมือที่สามารถตรวจสอบไซต์จากระยะไกลโดยไม่จำเป็นต้องดาวน์โหลดก่อน) แต่จะไม่ช่วยให้โปรแกรมแก้ไข CE หรือ EE ใด ๆ ที่ไม่ได้โพสต์ลงในพื้นที่ดาวน์โหลดสาธารณะสำหรับ CE หรือพื้นที่ดาวน์โหลดของไคลเอนต์ / ป้องกันสำหรับ EE นั่นจะทำให้วีโอไอพีต้องจัดทำนโยบายที่สอดคล้องกันซึ่งลูกค้าทุกคนจะได้รับแพตช์และนำโพสต์ไปยังที่ที่เราสามารถเข้าถึงได้

ดังนั้นฉันไม่คิดว่าจะมีวิธีอัตโนมัติแบบนี้ได้ 100% จนกว่าการเปลี่ยนแปลงจะเกิดขึ้นในด้านของวีโอไอพี แต่น่าเสียดายที่

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

อันที่จริงมีสองประโยชน์:

1. ไม่มีผลบวกผิดพลาดปรากฏขึ้นในส่วนต่างของคุณ

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

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

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

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

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

สำหรับคำจำกัดความของโปรแกรมปะแก้และแฮ็คฉันอยากจะเรียกมันว่า:

1. การเปลี่ยนแปลงในไฟล์คอร์ดั้งเดิมด้วยไฟล์แพทช์อย่างเป็นทางการ - เป็นแพทช์
2. การเปลี่ยนแปลงในไฟล์หลักดั้งเดิมโดยทีมของคุณ - เป็นแฮ็ค
3. การเปลี่ยนแปลงในไฟล์คอร์ที่คัดลอกในเครื่องสำหรับจุดประสงค์ในการแก้ไขบั๊ก - มันเป็นแพตช์
4. การเปลี่ยนแปลงในไฟล์ core ที่คัดลอกในเครื่องเพื่อจัดหาฟังก์ชั่นใหม่ - มันคือการแฮ็ค

ดังนั้นโดยการย้ายแกนหลักไปยัง repo ที่แยกต่างหากคุณจะได้รับการตรวจสอบว่าคุณมีรุ่นที่ได้รับการปรับปรุงตามรายการที่ 1 เท่านั้นและคุณสามารถติดตั้ง Patch ของคุณเองผ่านทางผู้แต่งลงในกลุ่มรหัสท้องถิ่นได้ และ 4 คุณสามารถสร้างคอมไพล์การคอมไพล์ใน repo โครงการเพื่อห้ามมิให้โค้ดใด ๆ

ฉันมองไปที่ไฟล์ปะที่นำไปใช้ใน/app/etc/โฟลเดอร์นั้นและทำงานย้อนหลัง แต่เมื่อฉันเรียนรู้จากการอัปเกรดฉันสามารถลบไฟล์ในเวอร์ชันที่มีไฟล์แพตช์ในพวกเขาและครั้งต่อไปที่แพทช์มันสะอาด

ทุกอย่างจาก Magento ฉันจะเรียกแพทช์ ทุกอย่างอื่นคือแฮ็ค