Dipendenze client / server con integrazione continua

1

Sto iniziando a utilizzare l'integrazione continua per uno dei miei progetti e ho alcune domande su struttura e architettura.

È fondamentalmente un servizio web multi-dispositivo che è suddiviso in un repository di server e più repository di client specifici per dispositivo.

La mia domanda è la seguente:

  • Poiché i client dipendono dal server per eseguire i test, ha senso dividerli in un altro repository?

Ho fatto alcune build con Travis CI come esempi e ha funzionato benissimo ma ora che voglio aggiungere test, si pone il problema di dipendere dal progetto del server.

Server che ha anch'esso una propria build e test.

Da un lato dell'architettura del progetto ha senso dividere i repository di server e client, ma ho problemi a guardare l'immagine grande e l'integrazione del server CI.

    
posta m_vdbeek 31.08.2014 - 22:21
fonte

2 risposte

0

TL; DR: dipende, ma non a causa dell'integrazione continua. Puoi eseguire la versione di tutto ciò che semplificherà la gestione delle dipendenze, oppure puoi dividere il codice e rendere esplicita la gestione delle dipendenze tra le diverse basi di codice.

Questa non è una domanda sull'integrazione continua. La preoccupazione principale quando si dividono le basi di codice è se si desidera eseguire la versione e gestire separatamente diverse parti della base di codici. Ad esempio se il codice del server non cambiava spesso, ma il codice client allora avrebbe avuto senso dividere il repository. Non vorresti fare un deploy e rilasciare un server quando l'unica cosa che cambia è il codice client.

Aggiorna

Una volta che il codice è stato diviso, è necessario assicurarsi di aver acquisito la dipendenza esplicita e rappresentata in modo appropriato. Ad esempio se stavi creando RPM, allora ciascun pacchetto dovrebbe dipendere sia dal pacchetto che dalla versione che il sistema di compilazione sta validando.

Decidere quando aggiornare le dipendenze nel sistema di generazione può essere un caso di aggiornamento di tutti i dipendenti a:

  • l'ultimo commit
  • l'ultima build di successo
  • l'ultima versione candidata
  • etc

Questo può essere spesso gestito dal sistema di build, o da alcuni script di shell che vengono attivati come operazioni di pre / post build con ogni build.

    
risposta data 31.08.2014 - 23:20
fonte
1

I server CI sono solo coordinatori, pianificano ed eseguono build, pianificano ed eseguono test e alcuni pianificano ed eseguono le distribuzioni. È il secondo a cui ti stai preoccupando e che è in definitiva un compito per qualsiasi strumento tu usi per distribuire il tuo progetto di build su qualsiasi hardware o VM verrà utilizzato per testare.

Ho un progetto che consiste in un client e un server, ogni volta che pianifico una build importante che verrà rilasciata per testare, costruisce tutto indipendentemente dal fatto che debba essere ricostruita o meno. quindi viene implementato il codice garantito ricostruito con l'ultima versione e timbrato con l'ultimo numero di versione.

    
risposta data 31.08.2014 - 22:25
fonte