Innhold
1 Repo
- Forslaget er å bruke Stash. Vart einstemmig vedtatt av Cerebrum-utviklarar og driftarar 20. november. Det er enklare å eventuelt migrere til ein annan git-service seinare når vi først er over på Git.
- Andre alternativ var gerrit og github.
2 Arbeidsflyt
- Vi starter med å bruke github flow.
- Vi har ein hovudbranch: master. Denne skal berre inneholde godkjende innsjekkingar.
- Alt anna av kode skal ligge i eigne feature-branches. Dette inkluderer både bugfix og større prosjekt.
- Vi velger å ikkje ha fleire branchar for til dømes produksjonsklar kode. Alt i master skal allereie vere klart for produksjon. Vi må eventuelt opprette ein ny branch for dette seinare, om vi finn ut at det er eit behov.
- Ingen skal merge inn til master, sjølv om du har skrivetilgang. Alt skal gjennom code review med pull requests. Unntaket er kritiske bugfiksar som virkelig haster.
- Code review settast no til å måtte godkjennast av 1 annan utviklar.
- Rebase eller merge: Opp til utviklarane, alt etter kor komplisert innsjekkinga er.
- Andre kan komme med kodeendringar, ved å enten legge det inn som pull requests, eller ved å bruke git sine eigne metodar, til dømes over e-post. Vi må lage ein beskrivelse av korleis vi ønsker at folk skal gjere dette, men det kan gjerast seinare.
- Utviklarane må lage retningslinjer og kodestandard som må følgast av alle, og brukast når ein køyrer code review. Drift treng ikkje vere med på dette, men dei må også følge dette når det er klart. Dette vil gjere det enklar både å utvikle og å godkjenne/avslå innsjekkingar.
3 Plugins
- Jenkins for å starte med automatisert testing. tvl jobber med å opprette nytt testmiljø for Cerebrum. Vi ser på bruk av Jenkins seinare.
4 Migrering
Vi tek med all historikken frå Subversion, med mindre det ikkje vert mulig å gjennomføre.
Er anbefalt i Git å ha eige repo for kvart element som ikkje heng for tett saman med anna. Kva tek vi ut i eigne repo før migrering?
Alle mapper i clients/, og nokre mapper i servers/. Er uklart kor vi set grensa, vi må lage ein oversikt over dette.
4.1 Beskrivelse av migreringsprosessen
Skal vi bruke git-svn:
# get users' names and e-mail addresses (author mapping) git svn clone <svn.uio.no> # rydding av refs (remotes og tags) git push <stash>
alternativt subgit-doc:
# installer subgit # get users' names and e-mail addresses (author mapping) subgit configure # config subgit install ... subgit uninstall # remove translation hooks
5 Prodsetting
- Produksjonsmiljøet set størst føringar for korleis migrere og sette i produksjon.
- Migreringsperioden vil vere langvarig. Vi vil ikkje få migrert over alle instansar på berre ei veke. Vi bruker då forslaget om at lager ein synk frå nytt Git-repo til gamal Svn-repo, med dummy-innsjekkingar. Dette gjer at ikkje-migrerte instansar framleis kan sjekke ut enkeltfiler som før. Det er viktig at dette ikkje varer altfor lenge.
- Kva må gjerast før vi kan migrere?
- Forslaget er å migrere berre ein instans, som ikkje er kritisk, men som det vert utvikla på. Akkurat no er WebID ein aktuell kandidat.
- Drift må få laga nye rutiner for prodsettinga med Git.