Patch o Core Hack

Quando sono su un progetto di aggiornamento del sistema, una delle cose che faccio è diff il sistema di un client contro una nuova installazione di Magento. Sto cercando hack core o file aggiuntivi che non fanno parte del Magento standard per assicurarmi di catturare qualsiasi lavoro critico ma di business svolto da un precedente libero professionista, appaltatore, consulente o agenzia.

Una cosa che mi sconcerta sempre però sono le patch. Nel corso degli anni Magento ha emesso patch "tra versioni", in genere per risolvere una correzione di sicurezza o una modifica dell'API di un fornitore di spedizione / pagamento.

Il problema è, dal punto di vista di un diff, che le patch sono indistinguibili dagli hack core, specialmente quando non si conosce quali patch (se presenti) sono state applicate al sistema.

Il che porta alla mia domanda.

Come si fa a distinguere tra un core hack e una patch?

Le patch Magento fornite dal supporto aggiungeranno una sorta di registro app/etc/applied.patches.list. Non so quando o da quanto tempo gli "script" patch lo fanno. Anche le patch CE sembrano fare questo.

Questo è qualcosa di cui mi occupo spesso (e sto lavorando proprio ora) e, sfortunatamente, finora è un processo completamente manuale - abbiamo un processo automatizzato che contrassegna ogni file che potrebbe essere modificato come parte del nostro controllo automatico iniziale per un nuovo client di supporto. Abbiamo quindi qualcuno che diffonde quei file ed escludiamo qualsiasi falso positivo evidente (cioè cambiamenti di spazi bianchi).

Quindi, la parte divertente - un membro anziano del nostro team che ha lavorato con Magento per un po 'di tempo deve dare un'occhiata ai risultati per determinare se uno qualsiasi dei file modificati potrebbe essere il risultato di una patch. Abbiamo esaminato l'aggiornamento del nostro sistema per verificare tutte le patch di cui siamo a conoscenza / su cui possiamo mettere le mani, e che potrebbero funzionare per CE, ma su EE è ancora più impegnativo, poiché il supporto EE a volte emette patch direttamente ai clienti che non sono mai stati rilasciati in altro modo o catalogati in modo coerente.

Quindi, quando eseguiamo questo livello di revisione, facciamo affidamento sull'esperienza passata con l'applicazione di queste patch + buon senso (ovvero, è solo una modifica all'endpoint di un'API? In tal caso, l'endpoint modificato è presente nella versione aggiornata? In caso affermativo, era una patch e può essere ignorato).

Sarebbe teoricamente semplice applicare tutte le patch disponibili nella pagina di download di CE, ecc., A tutte le versioni applicabili di CE e confrontarle (FYI, non usiamo diff per il primo passaggio - usiamo hashing, in parte perché abbiamo costruito questa tecnologia in uno strumento che può controllare in remoto su un sito senza bisogno di scaricarlo prima). Ciò escluderebbe la maggior parte delle patch, ma non aiuta ancora per le patch CE o EE che non sono pubblicate nell'area di download pubblica per CE o nell'area di download client / protetta per EE. Ciò richiederebbe a Magento di mettere in atto una politica coerente in base alla quale TUTTE le patch saranno rese disponibili a TUTTI i clienti e di pubblicare quelle dove potremmo arrivare.

Quindi, non penso che ci sia un modo per automatizzare al 100% questo fino a quando i cambiamenti non avvengono sul lato Magento delle cose, sfortunatamente.

Un modo in cui mi sono avvicinato a questo mentre stavo facendo molti aggiornamenti e cercando di sistematizzare il processo era in realtà il commit delle patch direttamente nel tuo repository di codice principale che stai usando per diff.

Questo in realtà ha due vantaggi:

1. Niente più falsi positivi che compaiono nei tuoi diff.

2. Diciamo che hai un sito che non ha una determinata patch. Potresti dire che è un problema perché apparirà come codice mancante nel tuo diff anche se tecnicamente non mancano nulla rispetto a un nuovo download senza patch. Ma in realtà, la mancanza di una patch è in realtà un problema che dovrebbe essere risolto, quindi è perfetto che si presenti nel tuo diff per poterlo risolvere insieme all'aggiornamento.

Non penso che avere un Magento nel repository del progetto sia inizialmente una buona idea, nel caso in cui gestisca più di 2-3 clienti. Dal momento che è sempre più facile confondere le patch di sistema applicate con hack core.

L'opzione migliore, a mio avviso, è quella di avere un mirror repository Magento del compositore con tag di versione, che punta a una particolare versione di Magento con possibili patch ufficiali applicate.

Inoltre, sarebbe più semplice mantenere le tue patch sui file, come Mage_Core_Model_Config per siti Web ad alto carico e alcuni altri, introducendo la loro installazione tramite compositore con un numero di versione corrispondente alla tua installazione di Magento.

Quindi, in questo caso, l'aggiornamento di tutti i progetti dei clienti a un codice Magento con patch comporterà solo il bump della versione del file del compositore. Inoltre, mantenendo il codice del progetto separato dal core, costringerai i tuoi sviluppatori a non hackerare il core.

Per quanto riguarda la definizione di patch e hack, preferirei chiamarlo così:

1. Una modifica del file core originale con il file patch ufficiale: è una patch
2. Una modifica del file core originale da parte del tuo team: è un hack.
3. Una modifica nel file core copiato locale ai fini della correzione di bug - è una patch
4. Una modifica al file core copiato locale per fornire nuove funzionalità: è un hack

Quindi, spostando il core in un repository separato, ti assicurerai di avere solo la versione patchata in base al punto 1. E puoi facilmente installare le tue patch sul compositore nel pool di codice locale, quindi hai tutto secondo il punto 3. In caso di 2 e 4 è possibile creare un hook di commit git nel repository di progetto per proibire qualsiasi commit del codice in quella directory.

Guardo il file di patch applicato in quella /app/etc/cartella e lavoro all'indietro. Ma come ho appreso dall'aggiornamento, posso semplicemente eliminare il file su una versione che ha il file patchato in loro e la prossima volta che è patchato è pulito.

Qualunque cosa da Magento chiamerei una patch. Tutto il resto è un trucco.