Questo commento suona bene.
Secondo me, la maggior parte possibile del codice di build dovrebbe essere negli script di build interni del prodotto, come ad esempio build.xml, maven's pom.xml, ecc. Questo ha 3 scopi:
- Versioni del processo di creazione insieme al prodotto. Se si esegue il fork di una diramazione del prodotto nel controllo del codice sorgente e si apportano modifiche che richiedono modifiche di build (ad esempio, si aggiunge un passaggio minify ai file javascript che prima non erano presenti), non è necessario modificare nulla al di fuori del controllo del codice sorgente.
- Facilità di sviluppo e on-boarding. Come sviluppatore, è ottimo per la produttività quando posso semplicemente eseguire il checkout del codice dal controllo del codice sorgente ed eseguire un comando di build, sia esso
ant clean build o mvn package o qualsiasi altra cosa.
- Rimuove la dipendenza dall'elemento della configurazione per i build. Tu dovresti usare CI per i build, ma se Jenkins è inattivo per qualsiasi motivo, non vuoi essere in grado di creare. L'elemento della configurazione dovrebbe riguardare l'automazione di un processo di generazione ottimizzato esistente.
Idealmente, un server CI deve essere configurato per fare semplicemente questo:
- Checkout
- Esegui un comando di build, preferibilmente lo stesso comando eseguito dagli sviluppatori o forse un super-set di questi comandi.
- Archiviare la build in un percorso di archivio di build ufficiale.
Dove questo diventa meno chiaro è con i processi che si verificano in fase di compilazione ma che non sono strettamente necessari per la compilazione, come i test di unità e di integrazione.
La mia preferenza sarebbe includere i test unitari nel core build. Cioè, non puoi ottenere una build, nemmeno in dev, senza che i test unitari funzionino e passino. Certo, ciò richiede un'enorme quantità di disciplina e raramente viene fatto. Se sei abbastanza fortunato da avere un ambiente che esegue test unitari automatizzati, includerli nel core build sembra una buona idea.
I test di integrazione, tuttavia, possono richiedere molto più tempo, quindi eseguirli ogni volta che vuoi semplicemente compilare il codice può essere un enorme spreco di produttività. Immagina se ogni compilatore - > il ciclo di test richiede una suite di test di integrazione di un'ora. Dovresti compensare compilando meno spesso il che significa meno test e naturalmente non ne uscirà alcun bene.
Quello che vorrei fare è definire tale funzionalità negli script di compilazione all'interno del controllo del codice sorgente, ma non collegarli al core build. Non conosco Maven molto bene, ma per ant, definirei un target separato, come ant integrationTests che è necessario eseguire esplicitamente. Questo potrebbe essere configurato nel sistema di CI e in questo modo, gli sviluppatori possono scegliere se / quando eseguirlo da soli sui propri sistemi.
Per mettere in una vista della pipeline, forse qualcosa di simile:
Pagamento - > Build - > Test di integrazione - > Test di sistema - > Test delle prestazioni - > Carica test - > Archivia build - > Deploy
L'implementazione di ognuno di questi passaggi dovrebbe vivere all'interno degli script di build del prodotto nel controllo del codice sorgente (tranne che per il checkout, altrimenti hai un problema di pollo o uovo) e il processo di processo possiede la decisione di passo per chiamare in quale ordine. Alcuni passaggi potrebbero non essere necessari per ogni build. I test di caricamento, ad esempio, possono essere eseguiti solo una volta.
Questo è il mio 2 centesimi. Non sono affatto un'autorità in materia, ma ho visto le build fatte bene e le build fatte male.