Git repo structure per un plugin che si rivolge a più versioni della piattaforma

0

TLDR: alla ricerca di git-flow come le convenzioni del flusso di lavoro adeguate allo sviluppo di estensioni destinate a più versioni della piattaforma host.

Nella nostra azienda sviluppiamo estensioni per una piattaforma di siti Web PHP. Ci sono attualmente tre versioni principali della piattaforma in natura e abbiamo adottato la seguente politica per nuove funzionalità e correzioni di bug: la versione più vecchia della piattaforma ottiene solo correzioni di bug (poiché pochissimi client la usano ancora), mentre le altre due entrambe ottieni nuove funzionalità. Poiché alcune correzioni di bug riguardano anche solo specifiche versioni della piattaforma, abbiamo fatto ricorso al versioning separato per le tre versioni specifiche per la versione della piattaforma dell'estensione.

Le differenze tra le versioni della piattaforma sono sia semplici riorganizzazioni della struttura file che modifiche comportamentali in classi situate sotto lo stesso percorso in tutte e tre le versioni, quindi le tre versioni delle estensioni differiscono anche nella struttura delle cartelle e nelle differenze di codice più piccole dove il core modificato viene utilizzata la funzionalità.

Un esempio: la parte MVC della piattaforma forza la convenzione di denominare le classi con l'intero percorso del file in cammello come ControllerModuleMyfile per un file /controller/module/myfile.php. Una delle versioni più recenti della piattaforma ha cambiato la directory per i controller di estensione, quindi, anche se il codice non cambia, la posizione del file e il nome della classe devono ora essere ControllerExtensionModuleMyfile per un controller / extension / module / myfile corrispondente .php.

Finora abbiamo semplicemente usato rami separati per ogni versione della piattaforma e per aiutare con gli errori del tipo "ho dimenticato il ramo in cui ero così ho aggiunto il file nella cartella sbagliata", la cartella di origine principale è suffragata con l'appropriato versione della piattaforma per quel ramo (src_10, src_20, src_30 per le versioni di piattaforma 1.0, 2.0, 3.0). Non ci sono dev, feature, hot-fix o release branch, tutto lo sviluppo avviene sul ramo "master" per la versione specifica (generalmente non è un problema, poiché raramente abbiamo più di una persona che lavora su un'estensione allo stesso tempo e lo sviluppatore è responsabile dell'aggiornamento di tutte le versioni con tutte le modifiche apportate). Tutto il codice comune viene semplicemente copiato tra i rami.

Ciò significa che ogni volta che una nuova funzionalità o correzione di un bug viene completata per una versione, dobbiamo principalmente trasferire o selezionare manualmente tali modifiche agli altri rami (non sempre a tutti gli altri rami a causa della versione più vecchia che riceve solo correzioni). / p>

Credo che un buon inizio per districare il caos che è successo con le nuove versioni della piattaforma in uscita nel corso degli anni, è di avere almeno tutte le cartelle src_xx su un ramo e separare il codice comune in una cartella src_common che sarebbe unito al codice specifico della versione appropriato come parte del processo di compilazione / imballaggio. Ciò si presterebbe meglio a flussi di lavoro come git-flow, con la mia preoccupazione principale di come affronteremmo la situazione in cui un pezzo di codice comune deve diventare specifico per la versione.

Dato che mi piace git-flow per progetti con meno versioni difficili, avrebbe senso avere più rami master e dev per ogni versione? La mia preoccupazione qui è che vorrebbe dire avere un sacco di rami di lunga vita che renderanno il repository piuttosto difficile da navigare e incline agli errori. La ricerca rapida / facile è una caratteristica desiderata, poiché offriamo anche il supporto per le estensioni e lo sviluppatore che gestisce la custodia potrebbe non essere quello che ha sviluppato l'estensione.

Infine, indipendentemente dalle discussioni sul git-flow, c'è qualche ragione nel provare a usare git subtrees o submodule per alleviare in qualche modo il problema di mantenere più versioni della stessa estensione in sincrono?

    
posta mtsvetkov 20.10.2017 - 17:30
fonte

0 risposte

Leggi altre domande sui tag