Tør jeg følge moden?

Jeg har det lidt med hypede teknologier som jeg har det med tøjmode. Oftest trækker jeg bare på skuldrene af hvilken farve der tilsyneladende er årets farve og nogle gange er der trends der overlapper med hvad jeg normalt finder rart og praktisk.

Mens den folkelige mode aldrig ligefrem har givet mig kuldegysninger, så er der en IT-mode på de seneste par konferencer som får hårene til at rejser sig i nakken på mig: Continuous Deployment. Programmet for GOTO-konferencen tyder ikke på en undtagelse. Der er afsat et heldagsspor i den store sal til emnet.

Egentlig er jeg tiltrukket af ideen med små hurtige og overskuelige opdateringer. Jeg kan i hvert fald nikke genkendende til oplevelsen af at bruge op mod 20% af min arbejdsuge på at gennemskue om ugens batch af opdateringer samlet set vil give problemer og hvad der skal tages særligt varsomt på.

Men alligevel er der noget af mig der vrider sig over ideen. Som udvikler frygter jeg at tage ansvaret, som release manager frygter jeg at miste kontrollen, som projektkoordinator frygter jeg om de andre teams er gode nok og endelig er min indre system administrator et konservativt røvhul der gerne vil have 100% kontrol over produktionsmiljøet.

Jeg ser i hvert fald frem til at blive klogere.

Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Martin Juhl Jørgensen

Hvordan har du det så med Chrome browseren[1]? Personligt er jeg ret glad for Googles håndtering af opdateringerne på deres forskellige platforme, men nu har jeg dog heller ikke leget udvikler på dem. Som IT-admin over 1 stks PC derhjemme er jeg glad for at der i det mindste er en mindre opdatering jeg skal bekymre mig om.

[1] http://www.codinghorror.com/blog/2011/05/the-infinite-version.html

  • 0
  • 0
#4 Klavs Klavsen

og følsomheden overfor "småproblemer" med heraf følgende ekstra releases, eller tilbagerulning.

Uanset, så er det min erfaring at der ALTID bør være en systemadministrator-type der har sikret sig at en tilbagerulningsplan forefindes (og checke om evt. kodeopdatering skulle ændre i databasen, således at foregående version ikke længere vil virke - uden at man laver en DB restore).

Afhængig af den øvrige forretnings følsomhed overfor "nedetid/siteproblemer" (f.ex. hvis det kan resultere i mange supportopkald osv.) og evt. bureaukrati/efterspil sådan noget kan give - så må man justere derefter, og f.ex. sørge for at der er et "papertrail" mht. hvem der godkendte hver release i de forskellige afdelinger der nu skal det.

Det er også noget jeg oplever ønsker om - og indtil jeg sørger for at få ansvaret afklaret og at der som minimum er en garanteret måde at rulle tilbage på.

Hvis man én gang har prøvet at et site går ned pga. ny kode, der trigger en fejl i en foranliggende cache f.ex. - så den går ned og selvf. med en forsinkelse der gør man ikke kan være sikker på at det var den nye kode.. så lærer man (eller i mit tilfælde bliver bekræftet i) at en fejlfindingsmulighed man SKAL have - er at kunne rulle tilbage :)

Så med continuous release, kommer continous rollback :)

  • 3
  • 0
#5 Ivan Skytte Jørgensen

Hvis man antager at de ændringer, som man foretager i softwaren, ikke introducerer nye fejl, så er continuous deployment det eneste som giver mening.

Men tilbage i den virkelige verden:

Hvis: - man kan forvente at opnå god dækning med egne tests, og - man kan forvente at brugerne giver hurtig feedback, og - det er nemt at rulle tilbage, og - man kan blive tilgivet når det går galt så kan continuous deployment virke. Jeg har brugt det på mit tidligere job, omend kun på mindre ændringer. Det giver god mening til ikke-kritiske systemer under ny-udvikling.

På mit nuværende job vil det ikke virke, fordi ovenstående ikke er opfyldt. Derudover har de fleste kunder deres egen testafdeling, som aldrig ville acceptere det, fordi konsekvensen ved en fejl kan være ret alvorlig.

  • 0
  • 0
#6 Peter Makholm Blogger

Det er også noget jeg oplever ønsker om - og indtil jeg sørger for at få ansvaret afklaret og at der som minimum er en garanteret måde at rulle tilbage på.

Tror du at du vil få et større behov for at kunne rulle tilbage ved at lave mange flere men tilsvarende meget mindre releases?

I min erfaring er der tre situationer: 1) Ændringer der trivielt kan rulles tilbage ved bare at føre koden tilbage, 2) Ændringer det lettest "rulles tilbage" ved at tilføje (atter) en workaround og 3) Ændringer der kræver restore af data.

I min erfaring er type 1 det langt mest normale og jo mindre releases man har, jo lettere er de at rulle tilbage. Type 2 bliver oftest håndteret ved en panik-agtig ad hoc-release der omgå alle faste procedurer; ved at stile efter continuous deployment så er der ikke behov for at omgå de sædvanlige procedurer, release processen er allerede fuldt ud optimeret.

Tilbage er der så type 3 som er meget alvorlige uanset hvilken deployment-process man arbejder efter. Kikker jeg tilbage i historikken for mit nuværende projekt tror jeg ikke at continuous deployment ville have ændret risikoen det store. Enten skriger ændringerne til himlen, således at de i forvejen er blevet ordentlig reviewet før de er tilføjet vores master-branch eller også har de været så obskure at vi alligevel har haft koden i produktion i lang tid før problemerne har hobet sig op og vist et klart mønster.

Det er selvfølgelig en forudsætning at man rent praktisk kan foretage en deployment uden et par minutters nedetid. Men ellers mener jeg ikke at der er nogen af dine pointer der specielt relaterer sig til continuous deployment.

Det er mere et spørgsmål om at man skal være bevidst om sin deployment-procedure. Og med den vinkel tror jeg at alt er bedre end monolitiske store deployments, fordi det var sådan man skrev rapporter på universitetet.

  • 0
  • 0
#7 Peter Makholm Blogger

På mit nuværende job vil det ikke virke, fordi ovenstående ikke er opfyldt. Derudover har de fleste kunder deres egen testafdeling, som aldrig ville acceptere det, fordi konsekvensen ved en fejl kan være ret alvorlig.

Deployment skal selvfølgelig i alle tilfælde ske i fuld forståelse med den endelige systemejer.

Det hører med til historien at jeg er in-house udvikler og de fleste jeg tidligere har snakket med om emnet ligeledes har været organisationer med egne udviklingsafdelinger.

Det er muligvis også derfor jeg foretrækker termen "Continuous Deployment" frem for "Continuous Delivery". For mig ophører mit ansvarsområde sig tidligst efter deployment, mens der ved en ekstern kunde ofte er en egentlig aflevering forinden hvor udviklerens ansvarsområde ophører.

  • 0
  • 0
Log ind eller Opret konto for at kommentere