Buon flusso di lavoro per lo sviluppo di software con scrum e integrazione continua

Sei parte del modo in cui ci sei, ma vorrei espandere un po 'il tuo diagramma:

Fondamentalmente(seiltuocontrollodiversioneloconsentirà,cioèseseisuhg/git),vuoicheognisviluppatore/coppiadisviluppatoriabbiailproprioramo"personale", che contiene una singola storia utente su cui stanno lavorando sopra. Quando completano la funzione, devono inserire un ramo centrale, il ramo "Rilascio". A questo punto, vuoi che lo sviluppatore ottenga una nuova filiale, per la prossima cosa su cui devono lavorare. Il ramo della funzione originale deve essere lasciato così com'è, quindi qualsiasi modifica che deve essere apportata ad essa può essere fatta isolatamente (questo non è sempre applicabile, ma è un buon punto di partenza). Prima che un dev ritorni a lavorare su un vecchio ramo di funzionalità, dovresti inserire l'ultimo ramo di rilascio, per evitare problemi di unione.

A questo punto, abbiamo un possibile candidato al rilascio sotto forma di ramo "Release" e siamo pronti per eseguire il nostro processo CI (su quel ramo, ovviamente puoi farlo su ogni ramo sviluppatore, ma questo è abbastanza raro nei team di sviluppo più grandi che ingombrano il server CI). Questo potrebbe essere un processo costante (questo è idealmente il caso, l'IC dovrebbe essere eseguito ogni volta che il ramo "Release" è cambiato), o potrebbe essere notturno.

A questo punto, ti consigliamo di eseguire una build e ottenere un artefatto di build fattibile dal server CI (ad esempio, qualcosa che potresti implementare in modo fattibile). Puoi saltare questo passaggio se stai utilizzando un linguaggio dinamico! Una volta che hai costruito, vorrai eseguire i tuoi Test unitari, poiché sono la base di tutti i test automatici del sistema; è probabile che siano veloci (il che è positivo, dato che l'intero punto della CI è quello di accorciare il ciclo di feedback tra lo sviluppo e i test), ed è improbabile che abbiano bisogno di una distribuzione. Se passano, si desidera distribuire automaticamente la propria applicazione su un server di prova (se possibile) ed eseguire eventuali test di integrazione disponibili. I test di integrazione possono essere test UI automatizzati, test BDD o test di integrazione standard utilizzando un framework di test unitario (cioè test "unitari" che richiedono più stato).

A questo punto, dovresti avere un'indicazione abbastanza esaustiva se la build è valida. Il passaggio finale che dovrei normalmente impostare con un ramo "Release" è quello di distribuire automaticamente il release candidate a un server di test, in modo che il tuo reparto QA possa eseguire test manuali del fumo (questo è spesso fatto di notte invece che per check-in per evitare di incasinare un ciclo di prova). Questo fornisce una rapida indicazione umana se la build è veramente adatta per un live release, dato che è abbastanza facile perdere le cose se il tuo test pack è meno completo, e anche con una copertura del 100% è facile perdere qualcosa che puoi 't (should not) testare automaticamente (come un'immagine allineata male o un errore di ortografia).

Questa è, in realtà, una combinazione di integrazione continua e distribuzione continua, ma dato che l'attenzione in Agile è sulla codifica snella e sui test automatici come processo di prima classe, si desidera ottenere un approccio il più completo possibile .

Il processo che ho delineato è uno scenario ideale, ci sono molte ragioni per cui potresti abbandonarne alcune parti (ad esempio, i rami di sviluppo non sono semplicemente fattibili in SVN), ma vuoi mirare tanto a è possibile.

Per quanto riguarda il modo in cui il ciclo Scrum Sprint si adatta a questo, idealmente si desidera che le proprie pubblicazioni avvengano il più spesso possibile, e non lasciarle fino alla fine dello sprint, come ottenere un rapido riscontro sul fatto che una caratteristica (e costruzione nel suo complesso) è un passaggio per la produzione è una tecnica chiave per abbreviare il ciclo di feedback al proprietario del prodotto.

Concettualmente sì. Un diagramma non cattura molti punti importanti come:

1. test delle unità
2. commit incrementale
3. la stadiazione viene distribuita spesso, la produzione di solito no.

Potresti voler disegnare un sistema più ampio per il diagramma. Vorrei prendere in considerazione l'aggiunta dei seguenti elementi:

Mostra i tuoi input al sistema, che sono forniti agli sviluppatori. Chiamali requisiti, correzioni di bug, storie o altro. Ma attualmente il tuo flusso di lavoro presuppone che lo spettatore sappia come sono inseriti tali input.

Mostra i punti di controllo lungo il flusso di lavoro. Chi / cosa decide quando una modifica è permessa in trunk / main / release-branch / etc ...? Quali codetre / progetti sono costruiti sulla CIS? C'è un checkpoint per vedere se la build è stata rotta? Chi rilascia dalla CSI alla messa in scena / produzione?

In relazione ai punti di controllo sta identificando quale sia la tua metodologia di ramificazione e come si adatta a questo flusso di lavoro.

Esiste un gruppo di test? Quando sono coinvolti o notificati? Sono in corso test automatici sul CIS? Come vengono reinserite le rotture nel sistema?

Considera come associare questo flusso di lavoro a un diagramma di flusso tradizionale con punti decisionali e input. Hai catturato tutti i punti di contatto di alto livello necessari per descrivere in modo adeguato il tuo flusso di lavoro?

La tua domanda originale sta tentando di fare un confronto, penso, ma non sono sicuro su quale aspetto / i stai cercando di confrontare. L'integrazione continua ha punti decisionali come tutti gli altri modelli SDLC, ma potrebbero trovarsi in punti diversi del processo.

Uso il termine "Automazione dello sviluppo" per comprendere tutte le attività di generazione, generazione di documentazione, test, misurazione delle prestazioni e implementazione automatizzate.

Un "server di automazione dello sviluppo" ha quindi una funzione simile, ma in qualche modo più ampia, di un server di integrazione continua.

Preferisco utilizzare gli script di automazione dello sviluppo basati su hook post-commit che consentono di automatizzare sia le filiali private che il tronco di sviluppo centrale, senza richiedere una configurazione aggiuntiva sul server CI. (Questo preclude l'utilizzo della maggior parte delle GUI del server della CI standard di cui sono a conoscenza).

Lo script post-commit determina quali attività di automazione eseguire in base al contenuto del ramo stesso; leggendo un file di configurazione post-commit in una posizione fissa nel ramo o rilevando una parola particolare (utilizzo / auto /) come componente del percorso del ramo nel repository (con Svn)).

(Questo è più facile da configurare con Svn che Hg).

Questo approccio consente al team di sviluppo di essere più flessibile su come organizzare il proprio flusso di lavoro, consentendo all'elemento della configurazione di supportare lo sviluppo sui rami con un sovraccarico amministrativo minimo (vicino allo zero).

C'è una buona serie di post su integrazione continua su asp.net che potresti trovare utile, copre un po 'di terreno e flussi di lavoro che si adattano a quello che sembra dopo aver fatto.

Il diagramma non menziona il lavoro svolto dal server CI (test dell'unità, copertura del codice e altre metriche, test di integrazione o build notturni), ma presumo che tutto ciò sia contemplato nella fase "Continuous Integration server". Non sono chiaro per quale motivo la scatola CI verrebbe respinta al repository centrale? Ovviamente ha bisogno di ottenere il codice, ma perché mai avrebbe bisogno di inviarlo di nuovo?

L'IC è una di quelle pratiche raccomandate da varie discipline, non è univoco per scrum (o XP), ma in realtà direi che i suoi benefici sono disponibili per qualsiasi flusso anche non agile come la cascata (forse bagnato- agile?). Per me i principali vantaggi sono il ciclo di feedback limitato, sai abbastanza rapidamente se il codice appena eseguito funziona con il resto della base di codice. Se stai lavorando in sprint e hai i tuoi stand-up giornalieri, allora puoi fare riferimento allo stato, o le metriche delle ultime notti costruite nel server CI sono sicuramente un vantaggio e aiutano a focalizzare le persone. Se il proprietario del tuo prodotto può vedere lo stato della compilazione - un grande monitor in un'area condivisa che mostra lo stato dei tuoi progetti di costruzione - allora hai davvero rafforzato quel ciclo di feedback. Se il tuo team di sviluppo si sta impegnando di frequente (più di una volta al giorno e idealmente più di una volta all'ora), le probabilità che ti imbatti in un problema di integrazione che richiede molto tempo per essere risolto sono ridotte, ma se lo fanno è chiaro tutto e puoi prendere tutte le misure che ti servono, tutti che si fermano ad affrontare la costruzione rotta, per esempio. In pratica probabilmente non colpirai molte build fallite che impiegano più di qualche minuto per capire se ti stai integrando spesso.

A seconda delle risorse / della rete, potresti prendere in considerazione l'aggiunta di diversi server finali. Abbiamo un build CI che viene attivato da un commit al repository e presupponendo che crea e passa tutti i test, viene distribuito nel server di sviluppo in modo che gli sviluppatori possano assicurarsi che funzionino correttamente (potresti includere selenio o altri test dell'interfaccia utente qui? ). Non tutti i commit sono comunque una build stabile, quindi per attivare una build sul server di staging dobbiamo taggare la revisione (usiamo mercurial) vogliamo essere costruiti e distribuiti, ancora una volta tutto questo è automatizzato e attivato semplicemente commettendo con un particolare etichetta. Per andare alla produzione è un processo manuale; puoi lasciarlo semplice come forzare una build, il trucco è sapere quale revisione / build vuoi usare, ma se dovessi taggare la revisione in modo appropriato, il server CI può verificare la versione corretta e fare tutto ciò che è necessario. Potresti utilizzare MS Deploy per sincronizzare le modifiche ai server di produzione, o per comprimere e mettere da qualche parte il file zip pronto per un amministratore da distribuire manualmente ... dipende da quanto sei comodo con quello.

Oltre ad andare su una versione, dovresti anche considerare come potresti gestire il fallimento e andare giù per una versione. Speriamo che non accada, ma potrebbero esserci delle modifiche ai tuoi server, il che significa che ciò che funziona su UAT non funziona in produzione, quindi rilasci la tua versione approvata e fallisce ... puoi sempre prendere l'approccio che identifica bug, aggiungi un po 'di codice, commetti, prova, distribuisci in produzione per risolverlo ... oppure potresti completare alcuni test intorno alla tua versione automatizzata in produzione e se fallisce, allora si ripristina automaticamente.

CruiseControl.Net utilizza xml per configurare le build, TeamCity utilizza le procedure guidate, se si mira ad evitare specialisti nel proprio team, la complessità delle configurazioni xml può essere un'altra cosa da tenere a mente.

In primo luogo, un avvertimento: Scrum è una metodologia abbastanza rigorosa. Ho lavorato per un paio di organizzazioni che hanno provato ad usare Scrum, o approcci di tipo Scrum, ma nessuno dei due si è davvero avvicinato all'utilizzo dell'intera disciplina nella sua interezza. Dalle mie esperienze, sono un appassionato di Agile, ma un (riluttante) Scrum-scettico.

A quanto ho capito, Scrum & altri metodi Agile hanno due obiettivi principali:

• Il primo è fornire un meccanismo esplicito per la gestione dei rischi e la continua scoperta di rischi.
• Il secondo è quello di fornire un meccanismo strutturato per gli stakeholder comunicazione, ricerca dei requisiti e gestione dei requisiti.

Il primo obiettivo (gestione del rischio) è raggiunto attraverso lo sviluppo iterativo; fare errori e imparare velocemente le lezioni, permettendo al team di costruire la comprensione e la capacità intellettuale per ridurre il rischio e passare a una soluzione a rischio ridotto con una soluzione "austera" a basso rischio già presente nella borsa.

L'automazione dello sviluppo, inclusa l'integrazione continua, è il fattore più critico per il successo di questo approccio. Rilevazione dei rischi & L'apprendimento della lezione deve essere veloce, privo di attriti e privo di fattori sociali confondenti. (Le persone imparano MOLTO più velocemente quando è una macchina che dice loro che sono sbagliate piuttosto che un altro umano - l'ego si intromette solo nel modo di apprendere).

Come probabilmente puoi dire - Sono anche un fan dello sviluppo basato sui test. : -)

Il secondo obiettivo ha meno a che fare con l'automazione dello sviluppo, e più a che fare con Human Factors. È più difficile da implementare perché richiede il buy-in dal front end dell'azienda, che difficilmente vedrà la necessità della formalità.

L'automazione dello sviluppo può avere un ruolo qui, in quanto la documentazione generata automaticamente e le relazioni sullo stato di avanzamento possono essere utilizzate per mantenere gli stakeholder al di fuori del team di sviluppo continuamente aggiornati con il progresso e possono essere utilizzati radiatori di informazioni che mostrano lo stato di generazione e le suite di test che passano / falliscono comunicare i progressi nello sviluppo di funzionalità, aiutando (si spera) a supportare l'adozione del processo di comunicazione Scrum.

Quindi, in sintesi:

Il diagramma che hai usato per illustrare la tua domanda acquisisce solo parte del processo. Se volessi studiare agile / scrum e IC, direi che è importante considerare gli aspetti sociali e umani più ampi del processo.

Devo finire sbattendo lo stesso tamburo che faccio sempre. Se stai cercando di implementare un processo agile in un progetto reale, il miglior predittore delle tue possibilità di successo è il livello di automazione che è stato implementato; riduce l'attrito, aumenta la velocità e amp; spiana la strada verso il successo.