Patch або Core Hack

Коли я працюю над проектом оновлення системи, одна з речей, яку я роблю, - це відрізняти систему клієнта від свіжої установки Magento. Я шукаю основні хаки або додаткові файли, які не є частиною стандартного Magento, щоб переконатися, що я зафіксував будь-яку нерозумну, але критично важливу роботу, виконану попереднім фрілансером, підрядником, консультантом чи агентством.

Одна річ, яка мене завжди спотикає, - це патчі. Протягом багатьох років Magento випускав патчі "між версіями" - як правило, для усунення виправлень безпеки або зміни API постачальника / оплати API.

Проблема полягає в тому, що, з точки зору відмінності, патчі не відрізняються від основних хак, особливо коли ви не знаєте, які патчі (якщо такі є) застосовані до системи.

Що призводить до мого питання.

Як ви відрізняєте core hack від патча?

Патчі Magento, що надаються підтримкою, додадуть до журналу свого роду app/etc/applied.patches.list. Я не знаю, коли і як довго це роблять патчі "скриптів". Здається, це роблять і патчі CE.

З цим я часто маю справу (і я зараз працюю над цим), і, на жаль, поки що це повністю ручний процес - у нас є автоматизований процес, який позначає кожен файл, який може бути змінений як частина нашого початкового автоматизованого аудиту для новий клієнт підтримки. Потім у нас хтось відрізняє ці файли і виключаємо будь-які явні помилкові позитиви (тобто зміни пробілів).

Потім, найцікавіша частина - старший член нашої команди, який працює з Magento досить довгий час, повинен переглянути результати, щоб визначити, чи будь-який із змінених файлів може бути результатом виправлення. Ми подивилися на оновлення нашої системи, щоб перевірити, чи не всі відомі нам патчі / можуть отримати наші руки, і це може працювати для CE, але для EE це ще складніше, оскільки підтримка EE іноді видає виправлення безпосередньо клієнтам, які ніколи не випускаються іншим способом або не каталогізуються послідовно.

Отже, коли ми робимо цей рівень огляду, ми покладаємось на минулий досвід застосування цих патчів + здоровий глузд (тобто це лише зміна кінцевої точки API? Якщо так, то чи змінена кінцева точка присутня в оновленій версії? Якщо так, це був патч і його можна ігнорувати).

Теоретично було б просто застосувати всі виправлення, доступні на сторінці завантаження CE тощо, до кожної застосованої версії CE та перевірити їх (FYI, ми не використовуємо diff для першого проходу - ми використовуємо хеширование, в частина тому, що ми вбудували цю технологію в інструмент, який може віддалено перевіряти на сайті, не спочатку завантажуючи його). Це виключає більшість патчів, але це все ще не допомагає жодним патчам CE або EE, які не розміщуються в загальнодоступній області завантаження для CE або клієнтській / захищеній області завантаження для EE. Це вимагає від Magento послідовної політики, щоб ВСІ патчі були доступні для ВСІХ клієнтів, і отримували повідомлення про те, куди ми могли б дістатися до них.

Тож, я не думаю, що існує спосіб 100% автоматизувати це, поки зміни не відбудуться на стороні Magento, на жаль.

Один із способів, коли я підходив до цього, коли я робив багато оновлень і намагався систематизувати процес, - це фактично фіксувати патчі безпосередньо у вашому сховищі основного коду, від якого ви використовуєте, щоб відрізнятись.

Це фактично має дві переваги:

1. Більше неправдивих позитивів, що відображаються у ваших розсіях.

2. Скажімо, у вас є сайт, який не має певного виправлення. Ви можете сказати, що це проблема, тому що він відображатиметься як пропущений код у вашій різниці, хоча технічно вони нічого не пропускають порівняно зі свіжим незавантаженим завантаженням. Але насправді те, що їм не вистачає патча, насправді є проблемою, яку слід вирішити - тож ідеально, що він виявиться у вашому розрізі, щоб ви вирішили разом із оновленням.

Я не думаю, що спочатку Magento у проекті repo є гарною ідеєю, якщо ви керуєте більш ніж 2-3 клієнтами. Оскільки завжди легше зіпсувати застосовані системні патчі з основними хаками.

Найкращий варіант, на мою думку, - це мати дзеркало для зберігання композитора Magento з тегами версій, яке вказує на конкретну версію Magento з можливими офіційними патчами.

Крім того, було б простіше підтримувати власні виправлення до файлів, таких як Mage_Core_Model_Config для веб-сайтів з високою завантаженістю та деякі інші, вводячи їх розстрочку через композитор з номером версії, який відповідає вашому розсилу Magento.

Отже, у цьому випадку оновлення всіх замовницьких проектів до виправленого коду Magento призведе лише до появи версії вашого композиторського файлу. Також збереження коду проекту крім основного, змусить ваших розробників не зламати ядро.

Що стосується визначення патча та хака, я б вважав за краще це:

1. Зміна вихідного основного файлу офіційним файлом патча - це патч
2. Зміна оригінального основного файлу вашої команди - це злом.
3. Зміна локального скопійованого основного файлу з метою виправлення помилок - це патч
4. Зміна локального скопійованого основного файлу, щоб забезпечити нову функціональність - це злом

Таким чином, перемістивши ядро ​​до окремого репо, ви переконаєтесь, що у вас є лише виправлена ​​версія відповідно до пункту 1. І ви можете легко встановити власні патчі над композитором у локальний пул кодів, тому у вас є все відповідно до пункту 3. У випадку 2 і 4, ви можете створити гак фіксації git у проекті репо, щоб заборонити будь-який код вводити в цей dir.

Я переглядаю застосований файл патчів у цій /app/etc/папці і працюю назад. Але, як я дізнався з оновлення, я можу просто видалити файл з версії, в якій є патч-файл, і наступного разу, коли він буде виправлений, це чисто.

Все, що з Magento, я б назвав патчем. Все інше - хак.