( _Franko_ | 2020. 07. 07., k – 10:06 )

A francokat workaround. Az a normális, hogy a közös kód saját repoban van (egyszer)

Oké, nézzünk egy életszerű példát, némi absztakcióval.

Team A1, A2, A3: három projekt, három mobilalkalmazással, a cég három fő profilját lefedve, hívja a cég publikus backend szolgáltatásait. Vannak közös részek kiemelve közös library-ba.

Team B1, B2: négy projekt, négy mobilalkalmazással, a cég három fő profilját lefedve, plusz egy privát szolgáltatást, hívja a cég publikus és privát backend szolgáltatásait. Vannak közös részek kiemelve közös library-ba.

Team C1, C2, C3, C4: nyolc Windows vastagkliens, a cég három fő profilját lefedve, plusz a belső folyamatok támogatására megírva, hívja a cég publikus és privát backend szolgáltatásait, plusz közvetlen adatbázist. Vannak közös részek kiemelve közös library-ba.

Team D1, D2, D3: a cég három fő profiljának a backend szolgáltatásit fejlesztik, kettő ebből microservice architektúra (együtt ~100 microservice, ~30 közös, ~25 publikus API-t biztosít), egy pedig monolitikus. Vannak közös részek kiemelve közös library-ba. Vannak közös microservice-ek. Vannak közös adatbázissémák.

Team E: asset library kezelése.

Team F: "titkos" új projekt.

Team A1, A2 és B1 közös asset készletet használ, Team A3 és B2 szintén. Team C1, C2, C3, C4 saját asset repository-t használ. Team E írhassa mindenkinek az asset library repóját. Team F láthasson mindent.

--

Hogyan építenéd fel a source repository-t, hogy mindenki csak ahhoz a forráshoz férhessen hozzá, amit _láthat_ és azt a forrást módosíthassa, amihez joga van (közös library, asset, microservice forrás). Ha több repository van, tudjon a megoldás összevont pull request támogatást. Várom a javaslatod.