Sync mismatches - Pipeline CI / CD

0

Stiamo implementando CI / CD nella nostra azienda e abbiamo un progetto normativo che richiede molto tempo per testare. Non c'è modo di scomporlo perché il progetto contiene circa 300 regole, ognuna delle quali deve essere testata ogni volta. Altri progetti hanno un tempo di test molto più ridotto e controllano con la linea principale molto più frequentemente. Per il progetto di regolamentazione, tiriamo dalla linea principale e facciamo un test di integrazione, ma al momento del check-in, ci sono 10 di check-in da altri progetti e questi dovrebbero essere nuovamente testati. Qualsiasi aiuto sarà apprezzato!

Nello schema allegato, il Progetto B indica il progetto normativo e durante il periodo di test del Progetto B, il Progetto A è stato registrato due volte e sincronizzato con la linea principale.

    
posta paranoidhb 19.09.2017 - 14:29
fonte

2 risposte

2

L'ottimizzazione dei test è probabilmente la prima cosa da considerare. Detto questo, probabilmente non sarà abbastanza. Poche strategie puoi esaminare, ognuna con il proprio insieme di inconvenienti, quindi sarà inevitabilmente un compromesso.

Isolare la versione dei progetti Separare entrambi i progetti nella propria pipeline di repo / build e integrarli come dipendenze esterne. In questo modo i loro cicli di commit non interferiranno l'uno con l'altro. Tratta il progetto A come prodotto / libreria e rilascialo con il proprio schema di controllo delle versioni. Il Progetto B è quindi libero di integrare la versione scelta e testarla. L'inconveniente di questo approccio è che il Progetto B è sempre in ritardo rispetto allo sviluppo del progetto A. Se un altro progetto dipende da A e B, sarà in ritardo rispetto a B e otterrà le sue dipendenze da B. Ciò significa che qualsiasi modifica apportata ad A dovrà ridursi ad un ritmo molto più lento rispetto al prodotto finale perché dovrà creare una versione, attendi che B rilasci questa dipendenza in una dipendenza e attendi che B completi i test e ne facciane uno di sua proprietà. Nota che questo non significa uno sviluppo più lento, solo che le modifiche apportate da A richiedono più tempo per raggiungere il prodotto finale. Detto questo, lo renderà molto più prevedibile.

Blocca il ramo principale durante i test di B fino a quando non è integrato Lo sviluppo di A continuerà nel suo stesso ramo ma non sarà in grado di fondersi nel main fino a quando il test di B non sarà terminato e si è fuso nel main.

Hai solo questi due progetti, quindi non è così male. Se dovessi avere altri che hanno una frequenza di commit simile a A, dovrebbero essere tutti sullo stesso ramo (ad esempio un ramo principale in cui B ottiene le cose e si impegna a farlo, un ramo dev dove tutto il resto va e viene e va a e dal ramo principale.

Ancora una volta, stai rallentando al ritmo del più lento. La chiave qui è di non interrompere tutto del tutto, così il dev di A può continuare, ma si sincronizzerà solo in momenti specifici con il main.

    
risposta data 19.09.2017 - 16:19
fonte
0

Potresti trovare utile un diverso flusso di lavoro di controllo del codice sorgente. Questa pagina di Atlassian offre un buon confronto tra diversi flussi.

In particolare, git-flow potrebbe aiutare a risolvere questo problema. Il concetto è simile a quello descritto da @Newtopian. Se disponevi di un ramo separato per i test normativi tra i tuoi rami develop e master , gli sviluppatori potevano effettuare frequenti check-in per lo sviluppo e fusioni, build e test periodici (overnight?) Potevano essere eseguiti dal ramo dei test normativi. Git-flow parla di "regole della strada" per ridurre al minimo i problemi di integrazione.

    
risposta data 19.10.2017 - 00:59
fonte