Rulle ut nye versjoner av FS-databasen
Fra og med høsten 2023 prøver vi ut en ny prosess for utrulling av nye versjoner av FS-databasen. Dette dokumentet inneholder en beskrivelse av den nye prosessen. Det vil bli oppdatert etterhver som vi gjør oss nye erfaringer og forbedrer prosessen.
Den overordnede prosessen ser slik ut:  Løpet er litt forskjellig ut fra om endringen skal ut i en hovedrelease eller ikke, og om det er behov for nedetid på databasene. Vi har også skissert et løp for hotfiksing.
Hovedrelease
FS-databasen kommer normalt i to hovedversjoner per år, én vår-release og en høst-release, jf. fellesstudentsystem.no. Etter normal prosedyre starter oppdateringen av demobasene ca. 30 dager før produksjonsdatabasene. Ny databaseversjon skal i utgangspunktet være klar og ferdig testet internt innen henholdsvis 1. februar og 15. oktober. Vi starter derfor prosessen noe tidligere:
| Hendelse | Dato vår | Dato høst |
|---|---|---|
| Release-prosessen starter | 15. januar | 1. oktober |
| Utrulling til demo og test på institusjonene | Ca. 1-15. februar | Ca. 15. oktober - 1. november |
| Release til prod | Ca. 1-15. mars | Ca. 1-15. november |
Releaseprosessen starter med å avtale nedetid innenfor det forhåndsvarslede vedlikeholdsvinduet med drift, og varsle om dette internt og eksternt. Vi vil normalt ha nedetid ved release av hovedversjoner.
Det interne varselet skal inneholde informasjon om siste frist for å merge inn ny funksjonalitet til main. Når denne fristen er passert, tar vi ut en release-branch fra main-branchen (i praksis betyr dette at vi innfører feature-freeze for denne versjonen). Deretter følger en periode med testing og kvalitetssikring av release-branchen før vi ruller ut den nye versjonen i demo- og produksjonsbasene i de avtalte tidsrommene. Hver institusjon vil også normalt få ca. 14. dager til å teste endringene i sin demobase før endringene går ut i produksjonsbasene.
Release utenom hovedrelasetidspunktene
Det er også mulig å rulle ut små og store endringer utenom hovedrelease-tidspunktene, forutsatt at eventuell nedetid blir avtalt og varslet på vanlig måte.
Hotfiksing
Prosessen for hotfiksing blir nokså lik den ordinære prosessen. Forskjellen er at vi her vil branche fra den versjonen som ligger i produksjon, og ikke fra enden av main-branchen. Er det behov for nedetid, vil vi normalt gå for første mulige tidspunkt, og med ingen eller svært begrenset tid til testing i demobasene.