Qual è il tuo flusso di lavoro di distribuzione dell'app Web preferito con SVN?

Question

Attualmente stiamo utilizzando una configurazione di distribuzione piuttosto complicata che coinvolge un server SVN remoto, 3 rami SVN per DEV, STAGE e PROD, promuovendo il codice tra loro tramite patch, ecc.Mi chiedo cosa usi per la distribuzione in una situazione di piccolo team di sviluppo?

Answer 1

trunk per lo sviluppo e un ramo (produzione) per il materiale di produzione.

Sul mio computer locale ho un VirtualHost che punta al ramo del trunk per testare le mie modifiche.

Qualsiasi commit sul trunk attiva un hook di commit che esegue un'esportazione svn e si sincronizza con l'URL di sviluppo del server online, quindi se il sito è stackoverflow.com, questo hook aggiorna automaticamente dev.stackoverflow.com

Quindi utilizzo svnmerge per unire le patch selezionate dal trunk alla produzione nei miei checkout locali.Ho di nuovo un VirtualHost sul mio computer locale che punta al ramo di produzione.

Quando invio le modifiche unificate al ramo di produzione, ancora una volta un hook di esportazione SVN aggiorna l'esportazione di produzione (live) e il sito è attivo!

Answer 2

Quando lavoravo in un piccolo team di sviluppo (piccolo intendevo io, un altro programmatore e il capo), era piuttosto un caos caotico.Tuttavia, abbiamo scoperto che l'assegnazione di un tipo di processo "gatekeeper" ha funzionato per noi.

Il gatekeeper era la persona che aveva svolto la maggior parte del lavoro sull'app (in questo caso, io avevo 2 progetti sviluppati da zero, lui ne aveva circa 4).

Fondamentalmente, ogni volta che doveva lavorare sui miei progetti, mi avvisava che stava lavorando, mi assicuravo che il repository fosse aggiornato e costruibile, poi lo tirava giù, apportava le sue modifiche, quindi eseguiva il commit .Mi avrebbe informato che era stato fatto, avrei demolito, costruito e distribuito.Se c'erano modifiche al DB, avevamo una cartella Modifica DB con tutti gli script che avrebbero corretto il DB.

Ovviamente ha molti buchi, ma il processo ha funzionato per noi e ci ha impedito di costruire uno sull'altro.

Answer 3

Non ho avuto problemi con l'organizzazione di tag/rami/tronco comuni.

Lo sviluppo generale in corso avviene nel bagagliaio.

Il mantenimento di una release in produzione avviene nel ramo di release appropriato.

Le modifiche al ramo di rilascio che sono ancora rilevanti per il trunk vengono unite.

Quando una nuova versione è pronta per la distribuzione, viene taggata dal trunk, quindi viene creato un ramo da quel tag.Il nuovo ramo di rilascio viene estratto sul server, parallelamente al rilascio corrente.Quando è il momento di cambiare, i percorsi vengono manipolati ("mv appdir appdir.old && mv appdir.new appdir").

Gli sviluppatori che supportano la versione di produzione svn trasferiscono la loro copia di lavoro nel nuovo ramo o eseguono un nuovo checkout da esso.

Answer 4

Tre rami sembrano semplicemente un lavoro extra.

Le differenze ambientali possono essere gestite avendo diverse versioni dei file rilevanti nel trunk.cioè.database.yml & database.yml.prod.Il processo di distribuzione dovrebbe essere rispettoso dell'ambiente e copiare semplicemente i file per ambiente su quelli predefiniti.

Answer 5

Un semplice ramo del tronco contiene il codice più aggiornato, quindi tagliamo un ramo ogni volta che andiamo in diretta.Sembra funzionare in modo abbastanza efficace.Puoi facilmente passare al ramo precedente ogni volta che il ramo corrente che hai tagliato per il sistema live fallisce.Inoltre, è facile correggere i bug sul ramo che è attualmente attivo, e poiché il ramo effettivamente muore quando ne tagli uno nuovo, c'è sempre e solo 1 ramo reale su cui devi lavorare (e poi unire le correzioni da lì al ramo ramo vivo).

Answer 6

Non utilizziamo i rami per mettere in scena cose relative al web;solo per testare cose sperimentali che richiederanno molto tempo (leggi:più di un giorno) per riunirsi nuovamente nel trunk.Il bagagliaio, in stile "integrazione continua", rappresenta uno stato attuale (si spera) funzionante.

Pertanto, la maggior parte delle modifiche viene applicata direttamente al trunk.Un server CruiseControl.NET si aggiornerà automaticamente su un computer che esegue anche IIS e dispone di copie aggiornate di tutte le risorse aggiuntive del sito, in modo che il sito possa essere testato internamente in modo completo e pulito.Dopo il test, i file vengono caricati sul server pubblico.

Non direi che sia l'approccio perfetto, ma è semplice (e quindi adatto al nostro personale relativamente piccolo) e relativamente sicuro, e funziona perfettamente.

Answer 7

Trunk contiene l'attuale codebase di sviluppo "primario".

Uno sviluppatore creerà spesso un ramo individuale per qualsiasi progetto a medio e lungo termine che potrebbe intasare la base di codice del trunk e intralciare gli altri sviluppatori.Quando avrà finito si fonderà nuovamente nel bagagliaio.

Creiamo una versione con tag ogni volta che inseriamo il codice in produzione.La cartella in /tags è semplicemente il numero di versione.

Per eseguire la distribuzione in produzione, stiamo eseguendo un'esportazione SVN in staging.Quando ciò è soddisfacente, utilizziamo un semplice rsync per distribuirlo ai cluster di produzione.

Answer 8

Consiglio vivamente il libro (attualmente in versione approssimativa) Consegna continua, che descrive un processo completo per la gestione della distribuzione del software, basato su principi di integrazione continua (tra gli altri).

Non mi piace molto l'approccio di ramificazione e fusione, poiché può diventare molto disordinato ed è piuttosto dispendioso poiché si finisce per dedicare tempo ad attività che in realtà non forniscono alcun nuovo valore.Hai già sviluppato, testato e corretto il tuo codice una volta, perché creare una situazione (copiare il codice in un altro ramo) che richiede di ripetere questo lavoro?

Ad ogni modo, il modo per evitare ramificazioni e fusioni è creare i tuoi artefatti distribuibili dal trunk e promuovere gli artefatti costruiti (piuttosto che la fonte) mentre supera il test, la messa in scena, ecc.In questo modo sei sicuro al 100% che quello che stai mettendo in produzione è lo stesso che hai testato.

Se disponi di funzionalità diverse che potrebbero dover essere rilasciate in tempi diversi, cambiare il tuo approccio al modo in cui le implementi (rendere la funzionalità configurabile o, meglio ancora, modulare) può aiutarti a mantenere un unico trunk di sviluppo.

Answer 9

Usiamo il branching del rilascio: questo sembra essere più efficiente per noi rispetto al branching delle funzionalità che stavamo facendo.

Non creare rami diversi per i diversi ambienti.

Answer 10

Personalmente lavoro localmente (sviluppo), aggiungendo/correggendo funzionalità e quando penso che sia pronto mi impegno al trunk (produzione).Sul server di produzione eseguo semplicemente un aggiornamento svn.

Answer 11

Lavoro con una situazione simile a quella che hai attualmente.Mi è stato assegnato il compito di trovare una soluzione "migliore" e funzionava sulla falsariga di quanto segue.

Il ramo live rappresenta i server nel loro stato attuale.

Qualsiasi lavoro di sviluppo dovrebbe essere svolto in un ramo preso da live.Potrebbe trattarsi di un lavoro di mezz'ora per una persona o di un progetto multi team della durata di un anno.Tutte le volte che si desidera, i cambiamenti di vita possono essere integrati in questi rami di sviluppo.

Prima che un lavoro venga pubblicato, le modifiche dal live vengono nuovamente unite e vengono contrassegnate come potenziale versione.Questa versione viene testata sull'ambiente di staging e se supera il test la nuova live viene presa dal tag.

È possibile unire più parti di lavoro in un'unica versione se funziona meglio.

Ciò significa che è abbastanza semplice mantenere aggiornati i rami di sviluppo con live e se un pezzo di lavoro in sviluppo viene abbandonato c'è una riordinazione minima da fare.

Per passare dal lavorare su un progetto a un altro, uno sviluppatore può semplicemente cambiare il proprio ambiente di lavoro locale in un ramo diverso.

Uno dei problemi che abbiamo avuto con il sistema come descrivi è che DEV può diventare obsoleto con PROD abbastanza rapidamente, quindi non stai sviluppando rispetto al live e non è facile individuare le dipendenze incrociate fino alla fase.La soluzione di cui sopra risolve questi problemi pur rimanendo abbastanza leggera.