Workflow for releases og nye opgaver

Owned by Rasmus Rosendal (Unlicensed)
Last updated: Oct 10, 2016
2 min read

På denne side beskrives, hvordan releases, nye opgaver og fejl håndteres.

 

Releases

Tidshorisont

  • Der forventes release hver tredje måned, dog på sigt formentlig 2 gange årligt. 
  • En kommune kan ønske en feature installeret i en speciel version mellem mellem to realeases.
  • Mellem hvert release kan der lave hotfixes ved kritiske fejl, som efter ønske kan installeres ved kommunen.

Versionering

Nummerering følger denne skabelon: version x.y.z, fx 2.3.2 

x = releasenummer: Vi kører med regelmæssige releases (i første omgang hver 3. måned). Ved disse releases får alle kommuner den nyeste version med de features, det er aftalt skal være implementeret. Konfigurationsfiler ved den enkelte kommune afgør om en feature slår igennem. Versionen ved releases vil altid være x.0.0

y = featureversionsnummer -> Hvis en kommune ønsker en vigtig feature hurtigt, som andre kommuner ikke ønsker lige nu, er det muligt at lave en version, hvor denne feature eksisterer. Den kan derfor implementeres før den næste release dato, hvilket vil gøre at enkelte kommuner FREM til næste releasedato kan have en unik version. Kommuner vil altid have samme x, men y kan variere

z = Hot fix nummer -> Ved kritiske fejl i produktion kan man lave hot fixes. Disse bør installeres ved alle kommuner. Derfor vil z altid være det samme for alle kommuner.

Når der deployes kode til kommune bør det i branchnavnet fremgå, hvilken version, den enkelte branch indeholder.

Hver release vil kunne findes på sin egen branch i release/ mappen på github. Navnet på branchen skal være versionsnummeret, fx 2.3.1

 

Nye opgaver og fejl

Eksternt

Nedenstående dokument er sendt ud til koordinationsgruppen den 27/9-2016. Dokumentet indholder instruktioner til kommunerne om, hvordan deres medarbejdere skal indberette fejl og ønsker til nye features, heriblandt hvilke informationer der ønskes fra Miracles side i forbindelse med inberetning af fejl.

Internt

  1. Medarbejder ved kommune oplever fejl/nyt behov for funktionalitet. Fejl/opgave rapporteres ind gennem JIRA efter skabelon til formålet.

    1. Fejl: sagen assignes til udvikler på projektet efter prioriteret rækkefølge.

    2. Ny feature: sagen er prioriteret af koordineringsgruppen.

  2. Supportafdeling/Kristian kigger på sagen, og vurderer hvilken udvikler den skal assignes til.

  3. Alt efter prioritering i forhold til andre OS2 udviklingsopgaver, påbegyndes evt. analyse og estimering, eller fejlsøgning og udvikling.

  4. Udvikleren løser opgaven, og tester på i sit eget lokale miljø.

  5. Når opgaven er løst, deployes den til vores interne testmiljø, hvor Kristian eller en anden tester afprøver om alt er som det skal være.

  6. Efter opgaven er testet OK, vurderes det, om der er tale om et hotfix, der skal deployes til kommunerne hurtigst muligt. Hvis ikke, skal det bestemmes hvilket release opgaven skal med i.

  7. Opgaven kommer herefter med i et test-release, som lægges på pre prod serveren hos Syddjurs kommune, hvor sagens kontaktperson får mulighed for at teste.

    1. Hvis der stadig er fejl, kommer opgaven tilbage til udvikleren, og herefter ud i anden runde af test releaset.

  8. Når alle opgaver i test-release er testet OK, bliver der lavet et endeligt release, som deployes til alle kommuners produktionsmiljø.