Esiste uno strumento CI che non garantisce regressioni nel livello di qualità delle filiali?

Tradizionalmente i sistemi di CI eseguono il monitoraggio dei livelli di qualità in un ramo di integrazione, eseguendo verifiche di controllo qualità sulla base di codice in cui sono già state eseguite le modifiche, controllando le regressioni e inviando notifiche per l'intervento umano.

Ma quando vengono rilevate queste regressioni, la filiale è già nei guai almeno da quando è iniziata la rispettiva verifica del QA e rimarrà in tale stato (o addirittura peggiorerà!) Fino a quando tutti i colpevoli non saranno identificati, le riparazioni per loro commesse e una nuova verifica del QA conferma che il livello di qualità del ramo è stato ripristinato. Il ramo può essere considerato bloccato per il normale sviluppo durante tutto questo tempo.

Esiste uno strumento CI in grado di prevenire realmente tali regressioni, che verificherebbe verifiche di QA pre-commit e consenti i commit solo quando la base di codice aggiornata con i rispettivi commit passerebbe anche quelle verifiche di QA pre-commit, garantendo così un minimo livello di qualità del ramo?

Aggiornamento: si presume che siano disponibili per l'invocazione le verifiche di QA automatizzate adeguate con copertura adeguata per poter rilevare le rispettive regressioni tramite gli strumenti CI.

Per quanto ne so, stai cercando uno strumento che rifiuterà i commit che interrompono la compilazione: uno strumento CI probabilmente non sarà in grado di prevenire le regressioni correggendo effettivamente il codice, ma può impedirti di aggiungere codice errato al repository.

Atlassian ha alcune interessanti applicazioni di ganci Git :

Gli hook di pre-ricezione sul lato server sono un complimento particolarmente potente per l'integrazione continua perché possono impedire agli sviluppatori di spingere il codice sul master, a meno che il codice non soddisfi determinate condizioni - come i guardiani ninja d'élite, proteggendolo da un codice errato.

Se stai usando Git, gli hook sono molto potenti (e ci sono hook simili per SVN , Mercurial e altri sistemi di controllo della versione) e potresti trovare utile usarli per eseguire controlli pre-commit.

La documentazione di Git ha una pagina sulla creazione di un hook per rifiutare push se non soddisfano determinati criteri che potrebbero essere facilmente adattati a questo caso d'uso.

Tuttavia, molte persone sostengono che il rifiuto dei commit sia una cattiva idea in un featureramo: perderai semplicemente tempo a combattere contro il tuo sistema CI quando la build si rompe per qualche motivo, invece di correggere effettivamente il bug.

Sul masterramo, potrebbe avere senso rifiutare le fusioni interrotte, perché potresti voler assicurarti che si sviluppi sempre. Per un featureramo, si sarà inevitabilmente rompere le cose, e dal momento che il codice non sta andando in produzione ora , ha più senso solo avvertirti che in realtà rifiutare la commit del tutto.

Nessuno strumento potrebbe garantire nessuna regressione, ciò dipende molto più dai test che dallo strumento che li esegue. Tuttavia, puoi aiutare a prevenire le regressioni che verranno catturate dall'entrare nel ramo di integrazione. Puoi farlo con hook pre-commit, ma spesso è più facile con le richieste pull (che si spera tu stia già utilizzando per la revisione del codice peer).

Se una succursale è aggiornata con il suo upstream (dove il PR si sta fondendo) e i suoi test superano, allora passeranno comunque dopo l'unione; lo stato del ramo di destinazione dopo l'unione corrisponderà allo stato del ramo di origine prima dell'unione.

In genere non è particolarmente difficile (a seconda degli strumenti utilizzati) indicare se il ramo di origine in un PR è aggiornato con la destinazione e se ha una build CI passante. È possibile utilizzare questo come requisito (per criterio e / o imposto nel software) per unire la richiesta pull.

Veri strumenti di integrazione continua (al contrario di semplici test continui) come Reitveld e Zuul possono essere d'aiuto, anche se sono buoni tanto quanto i test che scrivi e le recensioni di codice che fai.

Usa GitLAB, puoi impostare le impostazioni del progetto per consentire l'unione solo quando la pipeline ha successo, quindi puoi avere un'integrazione veramente continua, combinare quella con l'aggiunta del QA all'elenco delle approvazioni di unione e con gli ambienti dinamici, puoi avere la garanzia della qualità prima di unirti al maestro.

ApartCI è un sistema CI progettato esattamente per prevenire le regressioni, garantendo così un livello di qualità del ramo piatto o in aumento. Ancora in beta.

Orchestra le verifiche centralizzate di pre-commit in modo tale da garantire che una modifica venga impegnata solo dopo che è stata verificata, insieme a tutte le altre modifiche commesse prima di esso, per soddisfare o superare l'ultimo livello di qualità della filiale.

Questa è la differenza chiave rispetto alle tradizionali verifiche pre-commit guidate dallo sviluppatore, spesso eseguite in parallelo, che lascia spazio a regressioni causate da interferenze che non sono mai state testate insieme.

Lo strumento è inoltre progettato per adattarsi facilmente , in grado di sostenere percentuali molto elevate di modifiche dei candidati in arrivo e supportare centinaia di migliaia di sviluppatori che lavorano nello stesso ramo di integrazione.

Disclaimer: sono l'autore dello strumento e il fondatore dell'azienda che lo offre. Ci scusiamo per l'annuncio.