Strumenti per la gestione del processo di promozione delle applicazioni in un ambiente aziendale

Question

Sono curioso di sapere come altri gestiscono la promozione del codice da DEV a TEST a PROD all'interno di un'azienda.

Quali strumenti o processi usi per gestire il lato "criteri burocratici", criteri di entrata / uscita?

La mia attuale organizzazione è per metà bloccata tra alcune funzionalità di tipo di moduli online personalizzati e dipendenze cartacee per inviare documenti, raccogliere approvazioni e recensioni.

Tutto ciò è lasciato nelle mani dei project manager per tenere traccia di ciò che è stato inviato, superato la revisione, approvato e avvisato la direzione in caso di blocchi che potrebbero richiedere l'approvazione per essere "trascurati". prima che un'applicazione possa essere promossa nell'ambiente successivo.

Un'applicazione basata su browser sarebbe l'ideale ... quindi cosa c'è là fuori? per favore mostrami che googlefu è meglio del mio.

Answer 1

È difficile trovarne uno buono tramite Google. Esiste una vasta gamma di strumenti per la gestione dei problemi, quindi menzionerò ciò che utilizziamo e ciò che vorremmo usare.

Attualmente utilizziamo i prodotti Serena. Hanno funzionato bene per noi in passato. Team Track è la nostra gestione dei problemi e gestisce il ciclo di vita di qualsiasi problema su cui lavoriamo. Version Manager è il nostro controllo del codice sorgente e ha la funzione di implementare gruppi promozionali come DEV TEST e PROD. Usiamo DEV, TSTAGE, TEST, PSTAGE e PROD per indicare il movimento dall'uno all'altro, ma è praticamente lo stesso. I due prodotti si integrano perfettamente in modo che l'origine associata ai problemi sia collegata, ma non abbiamo un'impostazione del processo di creazione in questo ambiente. È costoso, ma funziona bene.

Stiamo cercando di passare a un sistema più comune usando Jira per la gestione dei problemi, Subversion per il controllo del codice sorgente, Fisheye per collegare i due insieme e Cruise Control per la gestione delle build. Questo è meno costoso, ammonta a poche migliaia per una lisence aziendale e offre tutte le stesse funzionalità ma con l'ulteriore vantaggio di SVN che è un mangager di versione codice molto carino.

Spero che sia d'aiuto.

Answer 2

Ci sono alcuni scenari diversi che ho vissuto negli anni:

Dev - > Test: di solito esiste una data di blocco del codice che interrompe il lavoro su nuove funzionalità e ottiene un ambiente di test con il codice che è stato taggato / etichettato / archiviato che viene creato. Questo viene quindi copiato sulle macchine e i test vanno bene. Questo è di solito anche il meno dettagliato di qualsiasi spinta.

Test- > Prod: questo richiede il piccolo cambiamento che la produzione deve ridurre, il che può significare che una "pesca passata" la pagina sale o IIS non ha siti in esecuzione e il codice viene copiato di nuovo. Ci sono casi speciali in cui un bilanciamento del carico può fungere da interruttore in modo che la promozione avvenga e nessuno dei clienti subisce tempi di inattività poiché quelli sul server precedente si sposteranno al termine della sessione.

Per approfondire quell'idea dello switch, la configurazione prevede di avere 2 server potenzialmente attivi con un solo server che richiede che il bilanciamento del carico invii tutto il traffico a una macchina che può essere commutata quando l'altro server ha il codice aggiornato per andare in diretta.

Può esserci anche un ambiente di gestione temporanea che si trova tra test e produzione in cui il processo è simile in termini di una data prestabilita quando si verifica la promozione.

Dove un tempo lavoravo ci sarebbero stati giorni di unione in cui uno sviluppatore ha trascorso la maggior parte della giornata a fondere il codice Perforce in modo che potesse essere promosso da un ambiente all'altro.

Ora ci sono un paio di casi in cui questo non viene utilizzato:

" Hotfixes " o " Hot patch " si sarebbe verificato dove lavoravo e in questo caso i file specifici venivano copiati negli ambienti di gestione temporanea e di produzione da soli poiché la modifica del codice doveva entrare in produzione al più presto da quando qualcosa si è rotto in produzione o qualcosa di nuovo che doveva essere fatto ci vogliono 2 minuti. In questo caso, la modifica del codice che veniva inviata doveva essere rivista e approvata prima di uscire.

Questi sono i diversi approcci che ho visto usati in cui generalmente ci sono programmi e scadenze che devono potenzialmente essere cambiati o risorse aggiuntive introdotte per fissare una data difficile come se una conferenza è in un particolare fine settimana che tale e tale è pronto per quello.

Ovviamente in alcuni punti c'è stato, " Oh, è stato rotto? Fammi vedere ... " e qualche minuto dopo, "No, vedi che non è rotto per me", dove qualcuno ha cambiato le cose senza chiedere il permesso o qualcosa in cui un'azienda ha ancora ciò che chiamano "programmazione da cowboy". "

Un altro punto è la scala del rilascio: 1) Minuscolo: questo è il caso in cui una pagina Web viene visualizzata in modo che l'utente X possa eseguire Y.

2) Piccolo - Una manciata di file che non è davvero complicato ma non è esattamente banale.

3) Medio: dove passare da un ambiente all'altro richiede la modifica di un mucchio di file e di solito ha degli script da spostare.

4) Grande: dove ci sono promozioni in programma e ai vari sviluppatori viene chiesto chi sta effettuando i turni al termine della trasmissione live. Ho avuto questo in un caso in cui c'era una migrazione di dati da fare oltre a una versione di alcuni nuovi siti di e-commerce.

5) Mammut: dove tutto è nuovo di zecca, incluso come verrà utilizzato. Non credo di aver mai visto una di queste dimensioni, ma immagino che Microsoft o Google avrebbero versioni di queste dimensioni.

Da qualche parte in quello spettro cadono la maggior parte dei rilasci e quindi quanta pianificazione e preparazione possono variare un po 'e non dimentichiamo che la conformità normativa può essere la sua pena nel portare a termine alcune cose.