DevOoops!
Till vänster är den en grupp människor som kallas för ”dev”. Till höger är det en annan grupp människor som kallas för ”ops”. I mitten av bilden är det en hög mur. Har du också sett en sådan PowerPoint? I så fall har du också varit på en presentation om DevOps. Nyligen har jag haft några intressanta upplevelser i mitt projekt:
Jag pushar en ny modul. En kollega berättar vid fikat att hen såg en ny modul och installerade, konfigurerade och startade den i en testmiljö. Hen undrade bara vad den gjorde.
Jag modifierade en modul så att det blev mera kräsen rörande konfigurationen, som dessutom hade ändrats lite. Tyvärr så råkade System.exit(1) hamna före logger.fatal(”Incorrect configuration…”). Tjänsten avslutade utan att lämna minsta spår av vad som hade hänt.
Ooops! Gemensamt för dessa små incidenter är att vi gjorde en överlämning inom projektet. Jag och kollegan har bra kommunikation, ett lågt staket och inte en hög mur, och löste problemen på några minuter.
När jag har funderat mer på detta så har jag kommit fram till att låga staket - överlämningar inom ett projekt - är bra. Första fallet lär mig att all kod som jag pushar måste vara av så hög kvalitet att den går att installera utan att skada systemet. (Den behöver dock inte göra någon egentlig nytta.) I det andra fallet hade jag aldrig missat den förändrade konfigurationen om jag hade installerat själv och buggen hade aldrig hittats. Små överlämningar inom projektet höjer alltså kvaliteten på leveransen!
Att tillåta att DevOps ibland blir DevOoops! tror jag är ett effektivt och ekonomiskt fördelaktigt sätt att höja kvaliteten jämfört med både par-programmering och kod-granskning. Den lilla överlämningen inom teamet simulerar verkligheten på ett bra sätt och det kan vi dra nytta av.