CD condiviso (distribuzione continua) per più repository Git

Question

CD condiviso (distribuzione continua) per più repository Git

Naviga le tue risposte

#1 da (1 voti)

6

Breve storia

Qual è il modo migliore per progettare un CD condiviso per più repository Git (frontend e backend)?

Sto lottando per trovare il miglior design per il nostro CD.

L'immagine del foro (i dettagli possono essere modificati)

Frontend - Angular 2 (Javascript), no artifactory.
Ci sarà solo un frontend singolo nel progetto.
Backend - ASP.NET (C #), nessuna artefice.
Ci sarà un solo back-end nel progetto.
Git repository su Git TFS per ciascuno.
Server per Jenkins.
Più macchine, Dgroup , per la distribuzione dell'ultima versione dal ramo development da entrambi i repository - un parco giochi per ogni sviluppatore.

I miei obiettivi:

development ramo deve essere protetto da pull request e build deve passare. Più in dettaglio: Jenkins deve confermare che l'ultima versione del ramo che ha attivato la richiesta pull è stata compilata e che i test del suo repository sono passati. Anche i test di integrazione con l'altro repository non falliranno (i test del frontend). Significato per ogni richiesta di pull in ogni repository, Jenkins ha bisogno di "unificare" la build per entrambi i repository. Se ogni test di ciascun repository viene superato, la richiesta pull è pronta per essere approvata. Altrimenti, la richiesta di pull è negata.
Dopo ogni richiesta di pull approvata, le macchine Dgroup devono essere aggiornate per avere l'ultima versione del prodotto (servizi + file frontend).

Difetti:

Non riesco a trovare un modo per raggiungere il mio primo obiettivo da più motivi:

Il frontend non può spingere nessuna nuova caratteristica dall'inizio finché il backend non finirà la stessa funzione dal suo lato, altrimenti alcuni test di frontend non passeranno. Non so come influenzerà il flusso di lavoro del frontend e se è la migliore pratica.
Immagina una situazione in cui il ramo development in entrambi i repository è interrotto, ma ancora n. 1 ha scritto il test giusto che troverà gli errori (Per ora la generazione passa). Ora il frontend crea una richiesta pull che contiene un test che trova un bug nel back-end. Quindi la build non passa così automaticamente la sua richiesta di pull è negata.

Ora il backend risolve il problema e prova a richiamare la richiesta. Ora il suo cambiamento fallisce anche un test del frontend. Quindi anche la sua richiesta di pull è stata respinta. Di conseguenza, nessuno può più richiamare la richiesta.

Il design del mio CD, che non ho descritto a causa dei difetti, mi impedisce di andare avanti. Qual è la prassi migliore per progettare un CD per più repository Git?

git continuous-integration repository continuous-delivery jenkins

posta Stav Alfi 06.10.2017 - 22:57

fonte

1 risposta

Leggi altre domande sui tag git continuous-integration repository continuous-delivery jenkins

Domain Driven Design - Migliorare il lavoro degli sviluppatori Posso usare algoritmi citati pubblicamente per scrivere programmi?

score 1 · Answer 1

IMHO la causa principale del tuo problema è il tentativo di gestire un intero sistema (frontend + backend) pur consentendo a ciascuna delle parti di muoversi indipendentemente e senza il supporto adeguato dello strumento per farlo.

Un approccio migliore (IMHO) sarebbe quello di progettare il tuo approccio CI / CD con il sistema in mente. Qualsiasi modifica a una parte del sistema (oa una sua combinazione) deve sempre passare attraverso la verifica dell'intero sistema. In questo modo si garantisce che lo stato attivo rimanga sempre sull'integrità dell'intero sistema. Lo so, questo va contro la tendenza dei microservizi (a cui non sono molto affezionato, una delle ragioni è esattamente perché lasciano spazio a questo tipo di problemi), ma fondamentalmente è ciò di cui hai bisogno.

La complicazione è che gli strumenti tradizionali della CI, incluso Jenkins, non sono realmente progettati per tale approccio. Potresti provare a modificarlo, ma immagino che non sia un compito facile.

Un altro problema è quello che chiamerei verifiche assolute e solo verifiche di regressione (o delta, se vuoi): ad esempio non dovresti rifiutare una modifica al frontend se le verifiche falliscono il test perché la porzione di backend non viene eseguita - quel test non è passato prima, quindi non è una regressione. Solo dopo che le funzionalità di frontend e backend sono state completate e il test è riuscito a passare almeno una volta un errore di test dovrebbe bloccare il commit, perché ora è una regressione. Donno se Jenkins supporta tale funzionalità.

potresti voler dare un'occhiata a ApartCI , è stato progettato con uno sviluppo orientato al sistema in mente. Disclaimer: l'ho progettato e sono il fondatore dell'azienda che lo offre.