Ambiente di sviluppo del team per .Net

5

Ho appena aderito a una nuova società che ha recentemente cambiato lo sviluppo da PHP a C # /. Net Core. Stanno scrivendo un nuovo CMS da zero in questo nuovo ambiente.

Prima di me, c'era un solo sviluppatore che lavorava su questo nuovo sistema e ha creato un sistema con cui è piuttosto difficile lavorare. Sto cercando di pensare a come migliorarlo, ma ho difficoltà a trovare informazioni sulle funzionalità dei vari strumenti coinvolti.

Avviso: descrizione lunga / rant in arrivo. TL / DR: il sistema attuale rende lo sviluppo quotidiano molto inefficiente. Se vuoi, puoi saltare alle domande concrete di seguito.

La nostra configurazione attuale funziona in questo modo: il sistema è suddiviso in parti principali e parti specifiche del cliente. Ogni parte è ulteriormente suddivisa in una serie di piccoli progetti secondo divisioni logiche di responsabilità. Fin qui tutto bene.

Ciascuno di questi progetti si trova nel proprio repository Git individuale e consiste in un'unica soluzione che di solito contiene due progetti, una libreria di classi contenente la funzionalità e un progetto di test unitario. (Occasionalmente c'è più di una coppia di questi, ma io considero un incidente.)

I repository Git sono ospitati su un TFS. Il TFS crea automaticamente ciascuna soluzione man mano che i commit vengono inviati e pubblica il risultato della compilazione come pacchetto NuGet. La dipendenza tra i vari progetti è gestita esclusivamente dalle dipendenze di NuGet.

C'è un numero di problemi con questo.

Quando ho bisogno di una nuova funzionalità, le modifiche necessarie sono spesso suddivise in un numero di progetti. Poiché il CMS è molto giovane, molte nuove funzionalità richiedono aggiunte al nucleo; inoltre, una nuova funzionalità potrebbe richiedere cambiamenti in più progetti delle parti specifiche del cliente: il livello del controller della vista (un progetto), il livello dei sistemi (un altro progetto) e alcuni livelli di dati (ancora un altro progetto).

A causa del modo in cui funzionano le dipendenze, per ottenere questo ho bisogno di cambiare il progetto alla fine del grafico delle dipendenze, commit e push, attendere che il server pubblichi il nuovo pacchetto, aggiorni il livello successivo, apporti le modifiche lì, commetti e spingi, ecc., finché non raggiungo il livello finale. In qualsiasi momento di questo processo, la costruzione del mondo potrebbe essere interrotta se avessi cambiato qualcosa in modo incompatibile.

Come puoi immaginare, questo è un processo incredibilmente inefficiente. Inoltre, se in qualsiasi momento mi rendo conto che un cambiamento nello strato inferiore era errato o insufficiente, devo ricominciare il processo. Ciò significa che posso facilmente accumulare Git commit che in realtà non sono uno stato utile del sistema. Ciò che è ancora peggio, se voglio provare qualcosa in un livello inferiore (ad esempio aggiungo un output di debug), in realtà devo commetterlo e spingerlo nel repository ufficiale per ottenere una build, quindi aggiungere un altro commit che annulla l'effetto .

Inoltre, poiché ogni piccolo progetto è nella sua soluzione, devo aprirlo ciascuno nella propria istanza di Visual Studio. Al momento ho 6 istanze in esecuzione. Trovare quello giusto per un lavoro a volte è fonte di confusione. Inoltre, a causa del modo in cui funziona la configurazione VS, qualsiasi modifica apportata (ad esempio, layout di finestre degli strumenti) rischia di essere sovrascritta se l'istanza in cui l'ho creata non è l'ultima arrestata.

Infine, poiché i pacchetti NuGet che vengono creati sono versioni di rilascio, il debug attraverso lo stack non è ottimale. (Inoltre, al momento non abbiamo informazioni sui simboli o fonti nei pacchetti, quindi il debug è completamente impossibile, ma so come risolvere questo particolare problema.)

Domande

  1. C'è un modo per avere sia l'installazione della dipendenza di NuGet per i build CI, sia una configurazione di dipendenza del progetto a soluzione singola per le build dello sviluppatore?

  2. L'utilizzo di NuGet è anche utile? Esiste un modo migliore per comporre progetti che si estendano su un certo numero di repository Git?

  3. C'è un modo per avere un repository NuGet locale per lo sviluppatore che sovrascriva il server in modo prevedibile, dove i build vengono automaticamente inseriti con un buon numero di versione? Sono piuttosto preoccupato per i problemi di sincronizzazione quando due sviluppatori lavorano contemporaneamente allo stesso repository.

  4. Sarebbe un grande vantaggio fondersi in un solo repository Git per il core e uno per elementi specifici del cliente?

O per dirla in altro modo, che cos'è un buon setup di sviluppo in generale? Sfortunatamente questa è la prima volta che lavoro con lo sviluppo .Net, quindi mi manca l'esperienza in generale.

    
posta Sebastian Redl 27.01.2017 - 13:00
fonte

2 risposte

2

Mi sembra che questo sia stato configurato molto bene.

Ci sono un paio di cose che puoi fare per rendere la tua vita quotidiana più facile.

Problema 1: pubblicare i nugets prima che possano essere utilizzati nei progetti dipendenti

Puoi pubblicare manualmente un nugget pre-release da una build locale aggiungendo -beta al numero di versione. I progetti dipendenti possono quindi essere aggiornati per utilizzare questa versione preliminare e testati, prima di eseguire il commit di una versione "reale"

In alternativa: impacchetta il tuo test nuget sul tuo computer e copia in una directory. imposta questa directory come un repository di nuget locale in VS

In alternativa: puoi cambiare il riferimento nel progetto alla DLL che hai localmente

Problema 2: debugging nugets compilati.

Idealmente qui non dovresti mai farlo. Scrivi test unitari nel progetto nuget per assicurarti che funzioni correttamente

Tuttavia, puoi compilare una versione di debug e usarla come pre-release o inserirla nel repository di nuget locale

    
risposta data 27.01.2017 - 13:44
fonte
0
  1. Se capisco che cosa stai cercando correttamente, c'è uno strumento chiamato SlimJim che aiuta a gestirlo modificando la soluzione con tutti i pacchetti costitutivi sono stati sostituiti con i riferimenti di progetto.
  2. Significa che è possibile avere parti specifiche del cliente diverse a seconda delle diverse versioni del core. Se non lo vuoi, probabilmente non ti sta aiutando. Potresti provare sottomoduli o sottostrutture, ma non credo che sarebbero utili in questo caso.
  3. Non dovresti pubblicare sul feed centrale dallo spazio di lavoro locale. È possibile ospitare una fonte di pacchetto da una directory locale. Le specifiche variano a seconda della versione di Visual Studio con cui stai lavorando ma questo articolo dovrebbe iniziare.
  4. Ci potrebbe essere, sembra che tu stia usando la struttura del progetto di un'applicazione molto più grande per la tua applicazione abbastanza nuova e attualmente piccola e sta causando un sovraccarico in eccesso.
risposta data 27.01.2017 - 13:56
fonte