Come dividere un monorepo su più team in modo che ciascuno abbia accesso solo a una porzione del repository?

Question

Come dividere un monorepo su più team in modo che ciascuno abbia accesso solo a una porzione del repository?

#1 da (6 voti)
#2 da (2 voti)

2

Ci sono molti vantaggi per un monorepo. Leggiamo anche che grandi aziende come Google e Facebook usano questa tecnologia per mantenere tutto il codice sorgente in un unico repo.

Ma come si fa a limitare l'accesso di un certo team ai progetti su cui stanno lavorando quando si usa un monorepo?

Ad esempio, abbiamo un'infrastruttura di microservizi:

Servizio A
Servizio B
Gateway API

Il servizio A è sviluppato usando il Team A, e il servizio B è sviluppato dal Team B, mentre Api Gateway è il repository comune in questo progetto.

Come possiamo limitare l'accesso di ogni squadra solo al proprio servizio?

Attualmente manteniamo ogni parte nel proprio repository e in questo modo possiamo controllare l'accesso per ogni team. Ma mi è stato chiesto di migrare questo a monorepo, e non sono sicuro di come proteggere il codice sorgente e dividere il progetto con un simile approccio.

git project-management microservices gitlab

posta Zalaboza 29.06.2018 - 03:44

fonte

2 risposte

Leggi altre domande sui tag git project-management microservices gitlab

Documentazione tecnica e documentazione di progettazione del software C ++ 0x è compatibile con C?

score 6 · Answer 1

Non vuoi.

L'intero punto di un monorepo è che ogni sviluppatore può toccare tutto il codice. In questo modo, tutti i progetti, i sottoprogetti e le librerie possono essere mantenuti "sincronizzati" su tutto il codice base, in modo da non entrare nella "dipendenza dalla versione infernale", ecc.

Esempio:

Team Service-B deve effettuare alcune ristrutturazioni su una libreria comune nel monorepo, che interromperà il codice in API-Gateway e Service-B.

Il team B eseguirà l'intero processo di ristrutturazione, inclusa la correzione del codice di A e API e l'esecuzione di tutte suite di test. (La squadra B probabilmente probabilmente controllerà prima con gli altri team, potrebbe ottenere il supporto dagli altri, se le cose si fanno difficili, ovviamente.)

Una volta che tutte le suite di test sono state eseguite e tutto è verde, la squadra B controlla il nuovo stato, unico e solo, del monorepo.

_{Disclaimer: Abbiamo un monorepo di sorta. Mentre continua a crescere, non sono convinto che sia tutto il percorso felice che alcune persone sembrano pensare. Soprattutto senza utensili pesanti e buone suite di test, diventa fragile rapidamente, IMHO.}

Titus Winters di Google fornisce alcune spiegazioni in CppCon 2017: Titus Winters "C ++ come linguaggio" Live at Head "" . (Almeno penso che fosse questo video in cui spiega l'approccio monorepo.)

score 2 · Answer 2

Considererei un sistema che richiede recensioni da parte di persone specifiche in base ai file modificati.

Ad esempio, il codice che tocca /service-a richiede una revisione da parte di un membro del team che è il principale responsabile di tale servizio. In questo modo, gli ingegneri esterni al team del servizio A sono ancora abilitati a interagire con il codice sorgente del servizio A, ma non possono unirsi senza l'approvazione di quel team.