Idag hände något helt nytt. Jag tog en promenad med grannen – en mamma till något av barnens klasskamrater. Det har jag gjort många gånger förut, men det har aldrig tidigare hänt att jag har pratat releaseförfaranden med någon av mammorna i området. Efter att vi hade avhandlat marsvinspassning och hämtningar och lämningar med eller utan pulka kom vi in på om vi på svti pratar om releaser eller deployment. Det visade sig att mitt mammasällskap jobbar som release manager tidigare på SAS och nu på SEB. På vilka dagar releasar ni? undrade hon.
Framåt fikat kom min man in i samtalet också – de båda releasar varannan vecka på torsdagar. Fredagar vill man ju inte releasa på om något går fel som man måste åtgärda direkt. Vi på SVTi är stolta över att kunna releasa varje vecka, men på tisdagar – om vi av någon anledning inte kan releasa på tisdagen hinner vi fixa det till torsdagen och får till en release då. Däremot har vi haft problem med ansvarstagande vid varje release. Det går på rullande schema från team till team, ett nytt team har ansvaret varje vecka, och då har inte alltid de övriga teamen intresse och fokus på att se till att allt fungerar. Det är just det mamman här har som tjänst – att äga releasen och säkerställa att alla team har förstått vad den kod de ska släppa ut kommer att innebära för alla parter – och vad det kommer att innebära för alla parter om det inte blir en release.
I den här diskussionen ingår naturligtvis frågan om hur testningen fungerar. Hos oss finns det en testare per team som utifrån protokoll går igenom alla funktioner som är kritiska. När vi bygger svt.se responsive resulterar det i enormt mycket testning – på alla plattformar, med en uppsjö av browsrar i olika versioner. På SAS viktavvägningssystem fick det helt enkelt inte finnas buggar eftersom det inte går att riskera att planet blir för tungt…
Testare är således ett mycket viktigt yrke. Och release manager likaså.
Tack för kaffet.
Lägger i efterhand till barnteamets ex scrum master Yassal Sundmans detaljerade inlägg om den knackiga vägen till bättre releaseförfaranden på SVTi.
Malin Ströman 
#1 av Helen Kreutz-Bolander på januari 27, 2013 - 10:48 e m
Låter som en mycket trevlig promenad. Hade jag också gärna tagit 🙂
Borde inte varje team vara intresserad av att deras del i releasen inte strular även om de inte håller i releasen? Eller behöver de inte hjälpa till att fixa om det strular? Nu är ju vi färre men jag känner ju att alla som deltar i ett projekt faktiskt känner ansvar inför en release. Ingen vill ju sätta en kollega på pottan.
Testning är ju något som det alltid görs för lite av tycker jag. Svårt att få kunden att betala för det också, när det ‘bara’ gäller en webb.
GillaGilla
#2 av malinstroman på januari 27, 2013 - 10:53 e m
Kan tänka mig att tjänsten release manager har uppstått lite ur problematiken att alla har sitt att tänka på – det behövs en mamma eller pappa som dubbelkollar allt :-).
GillaGilla
#3 av perkovich på januari 27, 2013 - 11:04 e m
Vi på TV4 jobbade bort releasedagar helt och deployar nu när något är gjort, oftast mer än en gång dagligen (kolla TV4-texttv sid 685). På väg dit och för att få det att funka har vi jobbat bort mycket som inte funkar bra eller som satt käppar i hjulet.
Funkar mycket bra för webb men hade liv varit på spel hade vi nog putsat lite till.
GillaGilla
#4 av Joakim Jardenberg (@jocke) på januari 28, 2013 - 8:04 f m
Ni har aldrig funderat på att gå över till continuous deploy/delivery/release istället?
Har varit såld sedan jag långt innan jag hörde den här presentationen:
http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
Som fokuserar ganska mycket på kulturen snarare än tekniken.
(och så klart kompletterat med ”flags and flippers” som beskrivs så fint här http://code.flickr.net/2009/12/02/flipping-out/ 😉
GillaGilla
#5 av malinstroman på januari 28, 2013 - 9:22 e m
ooh vilken fin presentation – kristallklart, samlat och mitt i prick, tror vi har det mesta på plats utom det sista kanske – kulturen som ofta känns som det svåraste att få att blomstra
GillaGilla
#6 av Ola Sundell på januari 31, 2013 - 10:01 f m
Jag jobbade som release manager här på SVTi innan vi avskaffade tjänsten och började gå mot continuous delivery. Vi använder oss också av feature flippers.
Vi har några komplicerande faktorer som gör att CD är en liten bit bort.
Eftersom vi har valt att skära våra team på produkt istället för teknik, innebär det att en ändring i ett javascript från en utvecklare i ett team, kan komma att påverka saker för alla team.
Förhållandevis många tester för svt.se är svåra att automatisera, men vi jobbar stenhårt på det.
Det är inte helt trivialt att göra relevanta och produktionslika prestandatester på det vi gör, av samma anledning som det är svårt att automatisera tester. Därför kan det vara svårt att automagiskt hitta den typen av problem innan vi har rullat ut.
Vi har ett helt automatiserat releaseförfarande till test, stage och produktion utan nertid för besökare och med nästintill obefintlig nertid för redaktörer. Vi har även mellan 20-100 commits om dagen. Även om man inte behöver ta hänsyn till nertiden, så blir det rätt många utrullingar i produktion per dygn om varje commit ska ha sin egen produktionssättning.
Målet är självklart att koden alltid ska vara i releasebart skick och att vi ska rulla ut varje commit. Det är en liten bit kvar, helt enkelt, men utmaningarna är intressanta och roliga!
GillaGilla
#7 av malin ströman på januari 31, 2013 - 4:27 e m
oh vad jag håller med dig om att utmaningarna är roliga och vad gäller de tekniska processerna upplever jag som sagt att vi jobbar på bästa sätt, men bristerna i ansvarstagande från varje team under release är ändå ett kulturellt problem och inte ett systematiskt och det är mer den typ av utmaning som jag är delaktig i som produktägare… eller hade jag inte känt mig fullt trygg med den tekniska utvecklingen hade jag säkert varit där och rotat lite hysteriskt också…
GillaGilla
#8 av perkovich på januari 28, 2013 - 8:08 f m
895 that is..
GillaGilla