Abbiamo iniziato con uno sviluppatore e un repository svn contenente tutto il nostro codice:
^/foo/trunk/module-a
^/foo/trunk/module-b
^/foo/trunk/module-b/submodule-b1
^/foo/trunk/website1
(al momento questo è stato un grande miglioramento). Dopo che ciò ha avuto la possibilità di crescere per un po ', abbiamo iniziato a riscontrare problemi con dipendenze circolari, test di ricerca lenti e difficoltà generali nel riutilizzo del codice (dal momento che, ad esempio, il set di funzionalità di website1 si era insinuato nel modulo-a altrimenti generico).
Volendo modulare la base di codice e aspettandoci di passare a git a breve (e avendo letto da qualche parte che a git non piacciono i mega-repository svn), siamo passati a una struttura molto più granulare:
^/module-a/trunk/
^/module-b/trunk/
^/module-b/trunk/sumbmodule-b1
^/earlier-sub-sub-sub-module-c/trunk
etc. (about 120 such modules)
Questo è stato concettualmente fantastico. Codice più modulare, suite di test molto più veloci, più facile da documentare, ecc. Abbiamo acquisito alcuni dei nostri componenti più generici e reso installabili tutti i moduli pip (usando pip install -e .per installarli in developmentvirtualenv).
Abbiamo creato un ^/srv/trunkrepository contenente la struttura di cartelle dell'ambiente di runtime, ad es. ^/srv/trunk/libper i moduli, /srv/trunk/srcper i resti di ^/foo/trunk, ^/srv/trunk/wwwper siti Web ecc.
E infine (prendendo un'idea da perforce, con cui ho lavorato molto tempo fa [ https://www.perforce.com/perforce/r12.1/manuals/cmdref/client.html] ) abbiamo creato un "vcs- recuperare "file di testo che elenca tutti i repository rilevanti e dove devono essere estratti nell'ambiente di sviluppo e un comando corrispondente per farlo. Ad esempio una linea vcs-fetc:
svn srv/lib/module-a ^/module-a/trunk
causerebbe entrambi (la prima volta)
cd /srv/lib && svn co ^/module-a/trunk module-a
o (in seguito)
cd /srv/lib/module-a && svn up
e allo stesso modo per i repository github (sia i nostri pacchetti fornitori che quelli alterati / inalterati).
Abbiamo usato lo stesso processo di vcs-fetch per creare l'ambiente di produzione, ma stiamo rapidamente scoprendo che non abbiamo modo di sapere quale versione era utilizzata in prod dopo aver eseguito un vcs-fetch.
Con il mega-repository, potremmo solo notare il numero di revisione prima di aggiornare prod da trunk, e tornare indietro era un semplice passo indietro svn -r nnn up .. Con il codice sia in svn che in git (e un modulo in hg) - e ~ 120 repository, non è ovvio come farlo.
Ho letto http://12factor.net/ oggi e il primo fattore è "One codebase", quindi mi chiedo anche se sono fuori strada giusta qui?
Un'idea che ho avuto è stata quella di creare uno script di distribuzione in grado di creare ruote di "distribuzione" installabili tramite pip e "raggrupparle" in un requirements.txtfile. Una distribuzione implicherebbe quindi la creazione di un nuovo virtualenv, l'installazione pip del file requisito.txt che elenca le ruote di distribuzione e il cambio del virtualenv attivo. Il ritorno al precedente implicherebbe semplicemente il ripristino della virtualenv (ma a meno che non volessimo mantenere la virtualenv in giro per sempre, non ci permetterebbe di tornare indietro nel tempo - nella mia esperienza che non è mai stata necessaria).
A questo punto mi chiedo se sto camminando nella direzione sbagliata o se non ho camminato abbastanza lontano sulla strada giusta ..? (tutto quello che sto leggendo continua a parlare della "tua app", e non so come questo si traduca nella gestione di 14 siti Web al di fuori della stessa base di codice ...)