Til stades
- hanskfje
- pehaavin
- jokim (ref)
- estephaz
- kvaade
- jsama
elisabhs (permisjon)tvl (permisjon)
Sak 1: Utviklarar og deployering
Skal utviklarane sjølv ta seg av deployering av Cerebrum og tilhøyrande kode? Sjå forslag til grensegang ved prodsetting (forslag i blå tekst), og overordna rutine for prodsetting.
Kommentarar til grensegangsdokumentet:
- KIA: Kva betyr "prodmiljøet" i ansvar for prodmiljøet? Ønsker heller å kalle det "drift av applikasjonen Cerebrum". Tilbakemelding frå Hans Kristian er at INT ønsker å ha ein enhet som har det overordna ansvar for prodmiljøet, men som delegerer driften vidare nedover, sjå basis-drift - dette for å unngå at utviklarane må forholde seg til mange forskjellige driftsinstansar som ikkje nødvendigvis har ein dialog seg i mellom.
- Ansvar betyr ikkje at du må ha kompetanse på drift av kvar del. Ved problem tek du kontakt med dei som har kompetansen, til dømes dba-drift og nett-drift, og ser til at dei fikser problemet.
- Grensegangsdokumentet er ingen SLA. Det er berre for at vi skal ha eit utgangspunkt å jobbe utfrå, i samarbeid. Vi kan endre på dokumentet etter behov.
- Prodsettingsverktøy: Fleire har lukta litt på bedre verktøy enn det som brukast i dag, td. ansible. Korleis vi fordeler dette mellom drift og utvikling må vi sjå nærare på etterkvart. Drift kan ha ansvaret, men utviklarane må hjelpe til med å spikke på prodsettingsverktøya. La til dette i punktet i dokumentet.
- Spesifiserte at ansvaret for prodsettingsrutiner betyr ansvar for å spesifisere og dokumentere, og ikkje utføre.
- Tilbakemelding om at driftarane bør ha ein test på om ei endring funker for kvar prodsettingssak.
- Kven skal drift kontakte ved problem med ei prodsetting? Saker skal sendast over til RT-køa cerebrum-utvikling, i tillegg kan ein kontakte INT si ukevakt. Ein følger rutina som for alle andre henvendelser.
- Håper på sikt å få dratt inn driftssenteret i dette. Må då sjå på grensegangen på nytt, i ny interaksjon. Er ei stund til endå.
Vart til slutt enige om grensegangsdokumentet, så då er det spikra.
Kommentar til rutine-dokumentet:
- Kommentar til å "prodsette så ofte som mulig". Drift ønsker å kunne bestemme frysperiode, tidspunkt som det ikkje skal prodsettast på. Var litt diskusjon rundt dette punktet. Vart enige om at dette går av seg sjølv, spesielt når utviklarane får ansvaret, så vi skriv det ikkje inn. Ein utviklar som evt. skulle prodsatt fredags kveld vil svi for det, ved å bli oppringt i helga, og gjer ikkje det igjen.
- XMPP er ikkje godt nok for informasjon. Vi må ha ein oversikt over alle prodsettingar, uansett kor små.
- Ønsker mest mulig automatikk, minst manuelt og knot.
Joakim las fort opp rutineforslaget. Trengs litt meir arbeid.
Nådde ikkje å diskutere meir. Vart enige om vegen vidare:
- Joakim utvider rutine-dokumentet med tilbakemeldingane til no.
- Joakim kaller inn til neste møte, der vi forhåpentlegvis kjem til ein konklusjon.
- Cerebrum drift les meir gjennom rutinene i detalj og kjem med innspel. Sender e-post med kommentarar til alle involverte før neste møte, så alle får sett og evt. kommentert.
Sak 2: Utviklarar og KIA si ukevakt
Skal utviklarane ta del i KIA si ukevakt, til dømes kvar fjerde veke? KIA skulle ta ein intern diskusjon på om dette er hensiktsmessig, sidan det også krever opplæring.
Nådde ikkje dette, utsatt til neste møte.
Sak 3: Overvåking av Cerebrum-loggar
Skal INT si ukevakt utvidast til å også overvåke Cerebrum sine loggar for feilmeldingar? Dette krever ein del oppfølging. Vi nådde ikkje å konkludere noko rundt dette, så vi må diskutere vidare.
Nådde ikkje dette, utsatt til neste møte.
Sak 4: Workshop for å gå gjennom og løyse feil
Eit anna forslag som dukka opp, var om vi skulle arbeida med å løyse Cerebrum drift sine tidstjuvar. Vi går først gjennom det daglege arbeidet til Cerebrum drift, og ser på kva dei bruker tid på. Alt dei bruker unødvendig lang tid på rapporterer vi som bøggs, som vi deretter løyser. Noko er feil som kan fiksast og fjernast, andre bøggs kan det lagast verktøy for. Større bøggs kan takast med som vanlege utviklingsbestillingar. Skilnaden på dette og ein bøggfiksingsworkshop, er at vi er oppsøkande og leiter etter problem.
Nådde ikkje dette, utsatt til neste møte.