Tenestegruppemøte januar

Første tenestegruppemøtet i 2015.

Agenda

Formålet med dette møtet er å fortsette på arbeidet frå forrige møte, som går ut på å styrke tenestegruppa vår.

Agenda:

  • Mandat for tenestegruppa - Vi har eit utkast til mandat som vi ønsker at tenestegruppa kommenterer
  • Bestillingar frå tenestegruppa - Introduksjon, diskusjon og forslag til bestillingar
  • Versjonering av Cerebrum - Introduksjon og diskusjon
  • Ymse - folk må gjerne sei frå om punkt dei vil ta opp

Referat

Sjå presentasjon frå møtet.

Tilstede:

  • tvl
  • elisabhs
  • jsama
  • xiaoliz
  • estephaz
  • hamar
  • fhl
  • jokim
  • jbr
  • tgk

Mandat

Joakim presenterer nytt mandat for tjenestegruppen.

Formål

  • Sikre høyt faglig nivå
  • Koordinering og samarbeid

Ingen andre *oppgaver* i tjenestegruppen, tilhører KIA og UAIT. Tjenestegruppen har ikke noe *ansvar*. Ansvar går i linja, tjenestegruppa er for koordinering.

Fellesoppgaver

  • Koordinering
  • Bygge kompetanse
  • Forbedre og sikre Cerebrum
  • Dialog med partnere
  • Dokumentere og informere
  • Forvaltning

Innlegg: Gjør vi feil?

  • Forespursler på tvers av gruppene – hvor passer dette inn i fellesoppgaver?
  • Hvor går grensen for arbeid, bestillinger, oppgaver som kan løses i tjenestegruppen i stedet får å gå langs linjen?
  • DevOps – Bør fellesoppgave/formål utvides for dette? Bør vi ta et skritt nærmere DevOps?
  • Spørsmål om kven som har som oppgave å vedlikeholde tjenester/it/brukernavn-passord/
  • Etterspurde at det burde stått noko om XMPP (chat), sidan det i hovudsak er der tenestegruppekommunikasjonen foregår
  • Uklart kva som skal gå i linja, og kva som går på tvers (dvs. i tenestegruppa): Generelt: Småting går på tvers, større ting (dvs. masse arbeid eller konsekvensar) må gå via linja.
    • Alt som er driftskritisk går også på tvers
    • Ønske om ein definisjon på dette - og at det er dokumentert

Oppgaver som ikke hører til tjenestegruppen

  • 1.-linjesupport – dette skal gå gjennom Houston, men tjenestegruppen bistår
  • Brukeradministrasjon – henger fremdeles igjen etter brukerreg-tiden, og overgang til USIT 3.0. Ansvar antas ofte å ligge hos Cerebrum Drift eller tjenestegruppen. Tjenestegruppen skal tilrettelegge for å legge slikt ansvar hos andre. Må gå noen runder til med dette, siden det ikke er avklart.
  • Forvaltning – men muligens forvaltning av navnerom? Hva med forvaltning av kontrakter med partnere?

Roller

      GL KIA         GL UAIT
         |              |
         |              |(linja)
         |              |
         |              |          (koordinering)
+--------+--------------+-------------------------+
|        |              |                         |
| CerebrumDrift CerebrumUtvikling  Tjenesteleder--|-- Tjenesteeier
|                                                 |
+-------------------------------------------------+

Oppsummeringen er at folk fikk mer forståelse og innsikt i mandatet, men at noe gjenstår. Ikke alle spørsmål er besvart, og det er gråsoner mellom hva som tilhøyrer tjenestegruppen og hva som er KIA og UAIT, og andre. Joakim tar det videre med Elisabeth og Hans Kristian. Er opp til Hans Kristian å forankre det når utkastet er ferdig.

Kom spørsmål om Cerebrum drift, dvs. KIA, har ei eiga RT-bestillingskø som UAIT har? Elisabeth skal vurdere det.

Bestillinger

Tjenestegruppen har en bestiller-rolle av utviklings- og driftsendringer. Forslag til endringer bestemmes av tjenestegruppe-leder og tjenestegruppen.

Bestillinger gjøres i respektiv gruppe sin bestillingsliste (RT), som betjenes primært av gruppeleder. Bestillingen kan så legges inn i backlog hos gruppen, og prioriteres ift. andre bestillinger. Joakim bestiller, og legger tjenestegruppen på CC.

Ble tatt opp to bestillinger:

Format på logger
  • Ønsker å standardisere, for felles forståelse mellom drift og utvikling
  • Standardisere logg-nivåene
  • Meldingsinnhold
  • Sensitive data i loggen

Dette var ønsket av tjenestegruppen - Joakim bestiller.

Bøggfiksings-workshop

Det er en god del ikke-kritiske bugs i Jira for Cerebrum. Disse skaper ekstraarbeid for Cerebrum drift - en bug gir ikke så mye ekstraarbeid, men når det er såpass mange skaper det arbeid for drift. Ønsket er å redusere dette antallet, og vi foreslår derfor å sette av en dag der drift og utvikling setter seg sammen og løser så mange som mulig.

Tjenestegruppen var positiv - Joakim bestiller.

Kurs av drift

Det er behov for at Cerebrum drift får litt mer kompetansedeling av utviklerene i ulike deler av, og funksjonalitet i, Cerebrum. Forslaget er å bestille kursing av Cerebrum utvikling for drift, og nye utviklere.

Cerebrum drift trenger å tenke litt på dette, og komme tilbake til det i neste møte. Venter derfor med denne.

Kodestandard

På møtet kom det også innspel om å også bestille at Cerebrum får seg ein kodestandard. Dette påvirker grensesnittet, sidan Cerebrum drift må forholde seg til koden på eit visst nivå. Eit typisk døme er bruken av "--commit" eller ikkje ved køyring av skript.

Alle i tenestegruppa var enige om at dette kan bestillast først som sist.

Versjonering

Formål: Tydeliggjøre endringer i Cerebrum, spesielt for partnere.

Forslag fra Joakim:

  • Gjøres i Jira/Vortex
  • Ny versjon etter hver sprint som har issues i CRB
  • git tags for hver versjon
  • Så enkelt som mulig i denne runden, kan evt. utvide når en ser behov/muligheter

Ble en diskusjon rundt det tekniske, rundt branching av Cerebrum per versjon, og bruk av git-flow. Folk tok opp om git-flow kan brukes og gjøre det enklere for oss å følge riktig versjon. Joakim er skeptisk til å innføre noe ekstra rundt versjonering på det kodemessige, då vi har omtrent rolling release av Cerebrum, og forholder oss aldri til annet enn siste versjon.

Annet

Joakim informerte om litt forskjellig.

Drift ser fremdeles på smidig metodikk, men har ikke landet helt i å finne arbeidsprosess. Jobber med det. Kom spørsmål om bruken av Jira versus RT. Har ikkje konkludert noko her, men vil kunne bli endringar. Uansett vil RT brukast for eksterne henvendelsar i overskueleg framtid.

Kom innspel om ønske om hospitering mellom drift og utvikling.

Publisert 15. jan. 2015 06:04 - Sist endret 5. feb. 2015 13:41