Questo flusso di lavoro funziona per un team distribuito con CI / CD

Question

Questo flusso di lavoro funziona per un team distribuito con CI / CD

#1 da (1 voti)

2

Poiché la reazione di @DanCornilescu ho capito che la mia domanda non era chiara. Ecco perché ho modificato la domanda pesantemente.

Sono stato coinvolto in un progetto in cui c'era un solo sviluppatore. Tutto lo sviluppo è stato fatto sul tronco. Ma vogliono cambiare le cose:

Vogliono lavorare con diversi sviluppatori da tutto il mondo. Ed è importante che gli sviluppatori possano iniziare "immediatamente".
Vogliono lavorare con l'integrazione continua e la consegna continua.
Vogliono iniziare a utilizzare DevOps.
Usano la sovversione e vogliono continuare ad usarlo.

E alcune altre cose, ma qui non è importante.

Perché fino ad ora uno show per un solo uomo ci sono alcuni problemi:

Ci sono un sacco di modifiche manuali per ottenere una nuova versione testata, accettata e implementata.
Non ci sono abbastanza test di unità e integrazione.

Il mio lavoro è progettare un nuovo flusso di lavoro, ma questa è la prima volta che mi viene chiesto di fare questo tipo di lavoro. Ho una prima idea per un flusso di lavoro, ma sarebbe bello se le persone con esperienza potessero dirmi cosa potrebbe essere ottimizzato e cosa è sbagliato.

Al momento non ci sono recensioni tra pari. Voglio cambiarlo, ma nel caso in cui ciò non accada, ho definito un flusso di lavoro per due tipi di sviluppatori: fidati e mentori.

Mi è venuto in mente quanto segue per uno sviluppatore affidabile:

Iltestobiancodescriveipassaggimanuali,iltestobludescriveipassaggiautomatizzati.

Ognisviluppatorehailsuoramoefailsuosvilupposuquestoramo.(Questoèilmiomodopreferitoenellamiaricercal'hovistoancheconsigliato,mahoanchevistospessochegliutentisvnnonamavanofarlo.Soprattuttosullungoperiodopensochequestoporterebbepiùfrutto.Ostosopravvalutandoladifferenza?)
Almenoognimattina,primacheunosviluppatoreinizialavorare,unisceiltronconelsuoramo.
Illavoronormaledovrebbeesserecontrollatoneglistessigiorniincuièstatoavviato.Perlavoricherichiedonopiùtempodeveesserecreatounramospeciale.Questoramodovrebbeancheavereuntrunkintegratoinessoalmenoall'iniziodelgiornolavorativo.
Ognivoltachelosviluppatorehaaggiuntoqualcosachepuòesseretestato,dovrebbeeseguireitestunitari.Primadieseguireiltestdell'unitàvieneeseguitaun'unioneautomatica.Sequestositraduceinconflitti,questidevonoessererisolti.
Quandolosviluppatorepensadiaverequalcosachepuòessereimpegnato,chiamaitestunitariconunflagdicommit.QuandotuttoèOK,vengonoeseguiteleazionidicommitedifollow-up.
Vienedefinitounpre-hookcheverificailcorrettocompletamentodeitestdiunioneeunità.
Dopocheilcommitèstatoeseguitoconsuccesso,unpost-hookcreeràunserverdiintegrazioneincuivengonoeseguitinuovamenteitestprecedentievengonoeseguitiitestdiintegrazione.Quandononèunramospeciale:incasodisuccessovienecreatounserverdiaccettazioneconquestoramoeilramovieneunito(--reintegrate)neltrunk.Losviluppatorevienesempreinformatodelrisultato.
Aunosviluppatoreèconsentitoandareacasasoloquandolasuaversioneèstatainseritacorrettamente.Idealmentedovrebbeanchesuperareitestdiintegrazione.(Questosuonaunpo'duro,mal'hoaggiuntoperchéhovistosviluppatorichenonsiimpegnavanodasettimaneperchénoneranoancoracambiatimolto.Contuttiiproblemidiunionecreati.)

C'èunaleggeradifferenzadiflussoperunosviluppatorementore:

Quando uno sviluppatore mentore esegue correttamente il commit, il ramo non viene fuso nel trunk, ma viene inviato un messaggio per valutare questo ramo. Quando la valutazione è positiva, vengono seguite (automaticamente) le attività del test unitario con il flag di commit per uno sviluppatore attendibile. Sarebbe opportuno se tali revisioni fossero effettuate il prima possibile, per aggirare il più possibile i conflitti di fusione.

Above è la parte più importante, ma voglio anche definire le seguenti regole per ogni sviluppatore:

Vengono impegnati solo gli spazi di lavoro completi.
Un commit ha un unico scopo: correggere un bug, aggiungere una nuova funzione, ...
Quando un messaggio di registro è più come una riga, il messaggio inizia con un breve messaggio, quindi una riga vuota e quindi il messaggio stesso.
Immettere i problemi corrispondenti nel messaggio di registro.
Le righe di un messaggio di registro non sono più lunghe di 72 caratteri.
Quando scrivi un nuovo codice, scrivi sempre i test unitari.

Questo sarebbe un modo fattibile per funzionare, o ci sono insidie? Può essere ottimizzato?

svn continuous-integration continuous-delivery distributed-development

posta Cecil Westerhof 21.12.2018 - 17:15

fonte

1 risposta

Leggi altre domande sui tag svn continuous-integration continuous-delivery distributed-development

Utilizzo corretto del pool di connessioni Errori bizantini: elettore e replica del cliente sullo stesso processore

score 1 · Accepted Answer

Ho visto tentativi di segregare i flussi di lavoro sulla base dell'esperienza utente / fiducia / valutazione dei rischi, con risultati discutibili:

tutti fanno errori
gli sviluppatori più esperti di solito affrontano problemi molto più difficili / complessi rispetto agli sviluppatori mentori, spesso con maggiori possibilità di causare regressioni

Non consiglierei di estendere la segregazione del flusso di lavoro oltre la fase di revisione del codice - IMHO una volta che il codice è passato in rassegna dovrebbe seguire lo stesso pre-commit di verifica e integrazione del flusso di lavoro (idealmente automatizzato) indipendentemente dall'identità del mittente.

Personalmente ritengo che un approccio migliore sarebbe utilizzare un sistema di gating Gating che sarebbe automaticamente :

prendere le modifiche revisionate attraverso tutte le verifiche pre-commit configurate (quali che siano, idealmente includendo i test di integrazione)
reject (ritorno per ri-considerazione) quelli che causano regressioni o incontri si fondono in conflitto con altre modifiche già nella pipeline
esegue il commit di quelli verificati correttamente
sempre mantiene il ramo dell'integrazione verde / passando tutti i criteri di verifica pre-commit configurati. Ciò è possibile a causa delle verifiche centralizzate orchestrate (le verifiche private che hai citato non possono proteggere il ramo di integrazione dalle rotture, vedi link )

Con tale sistema la responsabilità per le interruzioni di filiale non è più in linea con gli sviluppatori - il sistema automatizzato dovrebbe prevenirli. Non più colpa, non più "gli sviluppatori non dovrebbero andare a casa prima ..." regole. E senza interruzioni la velocità di sviluppo del ramo di integrazione è molto più alta, non ci sono più fermate.

Aggiornamento:

La descrizione aggiornata mostra ancora più chiaramente che quello che stai descrivendo non è CI, proverò a spiegare i problemi in cui ti imbatterai.

In CI le verifiche di qualità vengono eseguite sul codice esattamente così come appare (o verrà visualizzato) nel ramo dell'integrazione, il che significa che sono già unite e impegnate (o semplicemente corrette sulla punta del ramo insieme a tutti gli altri cambiamenti che saranno commessi). Ciò garantisce che i risultati della verifica siano quelli del vero e proprio ramo di integrazione.

Le tue verifiche NON lo stanno dando. I test di unità e di integrazione vengono eseguiti sulle singole modifiche del codice precedente alla loro unione e si impegnano nel ramo di integrazione, senza alcuna orchestrazione che impedisca la verifica delle modifiche del codice di altri sviluppatori nello stesso momento. Quello che stai testando è il ramo di ieri più il cambiamento individuale, non come apparirà il ramo quando il singolo cambiamento finirà per essere commesso.

Niente impedisce alle modifiche individuali di un particolare giorno di interferire reciprocamente (il che è possibile anche se le modifiche non toccano lo stesso file, vedere l'esempio nel post a cui ho fatto il riferimento sopra). Se si verificano tali interferenze, non hai un modo "ufficiale / centrale" di informarti e informare gli sviluppatori, ognuno di loro apprenderà se il giorno successivo, dopo aver unito il tronco (riprendendo così la rottura risultante) e vedendo la propria verifica in mancanza di ragioni estranee ai propri cambiamenti. Ora l'intero team è bloccato - non possono nemmeno lavorare in isolamento, non hanno una buona etichetta / base per l'uso. La rottura deve essere investigata e una soluzione trovata e commessa - chi è la responsabilità? Alla fine verrà biasimato il cambiamento di qualcuno, nonostante passando la verifica (isolata)! Abbastanza frustrante. Questi possono essere eventi rari in piccoli gruppi, ma in team di grandi dimensioni possono accadere abbastanza spesso da compromettere completamente lo sviluppo del ramo: l'ho visto accadere.