Agile Waterfall integration e deployment ritardato

Una soluzione è adottare il modello "LTS" (Long Term Support) utilizzato dai fornitori di Linux e browser.

Alla fine di uno sprint, se hai una versione adatta per il rilascio, puoi creare una versione. Dagli un numero di versione, etichettalo in git (o qualsiasi controllo di versione che stai usando, ma sto assumendo git qui), aggiorna i documenti ecc. Quindi distribuisci efficacemente quella versione solo internamente.

Quando l'azienda vuole una nuova versione distribuita a "messo in scena per il test", gli dai la tua ultima versione. A quel punto, si etichetta anche quella versione come "LTS". Poi prosegui con i tuoi sprint e le nuove uscite.

Se trovano un problema durante il test, si diramano dalla versione LTS che gli hai dato da git, fai la correzione, ri-etichetta e ri-rilascia a loro. Se applicabile, si applica anche la correzione all'ultima versione.

Non è una soluzione perfetta e potresti scoprire che quando vogliono una nuova versione, vogliono solo alcune delle funzioni che hai aggiunto nel frattempo. L'uso di "feature branch", in cui ogni caratteristica è mantenuta, per quanto possibile, sul proprio ramo può essere d'aiuto, in quanto basta unire nuovamente quelle funzioni al master per creare una release per loro.

Invece di utilizzare i rami , ti consigliamo di utilizzare i flag di funzionalità. Essenzialmente, questi sono solo condizionali nel codice che determinano se una particolare parte del codice viene eseguita o meno. È possibile controllare lo stato della funzionalità tramite la configurazione, che può essere semplicistica come un'impostazione di app nel proprio Web.config o complessa come un servizio di terze parti come LaunchDarkly, che offre un controllo granulare su cui gli utenti possono accedere a quali funzionalità che ora.

L'unico svantaggio di mostrare le bandiere è che sono intrinsecamente un debito tecnico. In sostanza, si dispone di codice che potrebbe non essere mai eseguito nella base di codice e tale codice aumenta nel tempo. Alcune aziende in realtà abbracciano questo, però. Facebook, ad esempio, fa un uso massiccio di flag di funzionalità e non li pulisce mai. Personalmente, penso che sia un po 'folle, ma suppongo che funzioni per loro. Per il resto di noi, la raccomandazione comune è che quando viene introdotto un flag di funzionalità, si aggiunge anche un PBI per ripulirlo. Quindi, una volta implementata completamente questa funzione (e forse dato un po 'di tempo per assicurarsi che non ci siano problemi importanti), si aggiunge il PBI a uno sprint per sbarazzarsi del debito tecnico. Non è l'ideale, ma è gestibile.

Il debito tecnico a parte, le bandiere caratteristiche possono darti un'enorme libertà. Puoi effettivamente unire il codice in master, ma scegli di non distribuire effettivamente la funzione . In questo modo, non devi preoccuparti di gestire le fusioni con il codice che è settimane o mesi fuori fase rispetto al master, ma il prodotto reale non è cambiato.

Meglio, puoi semplicemente applicare la patch per abilitare le funzionalità, che è molto meno coinvolta degli aggiornamenti completi. Ad esempio, supponiamo che stai seguendo il tipico ciclo di rilascio monolitico. Hai un intero lotto di nuove funzionalità, alcune delle quali richiedono modifiche fondamentali al prodotto principale. Il processo di aggiornamento deve toccare molti file e apportare molte modifiche per abilitare tutte queste nuove funzionalità. Quindi, c'è un problema, un grosso problema, un problema per il quale non puoi semplicemente inserire una soluzione rapida. Ora devi gestire i downgrade e capire come far tornare gli utenti in uno stato utilizzabile. È una bestia di un problema.

Ora, diamo un'occhiata all'approccio del flag di funzionalità. Dal momento che tutto il codice per queste funzionalità è dietro i flag. Basta fare un rilascio che li accende. Ovviamente, se non fossero effettivamente nell'ultima versione, sarà necessario inserire il codice, che potrebbe richiedere lo stesso aggiornamento monolitico. Tuttavia, dove le cose vanno molto meglio per te è quando le cose esplodono. Questa volta, non è necessario eseguire il downgrade degli utenti e pianificare una nuova release monolitica. Invece, si rilascia semplicemente una patch che disabilita le funzionalità che causano il problema. L'applicazione ora ritorna al modo in cui ha fatto le cose prima. Quando correggi il problema, puoi eseguire il rollforward, solo la correzione e la funzionalità, invece di dover ri-rilasciare l'intero prodotto.

Sono sicuro che questa risposta avrà i suoi detrattori ma qualunque cosa. La risposta alla tua domanda è che non è possibile per entrambe le parti ottenere quello che vogliono come descritto. Quindi hai un paio di scelte. Per prima cosa, prova a scoprire cosa vuole veramente l'azienda. Se non riescono a esprimere una ragione aziendale, allora dovresti prenderli in considerazione per quello. Ad esempio, potrebbero semplicemente voler controllare il processo di sviluppo. Oppure potrebbero seguire un credo carico-settoriale sulla gestione dei progetti e sulla pianificazione dei rilasci che leggono da qualche parte e pensano che questo sia esattamente il modo in cui è stato fatto.

Un motivo commerciale legittimo potrebbe essere che ritengono che un ciclo di QA su una base di codice congelata in un ambiente controllato sarà in grado di catturare più bug e produrre meno difetti rilasciati alla produzione. Questa è davvero l'unica ragione per cui posso pensare che gli approcci siano legittimi. Tuttavia, in questo scenario, il nucleo centrale è "meno difetti di produzione".

Chiedi loro di qualificarlo e quantificarlo. Come fanno a sapere che ci saranno meno difetti? Qual è il tasso di difetti ora? È possibile ottenere un calo del difetto simile con un processo agile? Invitali a mostrare il loro lavoro.

Un approccio alternativo è l'integrazione continua con unità automatizzate e test di integrazione e segnalazione delle funzioni da controllare quando le funzioni appaiono agli utenti.

I vantaggi di quest'ultimo approccio sono significativi e vanno oltre la riduzione della complessità SCM. Ulteriori vantaggi includono un time-to-market più veloce, la possibilità di implementare funzionalità di rollout per determinati sottogruppi di utenti, semplificazione del refactoring, minori difetti, maggiore autonomia e soddisfazione del team di sviluppo e una valutazione complessiva dell'azienda più elevata.

Una cosa che ho visto è fondamentalmente una scansione periodica; se le cose sono contrassegnate come pronte per l'implementazione, a qualcuno viene assegnato il compito di implementazione e riesaminano il codice, cercano tutto quello che dovranno fare prima / dopo la distribuzione (come il monitoraggio di alcuni grafici o la migrazione di un database) e quindi la distribuzione.

Questo è simile alle idee menzionate nelle altre risposte di avere un rilascio. Il ramo di rilascio stabile (o tag) vive separatamente dal ramo instabile.

In questo modo, lo sviluppo può continuare con la stessa rapidità con cui il team Agile vuole e il feedback dei risultati di tale rilascio viene ritardato a seconda di quando il rilascio è effettivamente distribuito. Se il team fa affidamento su quel feedback, il ciclo di sviluppo rallenterà; nel qual caso inizia ad avere senso avere un proprietario di prodotti o clienti seduti nella squadra o allungare lo sprint.