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 aver avuto la possibilità di crescere per un po 'abbiamo iniziato ad avere problemi con le dipendenze circolari, i testuites lenti e le difficoltà generali nel riutilizzare il codice (poiché, ad esempio, il set di funzionalità di website1 si era insinuato in un modulo generico-a).
Volendo modulare la base di codice, e aspettandoci di passare a git a breve (e avendo letto da qualche parte che git non ama i mega-repos di 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 era concettualmente fantastico. Codice più modulare, suite di test molto più veloci, più facile da documentare, ecc. Abbiamo aperto alcuni dei nostri componenti più generici e abbiamo reso installabili tutti i moduli pip (utilizzando pip install -e . per installarli in development virtualenv).
Abbiamo creato un repository ^/srv/trunk contenente la struttura delle cartelle dell'ambiente runtime, ad es. ^/srv/trunk/lib per i moduli, /srv/trunk/src per i resti di ^/foo/trunk , ^/srv/trunk/www per siti Web ecc.
E infine (prendendo spunto da Forza, che ho lavorato molto tempo fa [ link ) abbiamo creato un file di testo" vcs-fetch "che elenca tutti i repository rilevanti e dove devono essere estratti nell'ambiente dev e un comando corrispondente per farlo. Per esempio. una linea vcs-fetc:
svn srv/lib/module-a ^/module-a/trunk
causerebbe l'uno o l'altro (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 di github (sia i pacchetti dei nostri fornitori sia quelli modificati / non modificati).
Abbiamo utilizzato lo stesso processo vcs-fetch per creare l'ambiente di produzione, ma stiamo rapidamente scoprendo che non abbiamo modo di sapere quale versione è stata utilizzata per produrre dopo aver fatto un vcs-fetch.
Con il mega-repo, potevamo semplicemente notare il numero di revisione prima di aggiornare il prodotto dal trunk, e tornare indietro era un semplice svn -r nnn up . di distanza. Con il codice in entrambi i repository svn e git (e un modulo in hg) - e ~ 120, non è ovvio come farlo ...
Ho letto link oggi, e il primo fattore è "One codebase", quindi mi sto anche chiedendo se sono fuori moda percorso qui?
Un'idea che ho avuto è stata quella di creare uno script di distribuzione che creerebbe "distribuzioni" di installazione di pip e le "impacchetta" insieme in un file requirements.txt . Una distribuzione implicherebbe quindi la creazione di una nuova virtualenv, la pip che installa il file requirements.txt che elenca le ruote di implementazione e che commuta la virtualenv attiva. Ritornare ai precedenti significherebbe solo riaccendere il virtualenv (ma a meno che non volessimo mantenere i virtualenvs per sempre non ci permetterebbe di tornare indietro in qualsiasi momento - nella mia esperienza che non è mai stato necessario comunque).
A questo punto mi chiedo se sto camminando nella direzione sbagliata, o se non ho camminato abbastanza lontano sulla retta via ...? (tutto ciò che sto leggendo continua a parlare di "la tua app", e non so come ciò si traduca nell'esecuzione di 14 siti web con lo stesso codice base ...)