Cosa significa "build automatizzata"?

Sto cercando di aggiungere l'integrazione continua a un progetto.

Secondo Wikipedia , un pezzo importante di CI sono le build automatizzate. Tuttavia, sono confuso su cosa, esattamente, ciò significhi, dal momento che l'IC e gli articoli di automazione sembrano non essere d'accordo.

Punti specifici di confusione: cosa significa "costruzione automatizzata" nel contesto di:

• un progetto che usa un linguaggio interpretato, come Python o Perl?
• costruendo dalla fonte su una macchina dell'utente finale?
• un'applicazione che ha dipendenze che non possono essere semplicemente precompilate e distribuite, come un database in un RDBMS locale sul computer dell'utente?

Hai ragione nel notare che, per alcune tecnologie, non è necessario un passo di compilazione. Tuttavia, ti consiglio di avere una visione più ampia nell'interpretazione del termine "build automation". Pensa a "build" includendo i seguenti due componenti principali:

• Il processo per gli artefatti di origine della trasformazione (codice, schema del database, documentazione, ecc.) Distribuito a un utente finale.
• L'applicazione di misure di garanzia della qualità durante detta trasformazione

L'automazione, quindi, si limita semplicemente a rendere automatiche (se non tutte) quelle operazioni (ovvero, che non richiedono un intervento manuale). Ciò può includere una varietà di passaggi, a seconda della tua tecnologia:

Passaggi di trasformazione:

• Compilazione
• Collegamento
• Confezione
• Distribuzione
• Migrazione dei dati
• di riserva
• Notifica

Passaggi di garanzia della qualità:

• Avvertenze / errori del compilatore
• Test unitari
• Test di integrazione
• Test di sistema
• Autenticazione di distribuzione

In questi giorni, buoni strumenti di CI ti permetteranno di affrontare tutte queste preoccupazioni. Inizialmente, la maggior parte dei negozi è interessata all'automazione della compilazione del proprio codice, poiché questa è la prima - e la più visibile - fonte di problemi nello sviluppo di software convenzionale.

Una build automatizzata è una descrizione di un processo che dovrebbe comprendere le seguenti basi:

1. Scarica l'ultimo codice dal controllo del codice sorgente
2. Compilare l'ultimo codice nell'eseguibile
3. Esegui test (unit test, test di sistema, test di integrazione) rispetto al codice compilato
4. Distribuire il file eseguibile completato in un percorso noto per la distribuzione.
5. Pubblica i risultati della build.
   5.1 Compilazione riuscita, successo del test unitario

È un processo pratico, che dovrebbe essere eseguito senza intervento manuale.

Secondo me, una build automatizzata è qualcosa che

• avviene automaticamente, su una pianificazione o con ogni commit per il controllo del codice sorgente
• crea una serie di artefatti che possono essere distribuiti semplicemente su qualsiasi server

L'obiettivo è quello di avere un processo di distribuzione che può essere ripetuto - leggi: testato - in modo tale che, al momento della distribuzione in produzione, si abbia un certo grado di certezza che le cose non vadano male. Meno interazione umana nei processi di compilazione e distribuzione, più sicura sarà la tua versione.

Se hai un linguaggio non compilato, puoi comunque creare un sito e comprimerlo per creare un singolo artefatto.

Un buon strumento CI ti permetterà di eseguire lo script di molte attività nel processo di compilazione, incluso l'esecuzione di unit test. Manterrà anche le registrazioni delle build riuscite e non riuscite, della copertura dei test, ecc. Ma nulla di tutto ciò fa parte di ciò che definirei una build automatizzata. (vale a dire. Un buon processo di compilazione automatizzata ha queste cose, ma uno scadente non può non essere chiamato "build automatizzata" perché manca di quelle cose.)

Suggerirei che i test di integrazione / regressione vengano eseguiti come parte del processo di distribuzione, piuttosto che del processo di compilazione (anche se, se si dispone di un ambiente conveniente, è possibile distribuire con ogni build).

a project using an interpreted language, such as Python or Perl?

Nel caso delle lingue interpretate, le cose possono essere colpite o mancate. Alcuni linguaggi compenetrati hanno compilatori, ma il più delle volte probabilmente non c'è molto bisogno di usarli. In tal caso, in genere eseguivo la scansione del codice per verificare la sintassi e analizzare gli errori al posto della compilazione o saltare direttamente all'esecuzione dei test sul codice.

costruendo dalla fonte su una macchina dell'utente finale?

Per me questo significherebbe che è possibile fornire un singolo comando che gli utenti finali possono eseguire per ottenere l'ultima versione del programma, compilarlo, configurarlo e distribuirlo secondo necessità.

un'applicazione che ha dipendenze che non possono essere semplicemente precompilate e distribuite, come un database in un RDBMS locale sul computer dell'utente?

Questi rientrerebbero nella parte di test dell'integrazione continua in quanto è possibile distruggere e ricostruire automaticamente i database per garantire che gli script siano corretti e che il programma esegua correttamente il test.

Ciò di cui stai discutendo nella tua domanda sono in realtà 3 concetti diversi:

L'integrazione continua al suo interno sta facendo piccoli cambiamenti e spesso sincronizzando tali cambiamenti con la "verità globale". Invece di fare un checkout e trattenerlo per una settimana, uno sviluppatore dovrebbe lavorare su attività che possono essere completate entro un giorno in modo che il suo codice non sia mai troppo lontano dalla sincronizzazione con il repository principale.

Per raggiungere questo obiettivo senza causare dolore alla sua squadra (ad esempio, il check in nella fonte che non crea o interrompe la funzionalità esistente). Lo sviluppatore deve verificare che il suo codice non "rompa la build". Se fatto manualmente, questo aggiunge un ulteriore sovraccarico al processo di sviluppo (pensate a un progetto che richiede molto tempo per essere costruito e / o ha molte interdipendenze in cui una modifica a una riga di codice può influire sull'applicazione in modi imprevisti).

Per mitigare questa situazione, utilizziamo altre tecniche per rimuovere questo sovraccarico.

Usiamo build automatizzate per il checkout del sorgente e costruirlo facoltativamente eseguendo test automatici che verificano che l'applicazione funzioni come dovrebbe (questo passaggio è utile solo come la suite di test).

Un ulteriore passaggio di consegna continua risolve il problema con il database e altre preoccupazioni. L'idea qui è quella di fornire un certo livello di controllo delle versioni per il database e altri fattori dell'ambiente in modo da poter confermare il più rapidamente possibile che l'applicazione funzioni in un ambiente il più vicino possibile alla produzione .

"Build automatizzato" significa che è possibile passare dal controllo del codice sorgente a un pacchetto shippable con un'azione (programmabile) (in genere uno script shell o un file batch).

Ciò che costituisce esattamente una build, in questo contesto, dipende molto da cosa esattamente stai spedendo, come viene consegnato e quali passaggi sono necessari per le varie parti del tuo stack di sviluppo, ma in ogni caso, inizi con cosa c'è nel controllo del codice sorgente e si finisce con un prodotto spedibile (o un messaggio di errore e un project manager arrabbiato).

Per un semplice progetto Python, una build automatizzata potrebbe consistere in solo due passaggi: il check out dei sorgenti e la copia dei file rilevanti nelle directory corrette. Per progetti più complessi, potrebbe comportare cose come:

• compilazione, collegamento
• esecuzione di test automatizzati
• creazione di pacchetti di installazione
• installazione
• modifica database
• creazione di backup (nel caso sia necessario il rollback)