Lo sviluppatore dovrebbe attendere il completamento della pipeline CI o avviare l'attività successiva dopo aver premuto

8

La mia azienda sta integrando CI / CD, finora abbiamo implementato CI da quello che ho capito. Attualmente quando uno sviluppatore invia il codice al nostro repository git, viene eseguita la pipeline CI.

Attualmente la nostra pipeline CI comprende la costruzione del progetto e l'esecuzione di analisi di codice statico per assicurarsi che soddisfi i nostri standard di codifica. In seguito implementeremo i test. L'analisi della build e del codice statico richiede circa 3 minuti in questo momento. Da quello che ho letto, la risoluzione dei problemi è fondamentale per CI / CD. Mi aspetto che, quando aggiungiamo i test unitari, l'esecuzione della pipeline potrebbe richiedere circa 10 minuti.

Quindi la mia domanda è quando uno sviluppatore inoltra una richiesta pull / merge se deve attendere il completamento della pipeline CI o semplicemente passare all'attività successiva e tornare a risolvere i problemi della pipeline se esistono? O dovrebbero sedersi e guardare la conduttura correre?

continuous-integration git continuous-delivery

— iqueqiorio
fonte

7

Sedersi e guardare la conduttura in esecuzione?

No, non è così che lavori in modo efficiente.

Gli sviluppatori spingono i propri commit nel repository di controllo del codice sorgente e quindi viene avviata la pipeline CI / CD.

Gli sviluppatori possono pubblicare una richiesta pull ben scritta ogni volta che lo desiderano. Di solito c'è un segno visivo che rappresenta una "build in corso" / "build fallita" / "build riuscita".

In genere un brach può essere unito ogni volta che tutti questi criteri sono soddisfatti:

è stato approvato almeno un responsabile dell'approvazione / o quanti sono necessari per l'approvazione.
una "costruzione di successo"
nessun conflitto di unione irrisolto

Se uno di questi criteri non è soddisfatto, devono essere corretti, ma lo sviluppatore lo fa ogni volta che ha tempo o priorità per svolgere questo compito.

— Jonas
fonte

2

Buona risposta. Molte persone non sono consapevoli del fatto che con GitHub SaaS è possibile far sì che circle-ci o un altro elemento della configurazione crei le modifiche proposte in una richiesta pull prima che la modifica venga unita. Quindi ho visto GitHub Enterprise on-prem usato senza quella funzionalità: la Jenkins Farm on-prem gira solo quando unisci il PR che può essere rotto a meno che lo sviluppatore non abbia fatto una fusione e una costruzione complete. Ciò rende la vita molto più complessa. Anni fa teamcity ti ha permesso di fare un ci build in una fattoria prima ancora di impegnarti per evitare di spezzare un ramo. Costruire solo dopo che il problema è stato pubblicato è un modo legacy di lavorare.

— simbo1905,

@ simbo1905 tutto bene, tranne la verifica delle PR non è efficace al 100% a meno che non sia interamente serializzata. Le PR sovrapposte indicano che le rispettive modifiche non si tengono in considerazione le une con le altre e possono comunque interferire tra loro causando una rottura quando atterrano nel ramo di integrazione. Anche se non hanno conflitti di unione o non toccano gli stessi file, sono ancora possibili conflitti funzionali.

— Dan Cornilescu,

@DanCornilescu I PR concordati possono passare build indipendenti ma in conflitto. Uno rinomina un metodo, uno aggiunge il codice che utilizza il vecchio nome del metodo. Entrambi i PR trasmettono build in parallelo. Se approvato e unito, il codice non verrà compilato. I grandi progetti utilizzano un bot di unione come bors-ng. Il revisore non lo unisce e dice al bot di provare. Il bot esegue le fusioni seriali solo dopo una nuova build in cui ha combinato ciò che è nella sua coda di unione. Nel nostro esempio proverà una build unita dei PR combinati. Non riesce, quindi prova solo il primo aggiunto alla sua coda, riesce, unisci, quindi crea e rifiuta l'altro.

— simbo1905,

1

Ti consiglio di fare del tuo meglio per assicurarti che la pipeline sia inferiore a 10 minuti. È possibile eseguire i test in parallelo per abilitare questo. Quando jonas ha risposto, può quindi passare il tempo a creare una richiesta pull (mentre la pipeline è in esecuzione).

Il cambio di contesto è negativo per la produttività, quindi piuttosto che raccogliere un'altra attività, consiglio allo sviluppatore di utilizzare quel tempo per lavorare su qualsiasi altra cosa correlata alla modifica che ha appena apportato. Forse c'è della documentazione che potrebbe essere aggiornata in relazione a questo. Se è una caratteristica degna di nota, potrebbe creare una breve gif che mostra come lavorarci. Anche guardare di nuovo il loro cambio di codice può aiutarli a pensare a come migliorarlo la prossima volta. Questa volta potrebbe essere utilizzato anche per rivedere le richieste pull di altri sviluppatori e le modifiche al codice.

Se si dedicano allo sviluppo di un'altra funzionalità in quei 10 minuti, è probabile che passeranno più di 10 minuti prima che tornino ad esso e il lavoro sarà meno fresco nella loro mente. Se l'IC non riesce, sarà più difficile per loro ricordare cosa potrebbe essere andato storto e correggere il codice.

— Samuel Garratt
fonte

Questo è così vero: CI secondo me non dovrebbe mai correre più a lungo di quanto sarebbe sulla macchina dello sviluppatore.

— Peter Muryshkin,

0

Ok, supponiamo che tu abbia lo strumento di controllo versione come Git e lo strumento CI Jenkins. Quindi Dev crea un ramo di funzionalità per un problema. È presente una pipeline multibranch o un flusso di lavoro nello strumento CI che rileva questo ramo di funzionalità nella scansione successiva ed esegue i passaggi CI.

Quindi le cose che devono essere garantite sono:

Prima di aumentare PR / MR, il lavoro CI è verde. Se non è verde, PR / MR non deve essere sollevato. Ovviamente lo sviluppatore può eseguire altre attività e poi tornare e risolvere il problema su questa attività, che è la loro scelta a seconda della priorità dell'attività. Puoi persino controllare che qualsiasi PR venga sollevato verificandone i parametri CI (se non ti fidi tanto del tuo sviluppatore e aumentano continuamente i PR per build interrotte)
Una volta sollevato il PR, un revisore del codice esaminerà e fonderà se tutto è OK. Il revisore del codice può essere qualsiasi altro sviluppatore. La sua responsabilità è di rivedere il codice, vedere se rientra nei criteri di "Definizione del fatto". DoD è principalmente un termine agile ma agile e DevOps vanno di pari passo.
Una volta unito il codice, l'elemento della configurazione per il ramo principale dovrebbe essere verde. In caso contrario, il codice dovrebbe essere ripristinato e il problema dovrebbe essere risolto perché in genere anche il ramo principale viene distribuito negli ambienti e non il rollback significa che l'intero ambiente verrà interrotto.

Ovviamente, le azioni post build notificheranno al committer che Hey, hai rotto la build, così gli sviluppatori possono svolgere le loro altre attività, riceveranno comunque e-mail.

— deosha
fonte