L'integrazione continua non genera mai errori di compilazione

Usa Maven, vale la pena dedicare tempo per impostare i tuoi progetti in modo conforme al suo modo di fare le cose. Ho bisogno anche di un repository interno locale per distribuire risorse, io uso Archiva. Quindi puoi impostare la tua versione di sviluppo su qualcosa di simile alla versione 1.1-SNAPSHOT e che conterrà automaticamente l'ultima versione di quel codice in fase di sviluppo quando viene distribuita su Archiva.

Passa alle versioni a versione fissa, versioni che non hanno il suffisso -SNAPSHOT per la produzione. Se lasci fuori <version/> su una dipendenza, per impostazione predefinita verrà utilizzata l'ultima versione rilasciata / non istantanea.

Tutto questo è stato progettato molto bene e funziona perfettamente con Hudson / Jenkins e qualsiasi altro strumento che si integri con Maven.

Gestiamo questo come parte del nostro sistema di build (SCons nel nostro caso). Cioè, specifichiamo la dipendenza della build da una versione di una libreria. Un tipico caso che abbiamo riscontrato nella nostra pipeline è che dobbiamo aggiornare un plug-in per un'applicazione, prima che l'applicazione possa compilare e installare, che la versione corretta del plugin debba essere compilata e installata e, facoltativamente, superare tutti i test unitari. Il vantaggio di rendere questo requisito di compilazione al posto del requisito di CI è che sia lo sviluppatore sia il sistema di elementi di configurazione sono impostati con gli stessi vincoli, il che dovrebbe semplificare questo tipo di situazione.

Prima eravamo abituati ad avere problemi del genere. Per noi ha risolto questi problemi poiché dichiari esplicitamente le versioni con cui vuoi lavorare. Offre anche una migliore visibilità sulle dipendenze transitive, che è il problema che stai combattendo.

Dichiarazione di non responsabilità: non sono uno sviluppatore Java e non ho mai usato Maven, quindi è del tutto possibile che invalidi tutto ciò che dirò di seguito. Ma potrebbe essere utile per le persone non-Java in seguito.

Se usi TeamCity 6, puoi utilizzare un passo del runner della riga di comando nella tua build che eseguirà xcopy per i giare dipendenti.

Se disponi di build TeamCity configurati che producono quelle librerie interne, puoi impostare dipendenze tra le build del tuo sito e le build della libreria in modo tale che una build di una libreria di successo possa innescare la costruzione di un sito. Se la build della libreria produce i jar come artefatti, TeamCity potrebbe quindi estrarre quei vasi anche nella build del sito.

Un'altra opzione (forse la peggiore) è controllare i vasi nel controllo del codice sorgente e configurare TeamCity per controllarli da lì per le build del sito e per attivare i build del sito quando vengono controllate le nuove librerie.