Potrei mancare qualcosa ma non capisco perché nel worklow comunemente descritto la Build segue le fasi del Codice. Voglio dire, non è il contrario? Codifichiamo, integriamo i cambiamenti, lo costruiamo, lo testiamo ...
L'immagine è ad esempio sul sito sottostante:
Scrivo del codice, poi lo compilo (lo compilo) e poi eseguo i test. Questo succede sulla mia macchina locale. Questa è la fase "code & build" in quel diagramma.
Quindi controllo il mio codice in un repository centrale, attivando una build remota e un test remoto. Ora ho eseguito un test "non funziona solo sulla mia macchina". Ho "integrato" il mio codice in un repository centrale, quindi è la fase di "integrazione".
In definitiva, molto di questo è solo semantica. Un gran numero di processi IT fa ancora riferimento all'intero ciclo "codice, compila, prova, ripeti" come "build". Il diagramma a cui si collega non mostra il test sul computer locale, né mostra "build" sul build server.
Quindi prendi questi diagrammi con un pizzico di sale e non perdere il sonno su di loro. Se senti di "perdere qualcosa" quando guardi un diagramma di questo tipo, ricorda che probabilmente si riduce a te usando un modello semantico leggermente diverso per descrivere tali cose a ciò che l'autore ha usato.
Dipende dal tipo di sistema che si ha in mente e da cosa "integrare" significa in quel sistema. Quando si parla di implementazione e consegna continue, lo scenario 99% è sistemi di applicazioni web . A seconda dei linguaggi e dell'architettura utilizzati, potrebbero esserci componenti compilabili che devono essere creati prima prima che possano essere integrati nell'applicazione web. Il passaggio di integrazione quindi li mette nel posto giusto sul server web, oltre a un test di integrazione.
Leggi altre domande sui tag continuous-integration continuous-delivery devops