Un progetto per soluzione per creare pacchetti di nuget

1

Ho una soluzione con 10 progetti, ho usato per distribuirlo come un SDK con un programma di installazione nel corso della giornata.

Per cambiare quella in VSTS ho aggiunto i passaggi per creare un pacchetto per progetto, ogni volta che apporto una modifica, viene attivata una build e uno script PS cambia la versione dei file nuspec, alla fine i pacchetti vengono spinti a un feed, se ho apportato una modifica a un solo progetto, la build spinge una nuova versione di ogni pacchetto anche se non ci sono modifiche in tutti.

Qualcuno mi ha detto che era sbagliato, non avrei dovuto spingere una nuova versione se non ci fossero cambiamenti nel pacchetto e ogni pacchetto dovesse essere creato separatamente.

Questo ha senso, ma nel mio caso, devo creare 9 ulteriori build in VSTS, sostituire i riferimenti di progetto per le dipendenze di nuget e, se dovessi mai cambiare due progetti, dovrei modificarne uno, commettere il cambiamento, quindi apri il secondo progetto, aggiorna il riferimento a nuget e apporta la modifica, che sembra un lavoro extra.

Quindi la mia domanda è: esiste una best practice o una raccomandazione sul flusso nella creazione di un gruppo di pacchetti di nuget?

    
posta Juan Zamudio 04.09.2017 - 18:25
fonte

1 risposta

1

Non sono un esperto di NuGet o VSTS, quindi posso solo offrire un consiglio generale.

Come schema generale, non solo NuGet, per i progetti interconnessi il modello è costituito da:

  • strutturare il progetto in modo che il codice comune sia chiaramente separato dal codice dell'applicazione o del progetto.
  • Riduzione al minimo o eliminazione di tutte le interdipendenze tra i progetti - idealmente tutti i progetti dovrebbero essere autonomi ed esternamente dipendenti solo dal codice comune.
  • Buoni strumenti di compilazione che ricostruiscono solo i progetti che sono interessati e possono automatizzare la distribuzione delle build risultanti.
  • Un'API chiara e stabile per tutte le comunicazioni tra progetti (che include strutture di file e qualsiasi altra cosa che viene scambiata tra progetti).
  • Includere il controllo delle versioni in qualsiasi scambio e tentare di mantenere la compatibilità all'indietro laddove possibile, così se i progetti escono dal passo o continuano a funzionare o danno un errore chiaro e utile.
  • Utilizzo di versioning semantico o maschere di compatibilità da segnalare quando è più probabile che sia necessario eseguire gli aggiornamenti più ampiamente.
  • Un sacco di test, preferibilmente test automatici, quindi quando stai pensando di spingere una nuova versione di un pacchetto tutti gli altri pacchetti sono testati per vedere se sono ancora compatibili con quella versione rivista e se le modifiche incidono su altri progetti segnalati che devono essere aggiornati contemporaneamente.

Una regola generale è che se la tua modifica non ha alcun impatto su qualcosa che potrebbe essere consumata da uno dei tuoi altri progetti, è improbabile che richieda modifiche agli altri progetti.

Puoi anche guardare:

  • Aggiornamento automatico delle versioni interconnesse dei pacchetti
  • I riferimenti aggiornati sono prevedibili.
  • Utilizzo di un sistema di gestione del progetto o meno MS più sano di VSTS che gestisce meglio i progetti interconnessi.
risposta data 05.09.2017 - 09:01
fonte

Leggi altre domande sui tag