Come si può usare CI per le lingue interpretate?

Non ho mai usato un sistema di integrazione continua (CI) prima. Principalmente codice in MATLAB, Python o PHP. Nessuno di questi ha una fase di costruzione e non vedo come un elemento della configurazione possa essere utilizzato per il mio lavoro. Un amico in un grande progetto in una grande azienda mi ha detto che la lingua non ha importanza.

Non vedo come CI sarebbe utile se non avessi un passo di costruzione. Posso pensare a CI come a un ambiente di test che eseguirà test unitari. Mi sto perdendo qualcosa?

L'integrazione continua come termine si riferisce a due idee distinte.

Il primo è un flusso di lavoro: invece di tutti quelli che fanno parte di una squadra che lavora nel proprio ramo e poi dopo un paio di settimane di programmazione cercano di fondere i loro cambiamenti nella linea principale, che i cambiamenti vengono integrati (quasi) continuamente. Ciò consente ai problemi di emergere presto ed evita modifiche incompatibili. Tuttavia, ciò richiede che possiamo facilmente verificare se una modifica "funziona".

È qui che entra in gioco la seconda idea, che si è rivelata molto più popolare. Un server CI è un ambiente pulito in cui le modifiche vengono testate il più rapidamente possibile. L'ambiente pulito è necessario affinché la build sia riproducibile. Se funziona una volta, dovrebbe sempre funzionare. Questo evita problemi "ma ha funzionato sulla mia macchina". In particolare, un server CI è prezioso quando il software viene eseguito su sistemi diversi o in configurazioni diverse ed è necessario assicurarsi che tutto funzioni.

La mancanza di un passo di costruzione è irrilevante. Tuttavia, CI ha senso solo se si dispone di una suite di test. Questa suite di test deve essere automatica e non deve presentare errori. Se i test falliscono, lo sviluppatore appropriato dovrebbe ricevere una notifica in modo che possano risolvere il problema che hanno introdotto ("interruzione della compilazione", anche quando non esiste una compilazione come compilation).

Si scopre che un server del genere è prezioso per qualcosa di più del semplice test. In effetti, la maggior parte dei software CI è davvero scadente nell'esecuzione dei test in varie configurazioni, ma è bravo a gestire tutti i tipi di lavori. Ad esempio, oltre ai test unitari "continui", potrebbe esserci un test completo come build notturno. Il software può essere testato con più versioni di Python, diverse versioni di libreria. Un sito Web potrebbe essere testato per collegamenti non funzionanti. Possiamo eseguire analisi statiche, controlli di stile, strumenti di copertura dei test, ecc. Tramite il codice. La documentazione può essere generata. Quando tutte le suite di test passano, il processo di packaging può essere avviato in modo da essere pronti a rilasciare il software. Ciò è utile in un'impostazione agile in cui si desidera un prodotto distribuibile (e dimostrabile) in ogni momento. Con l'ascesa delle app Web, c'è anche l'idea di una distribuzione continua: Se tutti i test vengono superati, possiamo inviare automaticamente le modifiche alla produzione. Naturalmente, questo richiede che tu sia davvero fiducioso nella tua suite di test (in caso contrario, hai problemi più grandi).

È vero, non è necessario un sistema di elementi della configurazione particolare per eseguire build e verificare che tali build siano corrette, ma questa è solo una parte di ciò che riguarda l'elemento della configurazione.

Lo scopo di CI è di rilevare gli errori il più presto possibile, perché in generale, prima viene rilevato un errore, più economico è da risolvere. A tal fine, nel caso in cui non sia necessario un passaggio di compilazione, un sistema CI può ancora automatizzare l'uso di strumenti di analisi del codice, la distribuzione in un ambiente di test, l'unità / integrazione / regressione / altri test che è possibile automatizzare e qualsiasi altro passaggio puoi eseguire automaticamente per verificare la presenza di errori.

L'integrazione continua esegue più di una compilazione del codice. Se è tutto quello che ha fatto, allora non avremmo bisogno di così tanti strumenti per farlo!

Alcune altre attività che mi vengono in mente sono che una pipeline di integrazione continua esegue spesso:

• Esecuzione di test automatici. (Python ha molte librerie di test automatizzate e PHP ne ha almeno alcune. Non posso parlare con MATLAB.)
• Raggruppamento del software per la distribuzione. Automatizzando questo processo, si assicura che venga eseguito in modo esatto, coerente e ripetibile ogni volta. Nessun passo sarà dimenticato; la generazione di un tale pacchetto di distribuzione richiede al massimo un clic. (Raggruppare la tua app Python come una ruota è un'ottima idea!)
• L'etichettatura della pietra miliare si impegna. Ogni volta che costruisci un pacchetto per la produzione, probabilmente vorrai etichettarlo.
• Numeri di versione con incremento automatico. Di solito questo sarebbe solo il numero "build" e non le parti più significative, ma può essere utile identificare in modo univoco una particolare build, in modo da sapere cosa viene distribuito dove.

Andando un po 'oltre la linea di confine dell' "integrazione continua" in senso stretto, potresti anche fare questi:

• Avere un processo automatizzato per l'impostazione di un sistema operativo e l'installazione delle dipendenze.
• Distribuire automaticamente copie del software (utile principalmente per applicazioni Web o software distribuito da un gestore di pacchetti). Alcuni team lo usano effettivamente per distribuire alla produzione (consegna continua), ma anche se non lo fai, puoi comunque sfruttarlo per distribuire copie extra, non di produzione del codice. Per alcuni progetti in cui lavoro, abbiamo una copia per gli sviluppatori per testare il loro codice prima di renderlo disponibile al QA, una copia per il QA da testare e una copia più "stabile" ai fini della dimostrazione.

Il punto è semplicemente questo: ci sono compiti che devi svolgere periodicamente nel processo di sviluppo del software oltre a scrivere semplicemente il codice. Automatizzando queste attività e facendole funzionare su un server, si ottiene

• Processo coerente (non avrai Stan e Sally a fare le cose in modi diversi).
• Conoscenza dei processi registrati nel codice (Chiunque sia in grado di leggere gli script può imparare i passaggi necessari per la distribuzione, invece che Sally sia l'unico che lo fa o sa come fare.)
• Duplicazione dei processi più semplice (Semplice da distribuire più copie del sito Web: basta fornire una nuova configurazione!)
• Test più approfonditi (Bob ha testato solo la sua pagina, ma le sue modifiche hanno interrotto la pagina di Sally. Sally ha dimenticato di eseguire il commit di un file. Stan ha aggiunto una nuova dipendenza che deve essere installata insieme all'app ma non se ne è accorta perché è stata installata automaticamente dall'IDE Ho visto tutto questo in un modo o nell'altro.)

E probabilmente altri benefici che non mi vengono nemmeno in mente.

Potrebbe non essere necessario compilare le soluzioni, ma CI può ancora aiutarti modificando i file di configurazione / i percorsi delle cartelle ecc. E se sei in una squadra, promuovendo le modifiche allo stato del prod e distribuendole

Supponi di distribuire il tuo codice Python su 5 diversi server QA e di aver bisogno che punti a diversi database QA, quindi una volta eseguito il test automatizzato (attivato da CI), promuovendo la generazione alla produzione e distribuendolo lì con le modifiche di configurazione appropriate per ogni server di produzione .