Ciclo di rilascio di una settimana: come posso renderlo fattibile?

Nella mia azienda (3 anni di startup nel settore web), abbiamo frequenti problemi con il team del prodotto che dice "aaaah questa è una patch di crisi adesso!" (non tutti?)

Ciò ha un impatto sulla produttività (e sul morale) del personale tecnico, incluso se stesso. Il management ha trascorso un po 'di tempo a pensare a come ridurre la frequenza di queste richieste in giornata e ha escogitato la soluzione che avremo un rilascio ogni settimana. (In precedenza ne avevamo fatto uno ogni due settimane, che di solito scivolava da un paio di giorni circa.)

Ci sono 13 sviluppatori e 6 tester locali / 9 offshore; la teoria è che solo 4 sviluppatori (e tutti i tester) lavoreranno su versioni con numero pari, a meno che non emerga un pezzo di lavoro che richiede davvero una competenza specifica da parte di uno degli altri sviluppatori. Ogni ciclo conterrà due giorni di lavoro di sviluppo e due giorni di lavoro di controllo qualità (più 1 giorno di scoping / triage / ...).

Le mie domande sono:

(a) Qualcuno ha esperienza con questa durata del ciclo di rilascio?

(b) Qualcuno ha sentito parlare di questa durata del ciclo di rilascio persino tentato?

(c) Se (a) o (b), come mai la fai funzionare? (Sono anche apprezzate eventuali insidie ​​da evitare, ecc.)

(d) Come possiamo minimizzare il danno se questo sforzo fallisce?

Puoi certamente consegnare ogni settimana - o anche più frequentemente. Al momento rilasciamo generalmente ogni due settimane, ma non è insolito implementare funzionalità quando qualcosa è arrivato senza preavviso da uno dei nostri partner che sarebbe irrilevante se aspettassimo il ciclo successivo. Ad un certo punto nei prossimi mesi mi piacerebbe che passassimo alla consegna continua (gli articoli vengono rilasciati non appena è pratico una volta che sono stati "fatti") come standard, ma non siamo ancora abbastanza sicuri di procedere lontano.

La cosa fondamentale è che hai bisogno che il tuo sito web sia fortemente coperto da test automatici - sia test unitari che test di accettazione end-to-end / specifiche eseguibili. Di conseguenza questo significa anche che la tua build è completamente automatizzata. A livello di accettazione utilizziamo Robot Framework, che è eccellente per creare rapidamente una suite di test gestibile grazie al suo approccio basato su parole chiave. Per quanto riguarda l'aspetto grafico, il nostro tester in loco esegue alcuni controlli superficiali, ma abbiamo anche un paio di ragazzi in India che eseguono un controllo più approfondito su diversi browser (ci sono siti che aiutano in questo tipo di cose prendendo screenshot per te, ad esempio BrowserLab ).

Non automatizziamo completamente la distribuzione (il passaggio finale richiede un intervento manuale, questa è una decisione concisa per noi) - ma automatizziamo tutto ciò come garantire che vengano utilizzate le connessioni corrette al database, ecc., Con brevi cicli di distribuzione sarebbe troppo facile sbagliare con questo genere di cose.

C'è un buon libro recente sulla consegna continua che potresti voler controllare, l'ho scremato ma non l'ho ancora approfondito nei dettagli. Ciò che ho letto finora si adatta bene alle nostre esperienze: Consegna continua: rilasci di software affidabili attraverso automazione di build, test e distribuzione

In sintesi, è necessario un team altamente disciplinato, un elevato livello di automazione e, soprattutto, un livello estremamente elevato di fiducia in tale automazione. A me sembra che passare a cicli settimanali nel tuo caso possa essere un errore: le patch di crisi suggeriscono altri problemi e dovresti lavorare per eliminarli. Aumentare il tempo potrebbe potenzialmente peggiorare la situazione ...

Se sei continuamente in modalità di "rilascio di crisi", direi che sarebbe più prudente fare un passo indietro e rivalutare il tuo codice e il tuo processo. Ovviamente, c'è un qualche tipo di fallimento che continua a ripetersi.

Anche se potrebbe non essere del tutto possibile farlo su una scala di produzione reale, ma probabilmente varrebbe la pena avere almeno un membro senior e altri sottogruppi di sviluppatori e tester dedicati a questa valutazione.

"L'approccio 4 alla volta" non suona come un chiaro vincitore per me. Ciò significa un costante cambio di contesto, il che significa molta meno efficienza.

Ricorda, se sei costantemente in corsa per apportare modifiche, è molto più probabile che tu commetta errori in tali cambiamenti e rompa qualcos'altro mentre lo stai facendo.

Cicli di rilascio più brevi di una settimana sono stati sicuramente raggiunti nel settore del software. Impiegano la tecnica chiamata consegna continua (anche chiamata distribuzione continua ).

C'è un'azienda che rilascia 50 volte al giorno. Questo post sul blog descrive come lo fanno .

Il management ha trascorso un po 'di tempo a pensare a come ridurre la frequenza di questi "lavori di crisi" e ha escogitato la soluzione che avremo un rilascio ogni settimana.

Sembra che il tuo managament sia campione del mondo ... perché non investire nel tuo spirito di squadra? Vedrai che i problemi spariranno da soli.

(a) + (b) IMHO, a seconda delle dimensioni della tua squadra dovrebbe essere di due settimane al massimo. Una settimana lavorerà per spettacoli one man o team molto piccoli (come 2 o 3).

(c) + (d) Ma indipendentemente dalle dimensioni del tuo team o progetto, una delle prime cose che faccio è automatizzare la costruzione e la distribuzione. Risparmio giorni se non settimane di lavoro facendolo nei primi giorni di un progetto.

Le distribuzioni devono essere eseguite con un clic. Dalla fonte alla messa in scena, quindi dalla messa in scena alla produzione. Ci sono molti strumenti per renderlo possibile. Da formica / nant a cose super pesanti come Automated Build Studio .

Tutto può essere automatizzato dalla distribuzione dei file all'aggiornamento del database, inclusi backup, notifiche, rapporti, ...