Unendo circa 15 piccoli repository Git di componenti di servizi Web centralizzati non opzionali a un unico repository di grandi dimensioni

Question

Unendo circa 15 piccoli repository Git di componenti di servizi Web centralizzati non opzionali a un unico repository di grandi dimensioni

#1 da (7 voti)

4

In un servizio web centralizzato suddividiamo i componenti in vari piccoli repository Git tramite moduli software, ad es. modulo di autenticazione, modulo di autorizzazione, modulo di accesso ai dati ecc. (circa 15 repository al momento)

La cosa buona è che è facile gestire la base di codice più piccola, tuttavia, la nostra produttività è diminuita di molto poiché molte modifiche devono essere aggiornate più repository contemporaneamente.

Inoltre, la distribuzione è più difficile in quanto sono coinvolte più versioni del modulo, dobbiamo sempre pensare alla dipendenza.

Sto considerando di unire tutti i moduli su un singolo repository, perché

i nostri servizi devono richiedere l'esistenza di tutti i moduli, non sono facoltativi per il nostro servizio
non siamo una grande squadra (3 persone in realtà) e il sovraccarico nel mantenere troppi repository non ne vale la pena, tutti hanno bisogno di avere conoscenze su tutte le basi di codice

Che ne pensi? Qualche pro e contro se ci fondiamo in un grande repo?

git design release-management modules gitflow

posta user34401 14.05.2014 - 18:45

fonte

1 risposta

Leggi altre domande sui tag git design release-management modules gitflow

Classi in OOP, metodi e attributi interni di memoria [chiuso] Aggiornamenti dell'app IOS che non richiedono l'invio all'App Store

score 7 · Answer 1

Questo dipende molto dai moduli. Stai dicendo che il servizio richiede che tutti i moduli esistano, ma i moduli richiedono che il servizio (o altri moduli) esista?

Se hai un modulo che è parte integrante del progetto, ma lo hai come modulo per motivi organizzativi (ad esempio - modelli , visualizzazioni e controller in architettura MVC), quindi è una buona idea averli nello stesso repository del progetto principale, perché è probabile che vengano aggiornati insieme.

D'altra parte, se hai un modulo che si comporta più come una libreria, e puoi facilmente lavorarci come un modulo standalone e usarne la funzionalità in altri progetti, è meglio tenerlo nel proprio repository.

Con 15 moduli è una scommessa sicura che hai entrambi i tipi. Non è necessario convertire tutto in un singolo repository. Forse il repository principale consisterà di 10 moduli, e un altro modulo avrà il proprio repository perché è una libreria standalone, e gli altri 4 moduli sono anche una libreria, ma devono essere insieme per avere un senso in modo da metterli tutti in un terzo repository. Naturalmente, la distribuzione non dovrebbe essere arbitraria - dovrebbe essere basata sull'accoppiamento logico tra i moduli (non l'accoppiamento corrente - quello che si pensa sia il progetto giusto) - ma in ogni caso probabilmente si otterrà un valore più basso, più quantità gestibile di moduli.

Inoltre, se hai problemi a tenere traccia di tutti i moduli, dovresti prendere in considerazione l'utilizzo di Git Submodules . I sottomoduli ti permettono di mantenere la versione corretta dei moduli che risiedono in altri repository, e puoi commettere e spingere direttamente dal sottomodulo ( fai attenzione con questo! ). Questo dovrebbe rendere più semplice il lavoro con molti moduli.