60. Vi slänger bara ut
lyssna!
Efter att ha avhandlat det senaste hippa sociala nätverket så snackar vi om produktionssättning, deployer, releaser; kalla det vad ni vill men det är något vi alla måste göra. Det blir en hel del om testmiljöer, e2e-tester, git när det brinner, hur svårt det är att säga Netlify samt argumenten för att släppa allt till produktion direkt. Dessutom en hel del om att ta en bra process för givet, kill_switch=”on” och jourens vara eller icke vara.
Om du gillar podden blir vi väldigt glada för en liten recension i iTunes eller en prenumeration på Spotify. Följ oss och säg hej på @asdfpodden på Instagram eller Twitter (Anton, Therése) <3
Länkar
Avsnittets skämt:
Varför är en tom array så kall?
Den har inga element.
Skrapa här!!
Transkribering
Transkriberingen är gjord av nån "AI-grej". Du kan förbättra den genom
att
klicka precis här :)
Varför är en tom array så kall?
Jag vet inte.
För det finns inga element.
Aaaah.
Aaaah, aaah, det var ändå bra.
Aa, aa, aa, nice.
Jag tänker inte erkänna att jag snodde den från podd, eller kodsnacks slack, men det kanske jag gjorde.
Var den där för din benefit, eller var det bara någon som drog ett pappaskämt allmänt?
Det var nog någon som drog ett pappaskämt allmänt kanske.
Men jag tror han heter Emil.
Han skrev också att den var snodd.
Så då snor jag den också.
– Ja, fint.
– Det är så, livets kretslopp.
– Absolut.
– Välkommen till ett nytt avsnitt av asdf.
Det var ett tag sedan vi pratade om den.
Då var det lite semester och skit emellan.
För mig i alla fall.
– Och skit.
– Semester för mig och skit för dig tänkte jag säga.
Men så illa var det väl inte.
- Här har jag inte jobbat. - Nej, exakt.
- Så varje dag har varit precis densamma som alla andra dör.
Den här jävla BeReal-appen, eller vad fan det är, som vill att jag ska ta en bild varje dag.
Ja, jag sitter vid min dator varje dag. Vad vill du?
- Ja, men är den inte ganska rolig?
Jag har ju också den. Alltså det är liksom det nya hippa sociala nätverket.
Får man säga så när man är 31 år snart?
- Oj, är du bara 31? - Ja, jag vet.
Jag är ungt uppe i det här sammanhanget.
Herregud! Jag har alltså två personer på den här.
Det är alltså mig och en till.
Ja.
Det är typ ett socialt nätverk där man ska lägga upp en bild varje dag.
Och twisten är att alla ska lägga upp den samtidigt varje dag när man får en pushnotis.
Och sen kan man bara se den bilden under den dagen om man själv också har lagt upp en bild.
- Alltså du kan se andras bilder under den dagen. - Ja, den tar både back- och frontkamera.
- Just det, det gör den också. - Det är ett par hakor med på den här appen.
Man kan också se hur många gånger folk har tagit om sina bilder. Det är en kul feature faktiskt.
Jag brukar ta om en del, men det är för att jag är på väg...
För att den tar först den ena bilden och sen så tar den frontkameran.
Men då har jag liksom redan dragit iväg, för jag glömde bort att jag måste vänta lite.
- Ja, man måste ändå hålla sig hyfsat still i typ två sekunder.
- Ja, det är fjävligt. Men det är inte det vi ska prata om.
- Nej, men den är kul. Testa. Det är trevligt.
Jag svärjer ju att Instagram kommer att komma ut med exakt samma funktionalitet om en månad, kanske två.
- Ja, om det blir populärt. Men vet ju fan om det blir det.
- Jo, men det är ganska poppigt redan nu. I Sverige inte så mycket.
Men utomlands.
-Oj, okej. Det är bara för att jag inte har några vänner.
-Men utomlands är det ändå ganska stort.
Jag gissar på att det finns garanterat ett team på Insta nu som sitter och crunchar för att få ut den här så snabbt som möjligt.
-Ja.
-Men som du sagt, det var inte det vi skulle prata om. Vi tänkte prata lite grann om produktionssättning.
Produktionsreleaser. Produktionsdeployer.
Att lägga ut saker i produktion.
Ja, att få ut sin kod till användare.
Exakt.
Du kom in på det här lite grann för du sa att vi slänger bara ut saker direkt i prod.
Ja, det är så att vi har faktiskt ändrat det nu, det kan vi komma till sen.
Men, det är Burden nu som har en push in i main.
i main, den heter fortfarande master, men main led direkt till en release till staging och till production.
Och det är så att vi har liksom inte haft så, alltså vi har inte haft några användare tidigare,
liksom vi är i fasen att börja releasa ut det här till användare så det har ju inte varit så himla farligt liksom.
Men att vi då började med att releasa till en beta-grupp och sen ska vi ta det vidare.
Då började jag fundera på, men det känns ju inte så jävla tryggt tycker jag att det går rakt ut i produktion.
Och då började jag fundera lite på vad får en att känna att det är tryggt.
Vi hade en diskussion också om varför det går rakt ut i produktion.
Jag köper argumenten, men jag vill fortfarande inte ha det rakt ut i produktion.
Vad var argumenten?
Jag tror det var så här att om man pushar kod in i main då ska den ju fungera.
Och det köper jag.
Och sen var det också så här att om man hör att man manuellt måste promota det till produktion så ligger det bara saker i staging och ruttnar för att folk glömmer trycka ut det.
Och då trycker någon ut allting på en gång och så blir det kaos och då vet man inte vad det är som har kausat.
Just det.
Så jag köper ju de sakerna för det har jag ju varit med om.
Ja, absolut.
Men det som jag tycker då känns fel är liksom att det är ju i teorin så det borde fungera men det fungerar ju aldrig riktigt så, bara rakt av.
Nej, det är väl lite min erfarenhet också skulle jag säga.
Sen beror det lite på vad man gör kanske.
Det skulle ju kanske funka att bara trycka ut rakt ut i produktion
om man bara sitter och gör frontend-saker, typ design-grejer eller vad som helst.
Men sitter man och ändrar lite i ett API och så går allting sönder, eller det finns någonting
du gör något logiskt fel som gör att du tog bort den och använder den istället för att lägga till en ny den och registrera sig.
Ja, det här har ju hjälpt både back-end front-end och infra tror jag.
Jag kan ändå förstå det, att när man i början bygger något nytt, då är det väldigt skönt att trycka över till produktionsmiljön.
För då vill du ju se att det funkar i produktionsmiljön också. Eller liksom att produktionsmiljön funkar.
Så att du inte har någon skillnad mellan någon testmiljö och en produktionsmiljö när du väl ska release.
Ja, det är sant. Och liksom lite på det där också satt jag och började fundera på hela grejen med okej, men varför vill jag ha det mellansteget liksom?
Varför tar jag inte bara ut det rakt ut i produktionen? Det följer ju också av det här snacket vi såg, något, Noric Jäströ, kan det vart, 2019?
Det tror jag.
om att testa i produktion.
För att det enda sättet du vet om någonting fungerar i produktion,
det är ju att testa i produktion.
Och det är ju jävligt sant, liksom.
Så då kanske man snarare börjar fundera på,
okej, men vad skulle krävas för att jag skulle känna mig trygg med
att med en merge till main så går det rakt ut i produktion.
Och det första, det som vi inte har, det är väl att ha bättre tester, liksom.
Vi börjar få upp vår coverage på unitester rätt väl.
Vi har väl egentligen lite för mycket unitesterk, för de känns inte alltid nödvändiga.
Men det vi skulle behöva är ju end-to-end-tester på våra viktigaste flöden.
Och sen så typ sätta upp larm och grejer på produktion så att man vet om det sjunker.
Eller vad tänker du? Vad känner du är viktigt?
Jag håller verkligen med om att jag inte skrivit jättemycket end-to-end-tester i mina dagar.
För det är sällan det finns en tillräckligt bra infrastruktur bakom det för att det ska bli lätt att skriva dem.
Nu är det på mycket mindre skala, men jag har suttit och skrivit ett litet hobbyprojekt, eller sidoprojekt.
Jag kommer återkomma till det i ett framtidavsnitt, men just om end-to-end-tester.
Så jag har suttit och skrivit dem med Cypress.
Och då testar de verkligen alla HappyPas-typ som finns i hela applikationen, och mot en riktig databas och allting.
Och att det funkar.
Att den setupen är väldigt enkel.
Att jag kan skriva bara så här "Cypress.login"
och så får jag en inloggad användare automatiskt.
Och sen att den automatiskt rensar den användaren när den har kört klart testet.
Alltså sådana saker gör det ju sjukt värt att faktiskt ha sådana tester också.
För då kan du köra dem som sagt mot en riktig databas,
med riktig information, med typ på varje push och bara testa.
"Funkar det här?" eller "Har de ett steg innan för att verifiera?"
"Innan du deployar så måste de här testerna gå igenom."
Och det har ju varit svinskönt.
- Ja, för det är väl det jag tänker också.
Jag har faktiskt aldrig jobbat med Cypress.
Däremot har jag suttit med Selenium-tester.
Så jag tänker att det är lite samma typ av...
Typ av grej.
- Jo, men det är det ju i stort sett.
Cypress är väldigt trevligt och har blivit mer trevligare och trevligare.
Det känns som en väldigt bra produkt eller projekt.
För det är ändå gratis för de flesta.
Men att du kan egentligen köra dem i ett gränssnitt som spelar upp allting framför dig
och du kan scrolla dig tillbaka i historiken på testet och se exakt vad den klickar på.
Alltså det är väldigt trevligt.
Jag kan varmt rekommendera att testa och sätta upp.
Men som sagt, jag tänker att det är det här andra runt omkring som är det jobbiga med end-to-end-tester.
"Du vill gärna köra mot en databas. Vilken databas ska man köra mot?"
"Vilken data ska finnas i databasen?"
"Hur ska man rensa data när man är klar med testerna?"
I mitt lilla CD-projekt kör jag med en SQLite-databas.
Det är bara en fil. Den skapar en helt ny databas och sidar den i testerna.
Det funkar väldigt smidigt.
Men för riktiga projekt, eller vad ska jag säga,
med en större projekt, så har man ju ofta en dedikerad databas
som snarare än bara är en fil som man kan skapa upp i varje test.
Ja, men jag tänker att det kanske är så att om man kör typ Flyway,
att man skulle kunna spinna upp en lokal databas
och sedan köra alla migreringarna så att jag har den.
Ja, men precis.
trycka in någon data. Men det där är intressant också med Flyway,
vi hamnade i en situation där back-end-tjänsten,
den tog bort en sak rap i it som fronten fortfarande använde,
så det blev kaos.
Det var ju också inte uppsatt, det var uppsatt via GitHub Actions,
så vi kunde inte rulla tillbaka deployer,
och då var det så här, men det är ju bara att göra en git-revert.
-Okej, och då kom vi på hur fan jag inget revert, och så kunde vi inte bara göra en revertad pull request, jag kommer inte ihåg varför, och då blev det jävligt så här "shall we pick up, shall we pick up, vad fan gör vi här, hur gör vi inte det här?"
och sen fick vi till slut till det, så la vi upp en pull request och sen så här "ja men det är en fly away migrering här i, och den kan vi inte bara backa, eftersom den är versionerad"
Vi fick ändra allting, lägga upp en ny flyway, migration och bla bla bla.
Så det funkar ju inte.
Det hade ju inte räddat oss fortfarande att ha ett sätt att rulla tillbaka en deploy
eller rulla ut en annan deploy.
Men det är ju kanske en av de sakerna jag verkligen vill ha för att känna mig trygg i
att deploya ut saker.
Att jag vill ha en möjlighet där det är lätt att rulla tillbaka.
Inte så här att vi måste get reverta saker.
Det är jättelätt i teorin.
Men när det brinner, då blir det så här, hur mycket fuckar jag upp om jag gör det här git-kommandos fel?
Ja, exakt.
Det är väl lite, just databaser är ju lite olyckligt.
Att det är ganska mycket svårare att bara rulla tillbaka rakt upp och ner.
Ja.
Jag vet, det finns en tjänst som heter PlanetScale, som är hostade databaser typ i Postgres.
De har tagit och utvecklat filosofin med versionshantering och git och grejer till databaser i stort sett.
Så att du kan ha olika branscher av din databas på deras tjänst.
Och sen när du ska deploya dina databasändringar så merjar du en bransch in i din produktionsdatabas.
Och då kör du migreringar på den databasen.
Och de har också gjort något magiskt, att du kan just reverta som du skulle göra med git.
fast du gör det på din databas istället.
Så då "revertar" den där du har gjort i din andra bransch.
Så blir det liksom som det var innan.
Och det verkar jävligt coolt.
Jag har inte kört dem jättemycket.
Jag har bara de på något litet sideprojekt.
Men det verkar jävligt coolt.
Vad, ett av dina sideprojekt?
Ja, just det här är på min antagundasköp.com
som jag har hållit på att bygga om till en ny version i typ ett år.
Och jag har inte gjort klart.
Men vi får se om den blir klar någon gång.
Gud, att du har databaser. Jag har bara frontend-kod.
Ja, men det var för att jag ville göra någonting. Jag försöker lägga in en massa easter eggs.
Och då tror jag att ett easter egg är att man kan lägga in att man kan vinka på sidan.
Eller något sånt, och då blir det en databas.
Så vi får se. Det kommer inte bli någonting av allt jag säger nu.
Men vi kanske får möjlighet att återkomma till det också.
Men det verkar så himla meckigt allt det där.
Jag förstår verkligen varför många backendare är så himla bra på tester.
För att det är den där feedbacken som finns på att man inte har pajat någonting.
Ja, verkligen.
Det var ju det vi var inne på, att en-ta-en-test är svimbra.
Men också tillbaka-rullandet är ju sjukt nice när man väl har det.
Om du bara kan klicka på en knapp och så kan du ta ut den gamla versionen så kan vi felsöka det här och se vad som händer.
Ja, vi hade en situation där produktion låg nere.
Och så var det någon som skrev produktionen ner i kanon och kollade på det.
Det jag gjorde då var för Fronten-appen är hostad via Netlify.
Så det jag gjorde var gå in på Netlify och trycka ut tidigare deploy.
Och så sa jag det, "men jag gjorde det i Netlify".
Netlify, det är svårt!
Jävlar.
Och då fick jag svaret "men du kan också bara göra en git revert".
Jag bara "jo, men det här gick ju på två minuter".
Och det hade kanske inte tagit super mycket längre tid på att göra en git-revert.
Men det jag kunde göra var att stanna i master, bara be alla "Tryck inte ut den, gör en fix på två minuter och sedan ha prod upp igen."
Ja, exakt. Det är ju sjukt smidigt, faktiskt.
Jag såg att Netlify hade några prestanda-problem idag. Eller inte prestanda-problem, jag tror att de låg helt nere.
Ja, jävlar! Jag fick så många 502-er i min Preview Deploy. Jag fattade ingenting.
Jag testade Login också.
Sådär 502-er och helt svarta jävla RO-skärmar.
Alltså, det var...
Det var spännande, va det?
Vi hade problem med alla våra system, tror jag de skrev.
Man bara hopp, okej, kul.
Ja, någon hade svettigt, så att säga.
Så var det garanterat.
Du nämnde också Preview Deploy.
Det tycker jag också är ett ganska bra steg att ha.
Sen är det kanske lite mer i puller och cast-flöden.
Men det känns också som att man vet att man kan testa in miljö
utan att känna pressen på att merja in i main.
Mm.
Och det är faktiskt jäkla trevligt.
Jag försöker komma in i att använda deploy previews.
För jag tar ofta hembranschen lokalt och spinner upp den och testar där.
Men det är skitbra för designers att säga "om du vill design-reviewa, kolla på den här branschen, det finns här och här, du kan kolla på det".
Och sen har vi något problem med att det inte går att få upp Localhost i Safari av någon anledning.
Så det är också svinbra att jag kan få en, i vår pull request så får vi en QR-kod till Privy Deploy, så jag kan bara få upp det på min mobil.
Det är så jävla smidigt.
Man älskar ju ändå sådana här Quality of Life-grejer.
Alltså så här att det spottar ut en QR-kod som man kan scanna för att få upp den på telefonen.
Ja, så jävla smidigt.
Mår bra varje gång jag kommer ihåg att använda den.
Ja, det är en toppenidé.
Jag har inte sett det förut något, tror jag.
Nej.
Är det en Netlify-grej eller är det bara en grej ni har?
Det vet jag faktiskt inte.
Min gissning är ju att det är en Netlify-grej.
Det är ju Netlify som spottar ut sig en comment i Git-appen.
"Här finns preview-deploy, här är Netlify-linken och här är en QR-kod."
Och så får vi dels en för webbappen och en för storybooken.
Det är också skitnice.
Det är löneförhöjning till den personen på Netlify som kom på det här.
Ja, om det inte är samma person som sänkte Netlify.
Då väger det upp. Man får en gratis produktionsdrivstörning för att man kom på den idén.
Ja, fan nice.
Jag tycker också det är spännande för när jag började jobba och konsultade också.
På första stället jag var på då så hade vi tre produktions-deploy per år.
Åh, jäklar. Sjukt.
Det är så jävla sjukt att tänka på nu.
Jag känner folk som jobbar där fortfarande.
Det är väl kanske en produktionsdeploy i månaden.
Sist jag pratade med dem var det ett tag sedan.
Men det är lite sjukt när man tänker på det.
Samtidigt som man själv bara "men vi kan inte deploya hela tiden till Prod".
Och de andra "kan vi inte få deploya mer till Prod?".
Så man måste hitta någon typ av balans.
Jag vet liksom inte riktigt vad som är det optimala.
Det känns som att det måste vara ganska flexibelt för att jag ska vara nöjd.
Man kan trycka ut det till prodd för att jag vet att det inte kommer påverka något.
Eller att man måste ha en massa QA innan, testare som går igenom allting innan.
Sådana saker som ger mer process och byråkrati istället för att det ger jättemycket värde.
Jag är väl en sån som tycker att man ska kunna trycka till prodd hela tiden.
Ja.
Egentligen. För att i teorin så ska saker vara så pass små, du ska ha så pass mycket test och code review och grejer att du ska kunna trycka ut det.
Men jag är så här, om man inte har fångat innan så kommer man ju ändå kanske inte göra det förrän det går ut. Så jag är mycket mer för att bara trycka ut saker.
Ja.
Men jag har ju haft en jävla räkmacka egentligen från det jag började. Jag fattade ju inte ens från början hur man kunde göra något på något annat sätt.
För jag kom ju rakt in i Continuous Deployment med små produktionssättningar varje dag hela tiden.
hela tiden och sen har det ju bara fortsatt. Sen har det ju blivit så här, ja men vi ska ha en release, vi har inga användare, vi ska släppa ut ett till användare och sådana saker har det ju varit såklart.
Men det har aldrig varit någon vattenfallsprojekts grej. För det var en gång jag var på en intervju och de var så här, ja men vi produserar genom att SSH är in på servern och gör en git pull.
Ja, ja.
Och där vet jag inte om jag hade gjort mig på det uppdraget, så det var kanske...
Ja, kanske var lika bra.
Kanske var lika bra. Så det hade varit en upplevelse, får jag ju säga, som jag inte varit med om tidigare och gissningsvis kanske inte kommer vara med om.
Jag känner mig väldigt bortskämd. Anledningen till att jag började fundera på det här mycket var att det känns som att jag tagit det för givet.
– Ja, jag fattar. – Speciellt när jag har pratat med någon som pratar om produktionsförfarande och jag är så här "Va? Trycker man inte på en knapp bara? Vad håller ni på med?"
Nej, det är lätt att hamna i sin bubbla. I alla fall när man har suttit ett tag i en specifik miljö och så här att "ja men det är så här vi gör" och så bara tycker att det funkar bra.
Men så har man någon annan som bara "nej men vi gör på det här sättet" och man bara "va? Hur?" Så det är inte rätt.
Hur mår ni?
Exakt. Och sen kanske det visar sig att det funkar jättebra för dem.
Men det är så lätt att bara tänka att "ja, vi gör det på rätt sätt och jag är så nöjd med att det går så snabbt".
Sen kan det ju bli åt andra hållet också, att man hör någon annan som bara "vi deployar på det här sättet" och så låter det mycket bättre.
Och så spricker den där lilla bubblan av att man har det toppenbra.
Ja, man ska inte prata med andra. Man ska bara sitta still i båten.
Inte lära sig något från andra.
Nej, fy fan.
Men en annan sak som jag tänkte på som också kan ge lite peace of mind är att ha feature togglar på saker.
Så att du ändå kan deploya ut i produktion så att de inte blir liggande jättelänge.
De här sakerna som du sa kan bli liggande i någon testmiljö och så är det ingen deployer.
Men att man hela tiden har att vi kan deploya ut det här men vi har feature togglat det.
testa dig på en viss del av användarna eller på några beta-användare.
Och det är ju också väldigt skönt.
Ja, det är ju nice med feature toggles och folk pratar om det så mycket.
Men det är väldigt länge sedan jag satt med ett ordentligt feature toggle-system.
De senaste feature togglarna jag gjort är typ så här...
"Du måste ha det här värdet i local storage."
Det kan vara vad som helst. Jag tror jag skrev in Bellman vid något tillfälle.
Jo, men grejen är ju också att det räcker ju ofta att ha det så.
Jag har ju kört LaunchDarkly till exempel, finns det väl en populär som heter?
Och den funkar ju jättebra.
Men fördelen är väl just att då kan du feature toggla det för alla användare.
Eller en viss del av användarna och sådana saker.
Men annars tycker jag ofta att det funkar så här.
Så om man har något som man vill att teamet ska testa i produktion, så lägg det bakom en "local storage"-flagga.
Eller en "query-parameter" i VDL eller vad som helst.
Eller bygga ett system där du har en benämning på det som går helt emot "true" eller "false".
Och du har ingen aning om du togglar på eller av när du togglar.
Ja, så att den är "disable enable toggle false".
Om jag säger "Kill switch on" är den på eller är den av?
Är den avtaglad?
Ja, det är väldigt kul faktiskt.
Nej, den där vill man ju undvika.
Ja, men det är skitnice med feature toggle egentligen.
egentligen. Men sen så här, det är också någonting som känns jobbigt med, eller?
Det är inte jobbigt, vi hade en dag en diskussion om vi skulle feature-toggla eller använda en feature-bransch.
Jag tror vi landade i en feature-bransch, så att vi skapade en bransch som blev liksom som en main för den featuren bara,
och så utgår alla från den. Jag vet inte om det är bättre eller särare, alltså det var, det kändes som att jag satt för länge
Jag har länge också på ett projekt som var Greenfield, så jag glömde bort hur det är att jobba på en produkt som är live.
Där du har användare.
Ja.
Ja, det är en jävla lyx egentligen.
Du behöver inte bry dig om det funkar i Prod.
Det kanske är den smälliga lösningen på dina bekymmer om att det ska funka i Prod.
Om jag har några användare, då är det lugnt.
Precis, om någon bara anställer mig istället som har noll användare, så kör jag där.
Borde man inte vara på byrå då?
Jo, så är det väl. Typ lite så.
Men det gick ut på en gammal kund som jag var på, som byggde vid ett system som hade tre användare.
Som satt en våning upp från oss.
Det var också ganska skönt.
Gick någonting sönder så fick vi veta det direkt, för det var den som knackade på axeln.
Det var ju den nivån.
Och sen kände man ju de som använde det.
Så var det inte hela världen om något gick lite fel.
Men också, känner man att man skapar stort värde då?
Gör man det?
Ja, men systemet skapade väldigt, väldigt stort värde för de här tre personerna.
Och sen var ju tanken att det skulle bli många fler som skulle använda det så småningom.
I andra länder och på andra ställen.
Men just när det var tre som använde det.
Jag längtade lite grann efter en stor extern webb med en massa användare och kunder när jag gick därifrån.
Men det var väldigt kul ändå.
Ja, men gräset är alltid grönare, eller hur?
Så är det ju.
Ja, interna system. Vad kul det var med externa system.
Ja, tills Safari 8, typ.
Ja, så är det ju verkligen.
Sen är väl det lite fördelen med att vara konsult också, om vi ska sidospåra på det.
Allt man faktiskt kan byta.
Ja, nu är ju inte jag konsult då.
Nej, jag vet. Men jag är.
Så vi får se hur länge, tills du längtar efter ett internt system.
Ja, alltså, det kan jag inte säga.
Det skulle ju vara en lögn att säga att jag inte saknar konsultlivet lite grann.
Ja, men som sagt, gräset är alltid grannare på andra sidan.
Så är det. Men det sista jag tänkte på vad gäller produktionssättning och sånt, det är ju egentligen att ha någon typ av on-call.
Ja, just det.
För det är ju, och det har jag haft väldigt lite faktiskt.
Ja, jag med. Extremt lite.
Ja, för jag tror det har varit mycket så här på vissa ställen också, man vill ju inte betala en konsult för on-call om man inte behöver, för det kostar ju mer.
Ja, jag har haft, det enda gången jag har haft en on-call tror jag, eller kanske var någon annan gång förutom det, är ju på det här stället där vi hade tre releaser per år.
Och då var det liksom under release-dagen som allt var på en söndag.
Så då kunde man ha en on-call i typ tolv timmar från åtta till åtta eller något sånt där.
För det första så skulle man ju ofta vara med och releasa någonting, för som sagt det var tre gånger per år, så det fanns ju saker att releasa.
Men då åkte man in till kontoret på en söndag, satt där och så skulle man releasa.
Men sen gick det ofta jättefort för oss, för vi satt med webbgrejer.
Men sen var det affärssystem och kassasystem och hur mycket som helst som skulle releasas.
Då kunde man ha lite on-call i typ 12 timmar. Men det var ganska nice ändå.
Fan. Alltså, ja.
Det var väl betalt för en söndag.
Ja, det kan jag tycka.
Men jag har ju varit på ställen som har on-call, men jag har aldrig haft sån.
Nej, det är samma här.
Och det känns inte som att folk gillar det.
Jag skulle nog inte gilla att ha det heller.
Nej, jag tog faktiskt upp det idag också, att vi borde ha det.
Men det är inte för att jag vill ha det, men det är för att...
Vad fan gör man om saker sjunker då? Någon måste ju ta hand om det.
Du tog upp det för att du bryr dig om produkten.
"Jag bryr mig om Fredrik, jag bryr mig om..."
"Ja, ja, bla bla bla..."
Men alltså jag menar...
Eller så har jag bara för mycket plikt-känsla.
Men liksom för att vi ska ju hantera folks pengar typ.
- Ja.
Du drivs av ångest som vanligt.
- Ja.
- Det är ju upplägt för succé.
Du kommer ju att hitta det här med din on-call.
Man vill ju hellre veta att jag har en on-call än vem som helst kan ringa när som helst om någonting händer.
Det kan gå larm på mobilen som jag bara måste se om någon springer på.
Absolut, det håller jag verkligen med om.
Alltså hellre planerad on-call än någon typ av passiv.
Oklar om någon kommer ringa. Är det mig de ringer?
Ja, men det är jävla oklart hur jag skulle må i det där.
Det skulle vara "Okej, men kan jag lösa det här?"
Tänk om det är en databasgrej.
Kan jag ens läsa loggar?
Jag har fan svårt att hitta information när vi får sådana här jävla error i vår jävla slackkanal.
Men omkoll brukar ju ändå inte handla om att du är den som är på plats och ska lösa allt.
Utan det brukar ju mer vara "Du är första personen som tittar på det"
"och sen så hör du av dig till rätt personer som kan lösa det."
Eller?
Jo, jag tänker.
Det finns säkert alternativ när folk tycker att du ska läsa allt själv.
Men jag tror att det vanliga är att man har en förväntan på sig att titta på problemet, se vad M's ansvar är och sen höra av sig till någon.
Jag kommer ihåg när jag var junior, då ville de inte att vi skulle vara on-call för att de inte behövde bli uppringda när de inte hade on-call för att junioren inte klarade av att ha on-call.
Japp.
–Är det nåt olika? –Jo, men jag kan ju förstå det ur det perspektivet–
–att man sätter inte nån på en kol som inte ens kan förstå vad problemet är.
–Jag, när det gäller databasproblem? –Jo, men du kan ju se att det är ett problem.
–Eller? –Var inte så självnedvärderande nu.
Ja, men det är svårt. Det här med att jag tittar alltid i...
Jag tittade på någon sån jävla Down-detector-sida någon gång, och så trodde jag typ att AVS låg nere.
Men det var bara en jävla GIF som spelades på deras sida, och att den var nere.
Alltså, jag har liksom noll-källkritik i mig.
Det är ju för sig. Väldigt, väldigt on-brand på något sätt.
[Skratt]
Jag vet. Och så skrev Slackkanalen så här, två minuter senare, "Nej, vänta, det var en GIF."
[Skratt]
Ja, lätt hänt.
[Skratt]
Det får vara absolut avsluten till det här avsnittet.
Gud, jag kan inte prata längre. Det är för varmt här.
Ja, det är så jävla varmt. Alltså, förlåt.
Men tack för att ni lyssnade som vanligt.
Hör gärna av er om ni har någon feedback.
Jag tycker det är svinkul att höra att folk faktiskt lyssnar.
Eller om ni har några frågor. Eller avsnittsförslag.
Det är toppen.
Vi ska försöka vara lite stabilare nästa avsnitt. Förhoppningsvis är det inte lika fuktigt och varmt.
Exakt. Tack för att ni lyssnar. Ha det så bra. Bye bye.
Hej då!
[Outromusik]
