Gli sviluppatori dovrebbero fare i loro rilasci di software (se esiste un team di supporto per i prodotti)?

Ci sono una serie di motivi per cui gli sviluppatori non dovrebbero fare release di produzione. Questo è ancora più importante quando hai un team di supporto alla produzione che deve gestire il codice dopo il rilascio.

Ho una vasta esperienza in piccole organizzazioni e team senza team di supporto alla produzione. Anche in queste organizzazioni sono state fatte uscite come se avessimo un team di supporto alla produzione. Le mie esperienze di supporto alle applicazioni e di sviluppo mi portano a rispettare entrambi i ruoli e le loro diverse esigenze.

Tra i motivi del supporto al passaggio alla produzione:

• Le correzioni possono essere eseguite direttamente in produzione e perse quando verrà rilasciata la prossima versione. (Ho appena violato questa regola per una correzione di configurazione su una riga durante una release di produzione di fine settimana.) Ma puoi scommettere che ho fatto in modo che venisse corretto nella base di codice lunedì. Una correzione più grande è passata dagli sviluppatori ai test di integrazione e poi alla produzione .)
• La configurazione dell'ambiente potrebbe essere inserita nel codice. Ciò si traduce in build di sviluppo, build di test di integrazione e build di produzione. A volte le modifiche non testate o non testate vengono incluse nella build di produzione.
• Il supporto alla produzione acquisisce build che non sanno come eseguire. Questo sembra fantastico per lo sviluppatore indispensabile che ha bisogno di fare tutti i riavvii ma non va bene per l'azienda.
• Il codice di produzione e sviluppo per un rilascio può diventare sempre più diverso. (Una volta ho commesso l'errore di confrontare un codice di sviluppo che doveva essere identico al codice di produzione. Alcuni file erano uguali.)
• Il codice rilasciato è pacchettizzato e configurato in modo più adatto allo sviluppo che alla produzione. È probabile che il team di produzione incoraggi o richieda adeguate funzionalità di packaging e configurazione.
• Le versioni di codice potrebbero non essere taggate nel controllo di versione. Le versioni costruite per la disattivazione devono essere monitorate. Questo potrebbe non succedere, ma è meno probabile che venga ignorato o ignorato se il codice viene "rilasciato" per test o produzione di integrazione.
• Sono possibili micro-rilasci. Ciò rende il supporto un incubo. (Era rotto alle 2:00 ma potrebbe essere stato corretto nella versione 2:15 o 3:05.)

EDIT: il team di supporto alla produzione è uno degli stakeholder del rilascio. È utile se il team di sviluppo collabora con il team di supporto alla produzione per riuscirci. Separare la configurazione specifica dell'ambiente in modo che possano essere mantenute in modo appropriato. È spesso appropriato che il team di supporto alla produzione mantenga la configurazione dell'ambiente.

Credo fermamente che gli sviluppatori dovrebbero fare tutto il necessario per rilasciare il loro codice. Il più grande problema con la delega di responsabilità è che crea molta sfiducia tra le squadre che prendono molti colpi e le squadre che fanno il lavoro. Questa sfiducia e attrito fa sì che entrambe le squadre concentrino i loro sforzi e le loro energie nelle attività antincendio e di puntamento del dito.

Se l'idea è che il tuo team sviluppi un codice di valore che funzioni bene in un ambiente di produzione, il più grande valore deriva da ciò che lo sviluppatore imparerà dal fare tutte le attività da solo. Se non affronta il problema, vedrà tutti gli scontri a fuoco di altre squadre come ostacoli piuttosto che apprendere. Quando vede come ostacolo, semplicemente non impara ma cerca di concentrarsi su come fare cose senza essere individuate dalle altre squadre.

Se fossi un'azienda con i soldi per potermi permettere team specializzati e chiedere zero fallimenti. Metterei in campo alcuni gruppi di esperti liberamente definiti (non vincolanti) e lasciare che lo sviluppatore scelga se vuole che il suo lavoro venga esaminato da loro. Se la versione non riesce, lo sviluppatore sa cosa ha fatto di sbagliato e come può evitarlo. Come cresce nella scala tecnica, potrebbe voler entrare in quelle squadre di esperti.

A causa della pressione dei pari, le persone riesamineranno il loro lavoro dai team di esperti. E creerà anche una migliore relazione tra i team di esperti e gli sviluppatori, portando effettivamente a un lavoro migliore.

Attualmente sto lavorando in una piccola azienda (siamo solo in 4) quindi dobbiamo fare tutto il lavoro (iniziando dalle interviste ai clienti per recuperare informazioni sulle funzionalità, creare documenti di specifiche e implementazione del prodotto finale).

All'inizio era il caos, ma quando ci siamo abituati a svolgere più attività, ci siamo resi conto che se si definiscono i flussi di lavoro e li si normalizzano, tutti dovrebbero essere in grado di fare una parte del processo senza sapere cosa ha fatto l'altro .

Un'altra lezione che abbiamo imparato è: È sempre bene sapere qualcosa su ciascuna parte del sistema. Non intendo il modo in cui è implementato, ma piuttosto ciò che fa. È molto utile quando si creano versioni (come il problema che si menziona) perché lo sviluppatore sta facendo il rilascio, anche se non ha scritto quel codice, sa cosa è per.

Quindi, per riassumere: gli sviluppatori dovrebbero svilupparsi per risolvere un problema. I releasers (penso di averlo appena inventato) dovrebbero pensare al modo migliore per rilasciare una certa soluzione. Se pensi di rilasciare durante lo sviluppo, il tuo codice non sarà così pulito e potrebbe generare problemi in futuro.

Potresti provare a installare un processo di integrazione continua (vedi qui link ). In questo modo, hai sempre e ogni giorno una nuova release candidate a portata di mano. Ciò non significa che ognuna di queste versioni sia realmente consegnata agli utenti, ma la decisione spetta al team di produzione quale versione o pietra miliare forniscano. La parte importante è che ottieni le responsabilità tra il team di sviluppo e il team di produzione.

D'altra parte, il tuo team di sviluppo sarà costretto a imparare come sviluppare in iterazioni più piccole, in cui ogni iterazione è un incremento testato e completamente documentato a livello interno. Forse questo ti aiuterà a lavorare in modo più efficiente su entrambi i lati.