Il miglior metodo per organizzare / gestire le dipendenze nel VCS all'interno di una soluzione di grandi dimensioni

3

Un semplice scenario:

  • 2 progetti sono in controllo della versione
    • L'applicazione
    • Il test (s)
  • Un numero significativo di check-in viene effettuato giornalmente sull'applicazione.
  • CI crea e gestisce tutta l'automazione ogni notte.

Per scrivere e / o eseguire test è necessario aver creato l'applicazione (per fare riferimento / caricare assiemi strumentati). Ora, considera l'applicazione massiccia , in modo tale che la sua costruzione sia proibitiva nel tempo (un'intera giornata da compilare). L'ovvio effetto collaterale qui è che una volta eseguita una build a livello locale, è immediatamente incoerente con l'ultima.

Ad esempio:

Se dovessi eseguire la sincronizzazione con le ultime e aprire uno dei progetti di test, non verrà creato localmente fino a quando non avrò creato l'applicazione. Questo è lo stesso quando si esegue la sincronizzazione con un altro ramo / build / tag. Quindi, per iniziare a lavorare, ho bisogno di aspettare un giorno per creare l'applicazione localmente, in modo che gli assembly possano essere caricati - e quindi quegli assembly non sarebbero più recenti.

Come organizzi il repository o (idealmente) il tuo ambiente di sviluppo in modo che tu possa continuamente sviluppare test contro qualunque sia la build attuale, o una specifica build, minimizzando allo stesso tempo la compilazione dell'applicazione il più possibile?

    
posta Steven Evers 07.12.2012 - 21:28
fonte

2 risposte

1

Da un lato, FIX YOUR BUILDTIME !! Questo è combattere i sintomi, non il problema principale!

I tuoi test dovrebbero venire insieme al tuo codice, come nello stesso repository. Ogni volta che costruisci i test vengono costruiti anche. Quando esegui i test, è della stessa generazione del codice con cui viene eseguito.

Si controlla il codice da compilare, questa verifica include i test. Questi test vengono eseguiti.

Ancora una volta non sprecare tempo a cercare di costruire meno spesso. Se fa male lo fa più spesso! Rompere il monolite, ottenere un controllo sulle dipendenze. Usa il tuo sistema di build per aiutarti a non toccare / ricostruire roba invariata. Hai bisogno di modularizzare per questo. L'inversione delle dipendenze aiuta molto qui.

    
risposta data 08.12.2012 - 02:30
fonte
0

Repository di pacchetti come Artifactory e sistemi di gestione dei pacchetti come Ivy e NuGet sono buone risposte a questo tipo di problema. Costruisci i pacchetti che vuoi costruire, scarica il resto attraverso una cache locale del disco rigido delle versioni attuali, e sei a posto.

    
risposta data 12.12.2012 - 01:55
fonte