Lavorare con esperti e più repository git

3

Recentemente abbiamo migrato da SVN, con la maggior parte del codice in un unico repository, per git, con la maggior parte dei progetti nei propri repository (circa 70 di essi). Costruiamo una dozzina di app diverse da questa fonte java. Le app vengono eseguite su server * nix. Usiamo maven e nexus per costruire. Molti di noi stanno lottando con lo sviluppo di funzionalità quando quella funzione tocca più di un repository. Ecco alcune delle sfide:

  • Lo sviluppatore deve suddividere separatamente ciascun repository - per una funzione è necessario utilizzare lo stesso nome per tutti i rami per rendere meno difficile il tracciamento.

  • Si devono aggiornare i poms di tutti i repository per puntare alle versioni aggiornate degli artefatti di ciascun repository. Se più persone stanno lavorando sullo stesso ramo, ci possono essere molte fusioni di altri pom. Quando apporto una modifica a un repository, l'artefatto viene rinominato in "-SNAPSHOT" che significa più aggiornamenti pom.

  • Le modifiche devono essere inserite nell'ordine corretto oppure i nostri build automatici falliranno, ad esempio: il repo A dipende da una modifica al repository B; se il repo A viene premuto prima che il repository B sia compilato e distribuito, allora il repository A non verrà compilato.

  • La persona che esamina la funzione deve esaminare le modifiche in più repository.

  • Quando la funzione viene unita dal suo ramo a, per esempio, master, Si deve ricordare tutti i reposli che sono stati toccati.

Sembra che il passaggio a un approccio per lo più monorepo potrebbe essere il migliore, quindi ci sono alcuni inconvenienti lì:

  • Costruire l'intero codebase con Maven richiede un tempo molto lungo. (Perché non puoi essere più simile a make, solo costruire cose che sono cambiate o le cui dipendenze sono cambiate?)

  • Ogni spinta dà il via a una grande serie di build e molti test unitari piuttosto che a una build e test di un articolo di un repository.

  • Gli sviluppatori che generalmente lavorano in uno o due repository preferiscono questo nuovo mondo multi-repo e resisteranno a un cambiamento.

Ho esaminato git submodules e sub trees, che non sembrano per risolvere molti dei nostri problemi (non sono sicuro di Google Repo). Alcuni di noi usano strumenti come "mu" per aiutare. Sarebbe bello se esistesse un toolkit che aiuterebbe gli sviluppatori a mantenere versioni in poms e tenere traccia delle modifiche tra i repository.

Fammi sapere se hai un set di procedure o strumenti che usi per facilitare lo sviluppo in questo tipo di ambiente.

    
posta Scott Sancetta 10.10.2018 - 22:12
fonte

1 risposta

3

Potrebbe non essere una risposta diretta, ma ho la sensazione che questi siano più i sintomi che la "malattia".

Se posso, penso che il problema principale sia che una funzionalità implica il contatto con tanti progetti diversi. So che non viviamo in un mondo ideale, ma forse mettere da parte i dettagli tecnici e aumentare "l'accoppiamento basso / alta coesione" dei tuoi diversi progetti potrebbe essere un obiettivo interessante.

Se diversi progetti sono così strettamente accoppiati da essere sempre toccati insieme, metterli insieme in un repository comune. Se una grossa porzione di codice può essere estratta come libreria relativamente indipendente, fallo.

Forse l'approccio più pragmatico non è né "ogni piccolo progetto in un repository" né "un gigantesco monorepo con tutto" ma qualcosa in mezzo tra progetti strettamente correlati raggruppati in un repository, mentre quelli relativamente indipendenti rimangono nei loro repository .

    
risposta data 11.10.2018 - 17:52
fonte

Leggi altre domande sui tag