Come può essere utilizzato l'elemento della configurazione per le lingue interpretate?

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

Il primo è un flusso di lavoro: invece di tutti i membri di una squadra che lavorano nella propria filiale e dopo un paio di settimane di programmazione, tentano di unire le loro modifiche alla linea principale, tali modifiche sono integrate (quasi) continuamente. Ciò consente ai problemi di emergere in anticipo e di evitare modifiche incompatibili. Tuttavia, ciò richiede che possiamo facilmente verificare se una modifica "funziona".

È qui che arriva 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 tuo software funziona su sistemi diversi o in configurazioni diverse e devi essere sicuro 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 problemi. Se i test falliscono, lo sviluppatore appropriato dovrebbe ricevere una notifica in modo che possano risolvere il problema che hanno introdotto ("rottura della build", anche quando non c'è build come compilation).

Si scopre che un server di questo tipo è prezioso per qualcosa di più del semplice test. In effetti, la maggior parte dei software CI è davvero schifosa a eseguire test in varie configurazioni, ma è buona per gestire tutti i tipi di lavoro. Per 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 morti. Possiamo eseguire analisi statiche, controlli di stile, strumenti di copertura del test, ecc. Sul codice. La documentazione può essere generata. Al termine di tutte le suite di test, è possibile avviare il processo di packaging in modo da essere pronti a rilasciare il software. Questo è utile in un'impostazione agile in cui si desidera un prodotto distribuibile (e dimostrabile) in ogni momento. Con l'avvento delle app Web, c'è anche l'idea di implementazione continua : se tutti i test passano, possiamo automaticamente trasferire le modifiche alla produzione. Ovviamente, ciò richiede che tu sia veramente sicuro della tua suite di test (in caso contrario, hai problemi più grandi).

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

Lo scopo dell'IC è quello di rilevare gli errori il prima possibile, perché in generale, prima si verifica un errore, meno costoso è da correggere. A tal fine, nel caso in cui una fase di creazione non sia necessaria, un sistema di elementi di configurazione può ancora automatizzare l'uso di strumenti di analisi del codice, implementazione in un ambiente di test, unità / integrazione / regressione / altri test che è possibile automatizzare e qualsiasi altra procedura puoi eseguire automaticamente per verificare eventuali errori.

L'integrazione continua offre molto più di una compilazione del codice. Se è tutto ciò che ha fatto, allora non avremmo bisogno di così tanti strumenti per questo!

Alcuni altri compiti a cui posso pensare a mano a mano che spesso viene eseguita una pipeline di integrazione continua:

• Esecuzione di test automatici. (Python ha una vasta gamma di librerie di test automatizzate e PHP ne ha almeno alcune. Non posso parlare con MATLAB.)
• Raggruppamento del software per la distribuzione. Automatizzando questo processo, ci si assicura che venga eseguito in modo esatto, coerente e ripetibile ogni volta. Nessun passo sarà dimenticato; generare un tale pacchetto di distribuzione richiede al massimo un clic. (Raggruppare la tua app Python come una ruota è una grande idea!)
• Il tagging si impegna. Ogni volta che crei un pacchetto per la produzione, probabilmente vorresti taggarlo.
• Numeri di versione con incremento automatico. Solitamente questo sarebbe solo il numero di "build" e non le parti più significative, ma può essere bello identificare in modo univoco una particolare build, in modo da sapere cosa viene distribuito dove.

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

• Avere un processo automatico per la configurazione di un sistema operativo e l'installazione delle dipendenze.
• Distribuzione automatica di copie del software (utile soprattutto per applicazioni Web o software distribuito da un gestore di pacchetti). Alcuni team lo utilizzano effettivamente per la distribuzione (produzione continua), ma anche se non lo fai, puoi comunque sfruttarlo per distribuire copie extraprodotte del codice. Per alcuni progetti in cui lavoro, abbiamo una copia per gli sviluppatori per testare il loro codice prima di renderlo disponibile per il QA, una copia per il QA da testare e una copia più "stabile" per scopi di dimostrazione.

Il punto è semplicemente questo: ci sono compiti che devi eseguire periodicamente nel processo di sviluppo del software oltre alla semplice scrittura del codice. Automatizzando queste attività e facendole girare su un server, si ottiene

• Processo coerente (non dovrai fare in modo che Stan e Sally facciano cose diverse.)
• Conoscenza dei processi registrati nel codice (Chiunque sia in grado di leggere gli script può apprendere i passaggi necessari per la distribuzione, invece che Sally è l'unico che lo fa o sa come.)
• Semplificazione della duplicazione dei processi (semplice implementazione di 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 salvare un file. Stan ha aggiunto una nuova dipendenza che deve essere installata accanto all'app ma non se ne è accorta perché è stata installata automaticamente dall'IDE, ho visto tutto questo in una forma o nell'altra.)

E probabilmente altri vantaggi che non ti vengono nemmeno in mente.

Potresti non aver bisogno di compilare le soluzioni, ma CI può ancora aiutarti cambiando i file di configurazione / percorsi di cartella ecc. e se sei in un team, promuovendo le modifiche allo stato dei prodotti e distribuendole

Supponiamo di aver distribuito il codice Python in 5 diversi server QA e di aver bisogno di puntare a database QA diversi, e quindi una volta eseguito il test automatico (attivato da CI), promuovendo la build in produzione e distribuendola lì con le modifiche di configurazione appropriate per ogni server di produzione.