Repository per codice opensource custom

La mia azienda nell'ultimo anno ha optato per l'utilizzo di sistemi e-commerce e CMS opensource per poter proporre soluzioni complete in termini di funzionalità in modo da ridurre al minimo le personalizzazioni al codice applicativo. L'introduzione di questi nuovi sistemi è stata per me molto interessante in quanto, oltre agli sforzi di apprendimento, mi ha portato a scontrarmi con una serie di problemi legati alla gestione del codice che non avevo mai affrontato in modo approfondito:

• mantenere aggiornato il mio codice con quello rilasciato dalla community
• gestire agevolmente le personalizzazioni per ogni cliente.

La risposta(ovvia) è stata quella di utilizzare un sistema di controllo versione, in particolare Subversion gestito tramite il client Tortoise. La scelta è stata mutuata dal fatto di lavorare in ambiente Windows e di avere a disposizione in azienda un server svn, anche se avrei preferito Git considerato più semplice da apprendere. Premesso che non sono un esperto e che non ho nessuna pretesa di fornire una soluzione o una "best pratice", ho pensato di organizzare il mio repository(in seguito repo) in due rami principali invece(dei "classici" trunk, tags e branches) chiamati "versioni_base" e "personalizzazioni": nel primo creo una nuova diramazione per ogni nuova versione rilasciata dalla community, nel secondo ne creo una per ogni personalizzazione(in pratica per ogni cliente).

 repo
  |
  ----personalizzazioni
  |     |
  |     ----clienteA
  |     |
  |     ----clienteB
  |
  ----versioni_base
       |
       ----ver1
       |
       ----ver2

Le operazioni principali che svolgo quotidianamente sono queste:

• creo una nuova personalizzazione come copia di una versione base(tipicamente la più aggiornata) e la modifico con implementazioni necessarie solo per il cliente specifico.
• Implemento una nuova funzionalità che sarà valida per tutte le future release: in questo caso mi risulta comodo fare un merge per integrare la modifica nella personalizzazione(concettualmente un branch) se lo sviluppo è avvenuto su una versione base oppure per reintegrare la modifica implementata nella versione base se è stata fatta per un cliente ma mi sono reso conto che potrebbe essere utile anche per altri.
• Scarico una nuova versione rilasciata dalla community e la importo nel mio repo creando un nuovo ramo in "versioni_base" ed eseguo un merge con la release più aggiornata della versione base precedente che contiene tutte le mie modifiche.

Volendo fare alcune valutazioni su questo schema mi rendo conto che pur risultando abbastanza chiaro(beh, facile che sia chiaro a me, voi che ne dite?) si potrebbe pensare di utilizzare un solo ramo per la versione base in cui head(la versione corrente del repo) punti sempre all'ultima versione con implementate le aggiunte e identificare le versioni precedenti attraverso la creazione di tags. Si potrebbe anche fare lo stesso ragionamento per il ramo delle personalizzazioni ma su questo sono abbastanza convinto che la separazione dei rami dei clienti porti una maggiore chiarezza. In conclusione questa soluzione mi risulta comoda, almeno per ora, mi riservo di verificarne la bontà al crescere del numero di release e di valutare eventuali suggerimenti in merito.