Implementazione dell'integrazione continua con una gerarchia volatile delle dipendenze della libreria

Question

Implementazione dell'integrazione continua con una gerarchia volatile delle dipendenze della libreria

#1 da (2 voti)
#2 da (1 voti)

1

Recentemente la mia azienda ha configurato un server di build utilizzando Bamboo e un feed Nuget privato che è popolato dalle build riuscite distribuite dal build server.

Esiste una gerarchia di progetti in una configurazione di sviluppo pesante per l'uso in bambù con un grafico di dipendenza lineare piuttosto semplice. Prima di essere installati su bamboo, tutti gli sviluppatori dovevano clonare il repository su cui si stava lavorando e tutte le sue dipendenze e creare un nuovo ramo in ogni progetto. Poiché quasi tutti i cambiamenti a questo punto stanno rompendo i cambiamenti, questo è stato un po 'di mal di testa.

Quindi ora con il nuovo strumento di Bamboo nel mix, come sviluppatore, come sarebbe il mio flusso di lavoro se avessi bisogno di apportare alcune modifiche nel Progetto A che richieda anche cambiamenti nel Progetto C dove Progetto B e C sono dipendenti su A e C dipende anche da B.

  A
 | |
 | B
 | |
  C

Voglio essere certo che tutti i test passino ancora nel Progetto B dopo le modifiche al progetto A prima di passare alle modifiche nel Progetto C. Esistono risorse che aiutano a spiegare quale flusso di lavoro degli sviluppatori dovrebbe essere a questo punto? Sembra che sia in grado di tirare giù, configurare manualmente le dipendenze e testare B. Oppure può configurare build speciali su Bamboo per gestire lo stato intermedio dei progetti e quindi scaricare i pacchetti nuget risultanti. Mi sento a disagio con questa soluzione perché richiede una comprensione più profonda da parte degli sviluppatori di Bamboo e del server di build (e non riesco a capire tutto a questo punto, per spiegargli tutto).

Questo problema aggrava le maggiori dipendenze che ci sono in una libreria di livello inferiore. Ci sono risorse che spiegano l'approccio accettato a questo problema?

continuous-integration .net nuget bamboo

posta jth41 14.01.2015 - 22:08

fonte

2 risposte

Leggi altre domande sui tag continuous-integration .net nuget bamboo

Il miglior approccio per sviluppare / distribuire il modulo proprietario Differenza tra lavori e lavoratori del server?

score 2 · Answer 1

Quando lavori con più team su più progetti, hai sempre avuto e avresti la maggior parte (se non tutti) dei tuoi problemi relativi all'interfacciamento tra questi progetti. Puoi chiamarlo progetto / libreria / microservizio / ecc. - è sempre lo stesso che descrivi. Una squadra subisce modifiche di rottura, l'altra squadra (s) soffre.

Poiché questo problema è abbastanza noto, esiste un percorso accettabile semplice. Almeno è tecnicamente semplice, ma può comunque coinvolgere la politica dell'ufficio. L'idea di base è che hai chiaramente definito le interfacce pubbliche e che una squadra non deve fare cambiamenti di rottura in tale ambiente. Invece, al tuo team è permesso solo di rompere le cose tramite un meccanismo standard di deprecazione.

In pratica, ciò significa che l'interfaccia esterna di A deve rimanere la stessa. Questo è più un problema per la squadra A in qualche modo realizzare il proprio cambiamento in un modo che lascia la vecchia interfaccia A disponibile e funzionante come una volta. In sostanza, questo è il prezzo che l'azienda deve pagare per assicurare il buon funzionamento di tutte le altre squadre in presenza delle modifiche di A. A, tuttavia, ha il diritto di deprecare / versionare la sua interfaccia in modo tale che tutti gli altri team siano informati che una certa funzionalità verrà eliminata all'interno di X (questo dovrebbe essere un periodo di tempo noto in tutta la società. Possono essere giorni, settimane o anche mesi - dipende dall'agilità delle tue squadre).

Dopo che questo periodo è trascorso, tutti gli altri team hanno avuto il tempo di sostituire le chiamate di interfaccia obsolete e il team A può semplicemente rimuovere la parte deprecata dell'interfaccia. Tutto ciò che si rompe al di fuori di A a quel punto non è più considerato il problema della squadra A.

Una buona pratica per lavorare in un tale ambiente è anche per ogni dipendenza che il tuo progetto deve configurare una serie di test, il che garantisce che a) tu capisca correttamente come dovrebbe funzionare quell'interfaccia e b) immediatamente fallisci caso hai perso la scadenza della deprecazione e l'interfaccia è sparita (come al solito: fallire è meglio).

score 1 · Answer 2

Usa un'architettura a strati. Colloca ciascun progetto in un livello, in cui ogni progetto dipende solo da progetti di livello inferiore, quindi nessun progetto di livello inferiore dipende da un progetto di livello superiore. Senza livelli, le dipendenze diventano ingestibili in quanto il numero di progetti si moltiplica.

Una volta che la tua architettura è a strati, test prima i livelli più bassi, poi il livello sopra, ecc. Questo disegno si è dimostrato utile per decenni.