Sto studiando un approccio per capire meglio come il flusso di lavoro di integrazione continua si adatta meglio in una società di sviluppo software con il metodo scrum.
Sto pensando a qualcosa del genere:
Sarebbe un bel flusso di lavoro?
Buon flusso di lavoro per lo sviluppo di software con mischia e integrazione continua
Risposte:
Sei in qualche modo lì, ma espanderei un po 'il tuo diagramma:
Fondamentalmente (se il controllo della tua versione lo consentirà, cioè se sei su hg / git), vuoi che ogni coppia sviluppatore / sviluppatore abbia il proprio ramo "personale", che contiene una singola storia utente su cui sta lavorando. Quando completano la funzione, devono inserire un ramo centrale, il ramo "Rilascio". A questo punto, vuoi che lo sviluppatore ottenga un nuovo ramo, per la prossima cosa su cui dovrà lavorare. Il ramo della funzione originale dovrebbe essere lasciato così com'è, quindi qualsiasi modifica che deve essere fatta può essere fatta da sola (questo non è sempre applicabile, ma è un buon punto di partenza). Prima che uno sviluppatore ritorni a lavorare su un vecchio ramo di funzionalità, è necessario inserire il ramo di rilascio più recente, per evitare strani problemi di unione.
A questo punto, abbiamo un possibile candidato al rilascio sotto forma del ramo "Rilascio" e siamo pronti per eseguire il nostro processo CI (su quel ramo, ovviamente puoi farlo su ogni ramo dello sviluppatore, ma questo è abbastanza raro nei team di sviluppo più grandi che ingombra il server CI). Questo potrebbe essere un processo costante (idealmente, l'IC dovrebbe essere eseguito ogni volta che il ramo "Release" viene modificato), oppure potrebbe essere notturno.
A questo punto, vorrai eseguire una build e ottenere un artefatto build realizzabile dal server CI (ovvero qualcosa che potresti implementare in modo fattibile). Puoi saltare questo passaggio se stai usando un linguaggio dinamico! Una volta costruito, vorrai eseguire i tuoi test unitari, poiché sono la base di tutti i test automatizzati nel sistema; è probabile che siano veloci (il che è positivo, poiché l'intero punto di CI è quello di abbreviare il circuito di feedback tra sviluppo e test) e è improbabile che abbiano bisogno di una distribuzione. Se passano, vorrai distribuire automaticamente la tua applicazione su un server di prova (se possibile) ed eseguire tutti i test di integrazione disponibili. I test di integrazione possono essere test UI automatizzati, test BDD o test di integrazione standard che utilizzano un framework di unit test (ovvero "unità"
A questo punto, dovresti avere un'indicazione abbastanza completa se la build è praticabile. L'ultimo passaggio che normalmente imposto con un ramo "Rilascio" è di far distribuire automaticamente il candidato al rilascio su un server di prova, in modo che il reparto di controllo qualità possa eseguire test del fumo manuali (questo viene spesso eseguito di notte invece del check-in in modo da per evitare di incasinare un ciclo di prova). Ciò fornisce solo una rapida indicazione umana del fatto che la build sia davvero adatta per una versione live, poiché è abbastanza facile perdere qualcosa se il pacchetto di test è meno completo e, anche con una copertura del test al 100%, è facile perdere qualcosa che puoi (non dovrebbe) testare automaticamente (come un'immagine mal allineata o un errore di ortografia).
Questa è, in realtà, una combinazione di integrazione continua e distribuzione continua, ma dato che l'attenzione su Agile è focalizzata sulla codifica snella e sui test automatizzati come un processo di prima classe, si desidera mirare a 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 (per esempio, i rami degli sviluppatori non sono semplicemente fattibili in SVN), ma vuoi mirare il più possibile .
Per quanto riguarda il modo in cui il ciclo di Scrum sprint si inserisce in questo, idealmente vuoi che le tue uscite avvengano il più spesso possibile e non lasciarle fino alla fine dello sprint, come ottenere un rapido feedback sul fatto che una funzione (e costruire nel suo insieme ) è fattibile per passare alla produzione è una tecnica chiave per abbreviare il ciclo di feedback al proprietario del prodotto.
1
Sono d'accordo con molto di quello che dici, ma io (personalmente) proverei a incoraggiare le persone nello stesso ramo ogni volta che è possibile.
—
William Payne,
@WilliamPayne Realisticamente, se stai usando un DVCS le persone non fanno mai parte dello stesso ramo (a meno che non stiano letteralmente lavorando sullo stesso computer), dal momento che "ramifichi" ogni volta che cloni. Il "ramo" equivalente a quello che avresti in un VCS standard è il ramo di unione che avrai per caratteristica (quindi Dev B e Dev C potrebbero lavorare sui rami del ramo C, quindi controllare nel ramo C come sono fatti, se entrambi stavano lavorando alla funzione C). I vantaggi di avere più filiali è meno tempo impiegato a risolvere i problemi di unione, poiché la fusione in HG / Git è quasi completamente indolore, ma non è una gara push / pull.
—
Ed James,
A rischio di trasformarsi in una guerra di fiamme, credo che i problemi dovuti alla fusione dei conflitti siano spesso esagerati (anche se ammetto che esistano). Inoltre, credo che il passaggio agli strumenti DVCS (sebbene giustificato da altre considerazioni) non dovrebbe essere giustificato esclusivamente sulla base di evitare conflitti di unione - In qualsiasi cosa diversa da uno sforzo di sviluppo aperto / comunitario, questi sono sintomatici di scarsa comunicazione e coordinamento in il team di sviluppo. Il passaggio a un DVCS maschera solo un problema più profondo e più significativo con la comunicazione di gruppo.
—
William Payne,
Credo ancora fermamente nella necessità di un repository "giornaliero" (trunk) a cui gli sviluppatori si impegnano mentre lavorano. Dopotutto, l'integrazione continua del tuo lavoro è una questione di integrazione continua. Per me, la ramificazione è qualcosa che viene fatto come ultima risorsa, non a causa del pericolo di unire conflitti, ma perché gli sviluppatori perdono traccia di ciò che l'altro sta facendo e iniziano a lavorare in silos. Riguarda il lavoro di squadra, la comunicazione e i fattori umani, non i limiti degli strumenti che utilizziamo. Per un'integrazione continua, è necessaria una comunicazione continua, che la ramificazione non supporta.
—
William Payne,
@WilliamPayne Non ho intenzione di discutere con te i meriti relativi di DVCS vs. VCS (almeno non tramite i commenti), ci sono vantaggi significativi nell'utilizzare un DVCS se ottieni il flusso di lavoro giusto, mentre con un flusso di lavoro più tradizionale un VCS farà un ottimo lavoro (secondo la mia esperienza). Ti dirò, tuttavia, che dal passaggio a un DVCS il mio team ha sperimentato tempi di risposta allo sviluppo significativamente più rapidi e implementazioni più solide. La fine del progetto unisce l'inferno che molte persone vivono ancora oggi è stato quasi completamente rimosso dal nostro processo di sviluppo.
—
Ed James,
Concettualmente sì. Un diagramma non sta catturando molti punti importanti come:
- test unitari
- commit incrementali
- la stadiazione viene distribuita spesso, di solito la produzione 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 vengono inviati agli sviluppatori. Chiamali requisiti, correzioni di bug, storie o altro. Ma attualmente il 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 è consentita una modifica in trunk / main / release-branch / etc ...? Quali codetree / progetti sono basati sulla CSI? C'è un checkpoint per vedere se la build è stata interrotta? Chi rilascia dalla CSI alla messa in scena / produzione?
Relativo ai punti di controllo è identificare quale sia la metodologia di branching e come si adatta a questo flusso di lavoro.
C'è un team di test? Quando sono coinvolti o avvisati? Esistono test automatizzati sul CIS? Come vengono ripristinate le rotture nel sistema?
Considera come assoceresti questo flusso di lavoro a un diagramma di flusso tradizionale con punti di decisione e input. Hai acquisito tutti i punti di contatto di alto livello necessari per descrivere adeguatamente il tuo flusso di lavoro?
La tua domanda originale sta tentando di fare un confronto, penso, ma non sono sicuro su quale aspetto / i che stai cercando di confrontare. L'integrazione continua ha punti di decisione proprio come gli altri modelli SDLC, ma possono trovarsi in punti diversi del processo.
Uso il termine "automazione dello sviluppo" per comprendere tutte le attività di costruzione automatizzata, generazione di documentazione, test, misurazione delle prestazioni e distribuzione.
Un "server di automazione dello sviluppo" ha quindi un mandato simile, ma un po 'più ampio di un server di integrazione continua.
Preferisco utilizzare gli script di automazione dello sviluppo guidati da hook post-commit che consentono di automatizzare sia le filiali private sia il trunk di sviluppo centrale, senza richiedere una configurazione aggiuntiva sul server CI. (Ciò preclude l'utilizzo della maggior parte delle GUI del server CI standard di cui sono a conoscenza).
Lo script post-commit determina quali attività di automazione devono essere eseguite in base al contenuto del ramo stesso; o leggendo un file di configurazione post-commit in una posizione fissa nel ramo o rilevando una determinata parola (io uso / auto /) come componente del percorso del ramo nel repository (con Svn)).
(Questo è più facile da impostare con Svn di Hg).
Questo approccio consente al team di sviluppo di essere più flessibile su come organizzare il proprio flusso di lavoro, consentendo a CI di supportare lo sviluppo su filiali con costi amministrativi minimi (vicini allo zero).
C'è una buona serie di post sulla continua integrazione su asp.net che potresti trovare utili, copre un bel po 'di terreno e flussi di lavoro che si adattano a quello che sembra che tu stia facendo.
Il diagramma non menziona il lavoro svolto dal server CI (test di unità, copertura del codice e altre metriche, test di integrazione o build notturne), ma suppongo che sia tutto coperto nella fase "Server di integrazione continua". Non sono chiaro il motivo per cui la scatola degli elementi della configurazione dovrebbe tornare al repository centrale? Ovviamente ha bisogno di ottenere il codice, ma perché mai dovrebbe rispedirlo?
L'IC è una di quelle pratiche raccomandate da varie discipline, non è unica per la mischia (o XP) ma in effetti direi che i benefici sono disponibili per qualsiasi flusso anche i non agili come la cascata (forse bagnato-agile?) . Per me i vantaggi principali sono il circuito di feedback stretto, sai abbastanza rapidamente se il codice che hai appena commesso funziona con il resto della base di codice. Se stai lavorando agli sprint e hai i tuoi stand-up giornalieri, essere in grado di fare riferimento allo stato o le metriche delle ultime notti costruite nel server CI è sicuramente un vantaggio e aiuta a focalizzare le persone. Se il proprietario del tuo prodotto può vedere lo stato della build - un grande monitor in un'area condivisa che mostra lo stato dei tuoi progetti di build - allora hai davvero rafforzato quel circuito di feedback. Se il tuo team di sviluppo si impegna frequentemente (più di una volta al giorno e idealmente più di una volta all'ora), le possibilità che ti imbatterai in un problema di integrazione che richiede molto tempo per risolversi sono ridotte, ma se lo fanno è chiaro che tutto e puoi prendere tutte le misure di cui hai bisogno, ad esempio tutti si fermano per gestire la build danneggiata. In pratica, probabilmente non colpirai molte build fallite che impiegano più di qualche minuto per capire se ti stai integrando spesso.
A seconda delle tue risorse / rete potresti prendere in considerazione l'aggiunta di diversi end server. Abbiamo una build CI innescata da un commit al repository e supponendo che costruisca e superi tutti i suoi test, quindi sia distribuita al server di sviluppo in modo che gli sviluppatori possano assicurarsi che funzioni correttamente (potresti includere qui selenio o altri test dell'interfaccia utente? ). Tuttavia, non tutti i commit sono una build stabile, quindi per innescare una build sul server di gestione temporanea dobbiamo taggare la revisione (usiamo mercurial) che vogliamo costruire e distribuire, anche questo è tutto automatizzato e attivato semplicemente impegnandosi con un particolare etichetta. Andare in produzione è un processo manuale; puoi lasciarlo semplice come forzare una build, il trucco è sapere quale revisione / build vuoi usare, ma se dovessi etichettare la revisione in modo appropriato, il server CI può verificare la versione corretta e fare tutto il necessario. Potresti utilizzare MS Deploy per sincronizzare le modifiche ai server di produzione o per impacchettarlo e mettere lo zip da qualche parte pronto per la distribuzione manuale di un amministratore ... dipende da quanto ti senti a tuo agio.
Oltre ad andare su una versione, dovresti anche considerare come potresti affrontare l'errore e andare giù una versione. Speriamo che non accada, ma potrebbero esserci alcune modifiche apportate ai tuoi server, ciò significa che ciò che funziona su UAT non funziona sulla produzione, quindi rilasci la versione approvata e fallisce ... puoi sempre adottare l'approccio che identifichi bug, aggiungi un po 'di codice, esegui il commit, prova, distribuisci in produzione per risolverlo ... oppure potresti avvolgere alcuni ulteriori test intorno alla tua versione automatizzata in produzione e se fallisce, allora torna automaticamente.
CruiseControl.Net utilizza xml per configurare le build, TeamCity utilizza procedure guidate, se stai cercando di evitare specialisti nella tua squadra, la complessità delle configurazioni xml può essere qualcos'altro da tenere a mente.
Innanzitutto, un avvertimento: Scrum è una metodologia piuttosto rigorosa. Ho lavorato per un paio di organizzazioni che hanno cercato di usare Scrum, o approcci simili a Scrum, ma nessuno dei due si è avvicinato molto alla disciplina completa nella sua interezza. Dalle mie esperienze sono un appassionato di Agile, ma uno (riluttante) Scrum-scettico.
A quanto ho capito, Scrum e altri metodi Agile hanno due obiettivi principali:
- Il primo è fornire un meccanismo esplicito per la gestione dei rischi e la scoperta in corso dei rischi.
- Il secondo è fornire un meccanismo strutturato per la comunicazione delle parti interessate, la scoperta dei requisiti e la gestione dei requisiti.
Il primo obiettivo (gestione del rischio) è raggiunto attraverso lo sviluppo iterativo; commettere errori e apprendere rapidamente le lezioni, consentendo al team di sviluppare 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à nella borsa.
L'automazione dello sviluppo, compresa l'integrazione continua, è il fattore più critico per il successo di questo approccio. La scoperta del rischio e l'apprendimento delle lezioni devono essere rapidi, privi di attrito e privi di fattori sociali confondenti. (Le persone imparano MOLTO più velocemente quando si tratta di una macchina che dice loro che hanno torto piuttosto che un altro essere umano - gli ego si limitano a ostacolare l'apprendimento).
Come probabilmente puoi dire, sono anche un fan dello sviluppo guidato dai test. :-)
Il secondo obiettivo ha meno a che fare con l'automazione dello sviluppo e più con i fattori umani. È più difficile da implementare perché richiede un 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 le parti interessate al di fuori del team di sviluppo costantemente aggiornate con i progressi, e i radiatori di informazioni che mostrano lo stato della costruzione e suite di test di superamento / fallimento possono essere utilizzati per comunicare i progressi sullo sviluppo delle funzionalità, aiutando (si spera) a sostenere l'adozione del processo di comunicazione Scrum.
Quindi, in sintesi:
Il diagramma che hai usato per illustrare la tua domanda cattura solo una parte del processo. Se volessi studiare agile / scrum e CI, direi che è importante considerare gli aspetti sociali e umani più ampi del processo.
Devo finire suonando lo stesso tamburo che faccio sempre. Se stai cercando di implementare un processo agile in un progetto del mondo reale, il miglior fattore predittivo delle tue possibilità di successo è il livello di automazione che è stato distribuito; riduce l'attrito, aumenta la velocità e spiana la strada verso il successo.