I miei colleghi e io stiamo ristrutturando il nostro sistema. Il vecchio sistema è un monolite ASP.NET che utilizza TFS per il controllo del codice sorgente. Il nuovo sistema è costituito da microservizi di ASP.NET Core che utilizzano GitHub per il controllo del codice sorgente e un repository NuGet privato in Artifactory.
Per prima cosa, abbiamo messo tutti i nostri progetti in un unico repository GitHub per semplicità. Possiamo facilmente apportare modifiche che tagliano più librerie, ma il lato negativo è che la modifica di un pacchetto fa rivedere il numero di versione per tutti loro. Inoltre, il repository ha il potenziale per diventare un casino di filiali, commit e PR una volta che tutti i nostri sviluppatori ci lavorano.
Il mio prossimo pensiero è stato la divisione di ogni pacchetto NuGet nel proprio repository GitHub. Questo risolve il problema della versione e consente agli sviluppatori di ignorare l'attività nei repository che non sono rilevanti per loro, ma rende la modifica di più pacchetti contemporaneamente un grosso problema. Se devo implementare una funzionalità che comporta modifiche ai pacchetti A e B in cui A dipende da B e sono in repository separati, devo apportare le modifiche a B in isolamento, creare un PR, ottenere l'approvazione PR, attendere il nuovo pacchetto da mostrare in Artifactory, aggiornare il riferimento del pacchetto nel progetto A, quindi apportare le mie modifiche ad A e sperare che non ci siano errori in B. Yuck!
Ho provato a utilizzare i sottomoduli Git, quindi ho potuto aggiungere un riferimento al progetto alle dipendenze del progetto corrente, ma alla fine non ne valeva la pena una volta che l'albero delle dipendenze avesse ottenuto più di uno o due livelli di profondità.
Quello che sto cercando sono alcuni consigli su altre strategie da provare. Oppure la strategia one-repo-per-package è il modo migliore per andare nonostante sia noioso?