Coping con i requisiti degli ordini di build nei build automatici

5

Ho tre pacchetti Scala in fase di costruzione come progetti sbt separati in repository separati con un grafico delle dipendenze come questo:

  M---->D
  ^     ^
  |     |
  +--+--+
     ^
     |
     S

S è un servizio. M è un insieme di classi di messaggi condivisi tra S e un altro servizio. D è un DAL utilizzato da S e l'altro servizio e alcuni dei suoi modelli vengono visualizzati nei messaggi condivisi.

Se faccio un cambio di rottura a tutti e tre, e li spingo al mio repo Git, una build di S sarà lanciata a Jenkins. La compilazione avrà successo solo se, quando S viene premuto, M e D sono già stati spinti. Altrimenti, Jenkins scoprirà che non sono disponibili le giuste versioni del pacchetto dipendente. Anche spingerli simultaneamente non basterebbe: le dipendenze dovrebbero essere costruite e pubblicate prima ancora che il lavoro dipendente sia iniziato. Rendere i lavori dipendenti da Jenkins non è sufficiente, perché ciò causerebbe solo la versione precedente da creare, risultando in un artefatto che non ha la versione necessaria.

C'è un modo per impostare le cose in modo che non debba ricordare di spingere le cose nell'ordine giusto?

L'unico modo in cui posso vederlo funzionare è se ci fosse un modo in cui una build poteva entrare in uno stato in sospeso se le sue dipendenze non erano ancora disponibili.

Mi sento come se ci fosse una soluzione semplice che mi manca. Sicuramente le persone si occupano molto di questo?

    
posta Dan Ellis 08.08.2014 - 11:00
fonte

1 risposta

1

Puoi anche dare un'occhiata a questo plugin Jenkins: link .

Consiglierei di riprogettare la tua app. Come approccio generale e buona pratica, raccomanderei il controllo della versione dei progetti / componenti. Ogni componente dipenderà da una versione specifica dell'altro componente. In questo modo hai il pieno controllo su quale dipendenza viene considerata per la build attuale.

    
risposta data 21.08.2014 - 12:50
fonte

Leggi altre domande sui tag