L'integrazione continua è più che un semplice test del codice?

L'essenza di CI è di evitare ogni tipo di rami a lungo termine. Se si dispone di un team che lavora su un prodotto, un modello contrario all'IC deve scegliere un nuovo requisito per lo sviluppo di una funzionalità per il prodotto. Quindi il team crea un ramo di funzionalità nel VCS, a parte il ramo "trunk" o "master", sviluppano e testano la funzione per diversi giorni in isolamento, la reintegrano successivamente nel trunk e quindi eseguono i test di integrazione finali (nota che tra le altre parti del team potrebbe aver apportato modifiche anche al bagagliaio.

In CI, hai diviso la nuova funzionalità in più parti secondarie, ognuna delle quali creava ancora un prodotto funzionante e compilabile, e integrava molto spesso tale sotto-parte nel tronco principale, in genere più volte al giorno. Non ci sono rami con grandi differenze dal tronco, e se gruppi diversi di persone stanno lavorando simultaneamente su diverse caratteristiche, aggiorneranno quotidianamente ("continuamente") tutte le loro modifiche al codice base. Quasi tutti i test sono sempre eseguiti sul lavoro "integrato", non ci saranno quasi test su parti non integrate (eccetto i test eseguiti da ogni dev sulla propria copia locale prima di eseguire le modifiche).

Per questo, è necessario disporre di un processo di compilazione automatico supportato dal server e di numerosi test automatici eseguiti anche su quel server. Ciò darà un feedback immediato al team se le modifiche apportate potrebbero causare problemi sul prodotto integrato. Non è necessaria una "fase di test extra" per verificare se l'integrazione di una funzionalità più grande nel prodotto causa problemi. Ma quegli automatismi sono solo strumenti di supporto per far funzionare bene l'IC, questi passaggi non sono i passaggi che in realtà definiscono CI.

Automated testing sarebbe un termine per eseguire semplicemente i test ogni giorno, anche se il codice è stato fuso in uno stato completo una volta al mese o mai.

Probabilmente è una cattiva idea, perché se mantieni diversi filoni di sviluppo in diversi rami a lungo funzionamento ti unirai test e codice allo stesso tempo. E se le funzionalità interagiscono in qualche modo, unirle dovrebbe spostare alcuni test dal passaggio al fallimento; se no, non stavi testando le cose in modo adeguato.

Di conseguenza, diventa difficile capire quali errori di test sono regressioni, che sono prevedibili dato lo stato corrente di integrazione, che è stato temporaneamente disattivato e così via. In altre parole, interpretare i risultati del test diventa un processo manuale, anche se l'esecuzione di questi è automatizzata. Il che rischia di sprecare lo sforzo necessario per automatizzare il test in primo luogo.

Un modo parziale è che tutti i test automatici siano rigorosamente test unitari; letteralmente una classe alla volta, prendendo in giro tutto il resto senza eccezioni. E poi fai tutti gli altri test manualmente o tramite un sistema automatico al di fuori dell'ambito del repository e dei suoi rami.

L'integrazione continua è un processo di integrazione continua di nuovi cambiamenti con le altre persone. L'obiettivo è quello di eliminare i problemi di fusione che si sviluppano nel tempo quando molti sviluppatori stanno cambiando il codice in modo indipendente in diverse direzioni.

È di moda negli ambienti commerciali avere un controllo centralizzato del codice sorgente con un server di compilazione automatizzato con varie metriche di test e reporting eseguite sul codice in risposta a un cambio di codice e consentendo agli sviluppatori di lavorare in un ramo separato mentre si integrano altre persone completate cambia ma non condivide le loro modifiche fino a quando il loro lavoro non è completo - e per chiamare quella integrazione continua.

Tuttavia, non sono d'accordo. Questo tipo di approccio consentirà agli sviluppatori che lavorano su funzionalità sperate di apportare modifiche radicali per evitare l'integrazione fino a quando il primo sviluppatore non avrà completato la propria funzione. Quando fondono le loro modifiche nel ramo comune, allora scaricano il tipo di unire l'inferno sul loro collega che l'integrazione continua è destinata ad evitare.

La vera integrazione continua ha gli sviluppatori che si affidano spesso (molte volte al giorno) allo stesso ramo, assicurando che tutte le modifiche al codice siano integrate prima che possa verificarsi una significativa divergenza.

Come approccio, l'infrastruttura fornisce alcuni vantaggi nel ridurre l'impatto che possono avere sorprese inaspettate in fase di fusione, ma crea problemi altrove nel processo aziendale di rilascio e distribuzione del software. (ad esempio cercando di sviluppare nuove funzionalità mentre si risolvono i bug per la versione imminente)

Il mio consiglio è di evitare la devozione religiosa verso una metodologia, ma di implementare processi che supportano il tuo team e il tuo ambiente aziendale che riflettono il tuo modo di lavorare, il modo in cui la tua azienda lavora intorno a te e ti permette di concentrarti sulla consegna del software e non sulla gestione dei processi.