Evita o minimizza i conflitti di unione durante l'utilizzo di NuGet e GitFlow

1

Ecco il nostro problema: abbiamo diverse soluzioni con più progetti che utilizzano i nostri pacchetti di nuget. Stiamo seguendo GitFlow, ma non SemVer. Ogni volta che sviluppiamo funzionalità più grandi o epiche vogliamo mantenere il codice aggiornato con il nostro ramo di sviluppo (che può avere alcune altre funzionalità o correzioni di bug in tempo per lo sviluppo di un'epica citata), quindi vogliamo unirlo regolarmente. Il problema è che in ogni unione, se ci sono stati cambiamenti con i nostri pacchetti nuget, abbiamo decine di conflitti di unione in tutti i file packages.config nei nostri progetti. In questo modo, unire richiede troppo tempo, soprattutto perché dopo l'unione dobbiamo aggiornare manualmente le versioni di nuget e installarle nei nostri progetti. Quindi ogni volta che vogliamo unire qualcosa dobbiamo riprodurre questi passaggi:

  1. Unisci ramo
  2. Risolvi tutti i conflitti di versione
  3. Spingi pacchetti di nuget aggiornati
  4. Installa pacchetti nuget aggiornati

Ho svolto alcune ricerche, ma non sono ancora sicuro di quale sia la soluzione migliore per semplificare questo processo. Ok, possiamo usare PackageReference o Paket con versioni flottanti combinate con GitVersion, che automatizzerebbe i passaggi 3 e 4 per il nostro ramo di sviluppo, ma permangono problemi di fusione e conflitti, poiché il nostro ramo di sviluppo utilizza versioni di rilascio (XXX) e altri rami versioni prerelease (con tag -branchName). Quindi con ogni aggiornamento ci saranno ancora dei conflitti.

Quindi la mia domanda è: come affrontare al meglio quella situazione? C'è un modo per risolverlo usando i nugets o forse possiamo condividere il nostro codice in qualche altro modo? I progetti condivisi non risolveranno i nostri problemi, poiché le nostre librerie sono piuttosto grandi e non vogliamo includerle nelle nostre soluzioni.

    
posta JayL 26.06.2018 - 11:45
fonte

1 risposta

1

OK Ecco la mia ipotesi.

Hai una lib condivisa distribuita da nuget e consumata dalla tua applicazione.

Quando si ottiene una richiesta di funzionalità per l'applicazione, si crea un nuovo ramo di funzionalità sul repository, ma si scopre che richiederà modifiche alla lib condivisa

Si crea un ramo di funzionalità sul repository di libreria e si pubblica un nugger di pre-release

Consumerai il prerelease nuget sul tuo ramo delle applicazioni e continuerai a testare la funzionalità.

In un altro ramo della funzione Applicazione accade che la stessa cosa accada, quando finisci quella OtherFeature, aggiorni la libreria e il ramo dev, ma la tua caratteristica Origional è ancora sul suo nocciolo prerelease e ottieni conflitti.

La soluzione è aggiungere e testare funzionalità alla libreria indipendentemente dall'applicazione. Non pubblicare le funzioni della libreria non finite, finiscile e uniscile in master prima di pubblicarle.

Una volta che la libreria è stata aggiornata con la sua nuova funzionalità, è possibile aggiornare l'applicazione per utilizzare la versione più recente e procedere alla creazione di un ramo di funzionalità.

Ovviamente questo significa che devi elaborare le tue specifiche un po 'più rigorosamente.

In alternativa puoi provare a riempire la libreria localmente con la stessa versione e utilizzare una directory come sorgente di file, mentre fai il test in modo da non dover aggiornare la versione sull'app

    
risposta data 26.06.2018 - 14:13
fonte

Leggi altre domande sui tag