Flusso di lavoro della dipendenza della soluzione .NET per un piccolo team di sviluppo

Question

Flusso di lavoro della dipendenza della soluzione .NET per un piccolo team di sviluppo

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

1

Abbiamo un team di 5 sviluppatori che lavorano su un prodotto e sono a un bivio cercando di determinare un modo migliore (se esiste) di gestire il flusso di lavoro di sviluppo e le dipendenze del progetto. Al momento abbiamo due soluzioni, Core e Client . Il core fa riferimento a 8 progetti come dipendenze ( non via NuGet ). Core è essenzialmente un'API di amministrazione e API REST. Client, è un modello di progetto che verrà replicato ogni volta che abbiamo una nuova istanza che deve essere personalizzata. Client riferimenti 4 degli stessi progetti eseguiti da Core . Ancora una volta, entrambe sono soluzioni (.sln) ed entrambe fanno riferimento direttamente ai progetti di dipendenza.

Per lo sviluppo locale, gli sviluppatori si dividono attualmente da due repository separati, uno per ciascuna soluzione. L'ambiente locale degli sviluppatori deve essere impostato in modo che il Client possa correttamente chiamare l'API REST localmente. Lo sviluppo locale richiede spesso modifiche a Core e Client per testare nuove funzionalità, ecc.

Il nostro problema è che a volte le nostre modifiche non si basano sui sistemi di altri sviluppatori a causa delle diverse posizioni dei repository sul file system. Ciò causa problemi con il percorso verso i progetti nei file della soluzione e crea un sacco di inutili lavori e frustrazioni extra.

Stiamo prendendo in considerazione il passaggio a un flusso di lavoro NuGet (server NuGet locali, Test e Prod), ma sembra che ci sia un sovraccarico extra per il payoff. Qualcuno può consigliare una soluzione migliore per il flusso di lavoro di sviluppo locale, test, staging, prod per il nostro piccolo team?

workflows .net asp.net-mvc nuget

posta joeldow 26.05.2015 - 23:43

fonte

2 risposte

Leggi altre domande sui tag workflows .net asp.net-mvc nuget

Dipendenze dal middleware Quale sarebbe il modo migliore per implementare la programmazione basata su priorità senza aggiungere troppa logica di elaborazione if-else

score 1 · Answer 1

Un problema classico: la soluzione più semplice è fare ciò che fanno tutti, considerare il tuo prodotto Core come un prodotto separato, in modo simile a come tratteresti un progetto open source che stavi riutilizzando nel tuo prodotto.

Ad esempio, utilizzo log4net nel mio prodotto. Non ho una copia della loro fonte, prendo solo l'ultima DLL stabile e la uso direttamente, inserendola in una directory 'libs di terze parti' che conosco dove si trova. Puoi farlo con i progetti dei tuoi clienti che utilizzano le dll del tuo prodotto Core.

Se stai condividendo il codice sorgente tra questi progetti, allora sei in un mondo di fastidio, combinerei i repos insieme in questo caso, o inserirò il codice condiviso in un terzo repository usato da entrambi i tuoi progetti principali. Questo non è l'ideale ma può funzionare bene - Ho fatto cose del genere con progetti C / C ++ in passato in cui è stata usata una directory comune / include, creando il progetto dipendente che copia il sorgente in questa directory. Il sistema C # di Visual Studio non è così amichevole verso il codice sorgente che è esterno alla root del progetto, quindi non lo consiglierei a C # (il che è un peccato che C # sia così "blunt-scissors" in questo senso). / p>

score 0 · Answer 2

La posizione del repository sul file system non dovrebbe causare problemi con il percorso dei progetti nei file della soluzione. Quest'ultimo dovrebbe dipendere solo dalle posizioni delle copie di lavoro - forse l'hai confuso?

Tuttavia, se devo indovinare cosa sta realmente accadendo, la soluzione al tuo problema è probabilmente: ricolloca i tuoi progetti in modo che tutti i riferimenti siano percorsi relativi tra loro. Quindi non dovrebbe importare dove vengono estratti sul file system finché la loro posizione relativa è la stessa. Questo deve essere vero per la tua Core e la tua soluzione Client in combinazione. Se è necessario disporre di rami diversi in parallelo su una workstation locale, disporre di una "cartella radice" locale per ogni ramo, contenente sempre entrambe le soluzioni Core e Client di quel ramo.