Ingegneria delle versioni Lean Software (Webapplication)

Question

Sto cercando di riorganizzare il modo in cui rilasciamo il nostro software interno. Tutto il codice (webapp PHP, alcune app Java e script Perl) viene controllato nei repository Subversion ma non ci sono rami o tag, tutto viene archiviato nel trunk (solo circa 1-3 sviluppatori per app). Sui server Linux di produzione, il software viene eseguito direttamente da una copia svn funzionante (in realtà la maggior parte delle modifiche avviene anche lì).

Dal momento che abbiamo molte piccole app e rilasciamo molto spesso piccole modifiche al sistema in esecuzione, sto cercando un modo molto snello o trasparente per fare un po 'di ingegneria di rilascio e ripulire questo disastro abit.

Esistono strumenti là fuori che possono aiutarmi a farlo in un ambiente eterogeneo (dal punto di vista linguistico) del genere? O qualcuno ha idea di come farlo in modo corretto?

Altrimenti avrei pensato di scrivere alcuni script di rilascio (shell) che creavano automaticamente tag di sovversione dal trunk e quindi facevano un checkout del tag corrispondente sui server di produzione. Ma a me sembra un po 'hack'ish.

Grazie,

Haes.

Answer 1

L'integrazione continua è sicuramente la strada da percorrere - qualsiasi elemento della configurazione (anche file batch minimalisti) è meglio di nessuno - ma sarà solo buono come le politiche che hai in atto. Dato che i tuoi file non finiscono per essere "binari" o "distribuibili", la marcatura di una versione potrebbe richiedere semplicemente che tu tagghi il repository, o addirittura nascondi il numero di revisione di Subversion da qualche parte. L'importante politica di cui hai bisogno è che qualsiasi versione può essere ricostruita ogni volta che ne hai bisogno, in modo da poter confrontare le versioni attuali e precedenti o tornare a una versione precedente se qualcosa va storto. Non preoccuparti del "sovraccarico" della creazione di tag in svn: è molto efficiente.

Uno script di rilascio che fa il tag subversion suona bene. Un'implementazione CI (consiglierei CruiseControl poiché è ideale per lavori eterogenei, sebbene l'eterogeneità richieda un po 'più di sovraccarico di configurazione) è ottima, dal momento che puoi avviare automaticamente il processo su un check-in di sovversione ed eseguire test automatici che determinano se è buono abbastanza per taggare o meno.

Sicuramente non mi distribuirei automaticamente su un server di rilascio. Sarebbe meglio una 'area di stadiazione' (chiamala 'build notturno', 'beta test', qualunque cosa). Consenti ai tuoi utenti di battere su questo prima di decidere che è abbastanza buono da implementare sui server di produzione. E, fintanto che hai la politica al posto di poter eseguire il rollback a una versione precedente, hai mitigato la possibilità di un roll-out errato.

L'auto-checkout sui server di produzione è l'unica parte 'hackish': un checkout automatico, test, tag, distribuzione beta è abbastanza fluido. Il lancio sulla produzione non dovrebbe avere un pulsante facile, tuttavia.

Answer 2

Usa tag e rami; renderlo parte del ciclo di sviluppo. Quando aggiorni quella "stabile-1.0" ramo, hai testato le modifiche e l'ho taggato " release-1.0.5 " semplicemente fai " svn switch " sul server per il nuovo tag. Non ha funzionato, nonostante l'avesse testato? Torna indietro e scopri cosa c'è che non va.

Ma attenzione, ramificarsi nella sovversione può essere un dolore, almeno prima della versione 1.5. Se tu o i tuoi sviluppatori non avete esperienza con i rami, aspettatevi un po 'di seccature e / o errori all'inizio. Ma fintanto che hai commesso nessun codice dovrebbe essere perso (nel peggiore dei casi semplicemente difficile da unire).

I tuoi sviluppatori dovrebbero davvero imparare a usare la ramificazione; può essere molto utile per vari scopi (non solo per l'ingegneria delle versioni).

non commuta automaticamente il codice sui server di produzione; qualcuno potrebbe accidentalmente premere il pulsante sbagliato. Gli aggiornamenti della produzione devono sempre essere eseguiti con cura. Gli script per l'aggiunta di nuovi tag non sono necessari a causa della sua semplicità, ma il tuo chilometraggio può variare.

Un'ultima cosa, non permettere a nessuno di avere modifiche sul tuo server di produzione. Potrebbe causare conflitti e questi tendono a richiedere del tempo per risolversi. Per non parlare, distrugge la tua capacità di riprodurre una determinata versione su diverse workstation (funziona bene qui! Perché non sul server? Hmm).

Answer 3

Alcuni server di integrazione continua fanno questo genere di cose, Hudson , ad esempio, ha l'integrazione di sovversione. Può taggare, eseguire test e distribuire per te.

Answer 4

Vorrei usare Hudson. oltre a recuperare e taggare in svn (ref sblundy), può essere utile nella gestione delle versioni con il plugin . ad esempio, puoi provare un plugin per " promuovere " ; le build che distribuisci alla produzione e mantieni un elenco delle build promosse stesse e un registro delle modifiche / commit per le varie versioni.