Come gestisci efficacemente i rilasci senza perdere troppo tempo? L'ambiente di lavoro è Eclipse, Java, Subversion

OK, non sono aggiornato sul tuo stack, ma nella mia esperienza, una volta che inizi a parlare di rilasci e affidabilità, guardi a giorni, se non settimane, di controllo qualità e gestione dei rilasci.

I 30 minuti di branching e 1h di programmazione per correggere un bug sono sminuiti dai test. anche se lo automatizzi.

10min - Create hotfix branch from correct version of software
30min - Repeat bug locally
1h    - write failing unit test
1h    - implement bug fix
10min - run all unit tests locally
30min - merge hot fix branch back in, build in CI environment, run unit test
24h   - run automated UI tests
30m   - deploy to test/qa envrioment/machines
1wk+  - manual QA/exploratory testing and sign off
1wk+  - schedule live deployment date, rollback plan etc
1day  - manual deployment to live blue, watch graphs, bug reports etc
1day  - wait to see if there are bugs
2h    - manual deployment to green

Possiamo migliorare con strumenti e test di implementazione automatizzati, ma ciò che non possiamo ridurre è il tempo necessario affinché gli esseri umani acquisiscano sicurezza in quanto la nuova versione è "sicura"

Per aggirare questo popolo, prendi due approcci

1: raggruppa le modifiche in un'unica grande pubblicazione mensile / trimestrale

Questo significa che esegui il test finale una sola volta (supponendo che non ci siano errori) piuttosto che per correzione. Permette anche di valutare il software nel suo insieme, che tende ad essere più indulgente. vale a dire, abbiamo ancora questo bug qui, ma nel complesso è migliorato.

Un altro vantaggio è che devi sperimentare il dolore una volta al mese, tutte le riunioni, ecc. diventano più di routine e c'è urgenza per il business di rilasciare piuttosto che il rollback e aspettare il prossimo slot mensile.

2: Dividi la tua app in molti piccoli servizi o componenti e rilasciali separatamente

Ciò significa che ogni singola modifica è più piccola e ha un rischio definito. È più semplice rispondere alla domanda "cosa potrebbe andare storto", il che significa che alcune piccole modifiche possono essere rilasciate con meno o nessun controllo.

Modifica:

È una perdita di tempo? beh immagino che dipenda da quanto apprezzi l'affidabilità. Fondamentalmente qualsiasi cambiamento che fai potrebbe andare storto in modo imprevisto. Se non provi che TUTTO funziona prima di rilasciare una modifica, allora qualcosa potrebbe non funzionare.

Ma il test non è perfetto, quindi anche se pensi di aver provato tutto, potresti aver perso qualcosa. Puoi solo ridurre il rischio e valutare quale livello sei disposto ad accettare per ottenere il beneficio del cambiamento.

Quanto sono costosi i bug per i tuoi clienti? Cioè, hanno davvero bisogno di essere riparati al più presto, o preferiscono piuttosto la stabilità in uno status quo?

Quanto è costoso un errore nel tuo prodotto? Cioè, la spedizione di un bug è una seccatura o è fatale?

Per un prodotto con costosi bug (ad es. software di contabilità o sistemi di controllo dell'aeromobile), avresti cicli di rilascio lunghi, versioni cumulative rare e una grande parte del tempo speso per i test manuali creativi.

Dal momento che i tuoi utenti vivono attualmente sul bordo vivo, quanto sopra non deve essere la tua area.

Per un prodotto con bug poco costoso, avresti cicli di rilascio molto rapidi, per lo più test automatici e potenzialmente più rilasci al giorno.

Più piccola è una versione, meno test di creatività hanno bisogno, perché una modifica è piccola e il suo impatto in qualsiasi altra parte del sistema è in genere pari a zero. Più piccolo è l'insieme di modifiche, più piccole sono le possibilità della loro interazione imprevista.

Inoltre, minore è il cambiamento nella nuova versione, più è facile tornare alla versione precedente nota. (Essere in grado di farlo in pochi minuti è sempre utile.)

Quindi, "rilascia presto, rilascia spesso".

Diventa un tecnico di rilascio; di solito le persone prendono turni facendo rilasci. L'ingegnere del rilascio (di oggi) determina quando tagliare il rilascio, cioè quali modifiche sono incluse in esso, assicura che la generazione del ramo di rilascio sia fatta e testata automaticamente, quindi esegue alcuni test manuali delle modifiche che non lo fanno avere test automatici (es. sottigliezze dell'interazione dell'interfaccia utente).

Se una versione supera i test, la versione viene promossa nello stato "blu" ("beta", "canarino"); viene trasferito un po 'di carico di produzione o reso disponibile per il download da parte dei clienti che hanno sottoscritto versioni beta.

Se un rilascio fallisce un test, il rilascio viene posticipato e il problema viene comunicato a chiunque sia responsabile. Se una correzione è banale, può essere trasferita al ramo di rilascio e il processo si ripete. Se la correzione è grande / richiede molto tempo, il rilascio può essere annullato o uno stato precedente del ramo principale può essere tagliato come ramo di rilascio.

A mio parere, con un setup come questo, una release non dovrebbe essere un grosso problema, qualcosa che richiede molto sforzo intellettuale. Ci vorrà del tempo per gestire tutto questo, però. Assegna questa volta; misurare il tempo effettivamente speso e regolare. La vincita è costituita da un numero inferiore di correzioni di bug (al contrario di bleeding edge), e più veloci (invece di essere rilasciate una volta all'anno). Di solito ne vale la pena.