Håndtering af store teams og repositories

Når udviklingsteams vokser, bliver det mere komplekst at administrere Git effektivt. Det, der fungerer for et lille team på 2-3 personer, kan føre til kaos med mere end 50 udviklere.

I denne lektion undersøger vi strategier til at koordinere udvikling på tværs af store teams og administrere flere indbyrdes forbundne repositories effektivt, samtidig med at vi sikrer et problemfrit samarbejde og god kodekvalitet.

Store organisationer står ofte over for et valg: De kan bruge ét stort monorepo eller flere mindre polyrepos (mange repositories). Hver tilgang har sine fordele og udfordringer.

• Polyrepo: Hver komponent eller tjeneste har sit eget Git-repository. Det kan give et tydeligt ejerskab og uafhængig udrulning.
• Monorepo: Al kode ligger i ét Git-repository. Det gør det nemmere at dele kode og foretage atomare ændringer på tværs af projekter.

I denne lektion fokuserer vi på strategier, der gælder for begge tilgange, især koordinering i et miljø med flere repositories, hvor eksplicit afhængighedsstyring er afgørende.

I en polyrepo-opsætning afhænger projekter ofte af kode fra andre repositories. Det kan være vanskeligt at administrere disse afhængigheder på tværs af repositories. Det er vigtigt at have tydelige processer for versionsstyring og opdateringer.

• Ensartet versionsstyring: Brug semantisk versionsstyring (f.eks. v1.2.3) til delte biblioteker.
• Pakkehåndteringsværktøjer: Brug sprogspecifikke pakkehåndteringsværktøjer (f.eks. npm, Maven, pip) til at angive og løse afhængigheder.
• Dokumentation: Dokumenter tydeligt, hvilken version af en afhængighed der er kompatibel med dit projekt.

For store teams er en ensartet Git-arbejdsgang ikke til forhandling. Den minimerer forvirring, reducerer konflikter og effektiviserer udviklingen. Det betyder, at I skal blive enige om:

• Branchingstrategi: En tydelig model som en forenklet variant af Git Flow eller GitHub Flow.
• Navngivningskonventioner: For grene (feature/add-auth), commit-meddelelser og tags.
• Mergepolitikker: F.eks. altid at bruge pull requests, kræve N godkendelser og forbyde direkte push til main.

Tydelige konventioner for navngivning af grene hjælper alle med hurtigt at forstå en grens formål. Her er nogle almindelige mønstre:

• feature/new-dashboard-ui
• bugfix/login-issue-42
• hotfix/critical-api-bug
• release/v1.2.0

Denne struktur fortæller dig straks, om det handler om en ny feature, en fejlrettelse eller forberedelse af en udgivelse.

Efterhånden som teams vokser, er det svært for alle at være eksperter i alle kodebaser. Ved at implementere kodeejerskab tildeler man bestemte teams eller personer ansvaret for specifikke dele af koden.

• Tydeligt ejerskab: Gør det nemmere at finde ud af, hvem man skal kontakte om ændringer eller problemer.
• Obligatoriske gennemgange: Kræver code reviews af alle ændringer, ofte ved hjælp af værktøjer, der håndhæver bestemte reviewere for forskellige kodeforløb.
• Automatiske kontroller: Brug linters, formatteringsværktøjer og tests i CI/CD til at opdage problemer tidligt og dermed mindske belastningen ved code reviews.

Kommunikation er grundlaget for samarbejde i store teams. Uden den kan udviklere arbejde på funktioner, der konflikter med hinanden, eller ubevidst introducere ændringer, der bryder eksisterende funktionalitet.

• Dedikerede kanaler: Brug chatværktøjer (Slack, Teams) til tekniske diskussioner, meddelelser og hurtige spørgsmål.
• Regelmæssige synkroniseringer: Hold teammøder, stand-ups eller arkitekturgennemgange for at koordinere større ændringer.
• Versionsnoter: Kommunikér tydeligt om nye funktioner, fejlrettelser og ændringer, der bryder eksisterende funktionalitet, for hver udgivelse.

Det er afgørende at beskytte kritiske grene (som main eller develop) mod uautoriserede eller ikke-gennemgåede ændringer. Git-hostingplatforme tilbyder omfattende funktioner til adgangskontrol:

• Regler for grenbeskyttelse: Kræv pull requests, flere godkendelser og beståede statuskontroller, og forhindre force pushes til vigtige grene.
• Rollebaseret adgang: Tildel brugere eller teams forskellige tilladelsesniveauer (f.eks. læse-, skrive- eller administratoradgang) til bestemte repositories.
• Revisionslogs: Registrér, hvem der foretog hvilke ændringer og hvornår, af hensyn til ansvarlighed og sikkerhed.

Konflikter er uundgåelige i store teams, men disse strategier kan mindske deres hyppighed og kompleksitet:

• Små, hyppige commits: Tilskynd udviklere til ofte at committe og pushe små, isolerede ændringer.
• Hyppige merges og rebases: Integrér regelmæssigt ændringer fra hovedgrenen i funktionsgrene for at undgå, at de udvikler sig i forskellige retninger.
• Tydelig kommunikation: Giv besked, når du arbejder i områder af kodebasen, som mange ændrer i.

Når der alligevel opstår konflikter, kan du bruge grafiske mergeværktøjer (som det indbyggede værktøj i VS Code eller Beyond Compare) til at løse dem effektivt.

Håndtering af Git for store teams og flere repositories kræver omhyggelig planlægning og konsekvent udførelse. Vi har gennemgået disse centrale strategier:

• Valg af passende repository-strukturer.
• Håndtering af afhængigheder på tværs af repositories.
• Standardisering af arbejdsgange og konventioner.
• Implementering af kodeejerskab og robuste reviewprocesser.
• Fremme af effektiv kommunikation.
• Anvendelse af adgangskontrol og tilladelser.
• Proaktiv minimering og løsning af konflikter.

Ved at anvende disse metoder kan store teams opretholde høj kodekvalitet og samarbejde effektivt.