JAOO: Releaser du også 371 gange om måneden?

Advarsel: Vi befinder os i web-verdenen, hvor livet leves i overhalingsbanen, hvor kunderne forventer og som minimum accepterer, at funktionaliteten ændrer sig med kort varsel. Det er også en verden, hvor den samme virksomhed laver både applikationsudviklingen og har det operationelle ansvar for at holde den i luften - enten fordi man driver en web-forretning eller leverer software as a service, hvad der også er flere og flere af os, der vil komme ud for, jævnfør mit seneste blogindlæg.

John Allspaw, der lige nu er VP of Operations hos online-markedspladsen Etsy og tidligere har været operationel chef hos Flickr, holdt tirsdag formiddag et spændende foredrag om at styrke samarbejdet mellem dev (=development) og ops (=operations) i et miljø, hvor man ikke blot laver continuous integration men også continuous deployment, der i øvrigt har været et gennemgående tema i flere af foredragene ved JAOO (nu goto;) i år.

I stedet for, at udviklerne kaster de færdige produkter over hegnet til operations, som i mange tilfælde ikke har andre muligheder i tilfælde af fejl end at rulle tilbage (og håbe på, at dette er muligt), er den radikale forandring nu, at det er udviklerne selv, der deployer - normalt
umiddelbart efter, at de har committet deres ændringer.

Ofte vil ændringerne dog først blive rullet ud, så de virker for Etsys egne ansatte, og derefter for et mindre andel af brugerne, inden de endeligt bliver tilgængelige for alle. Det skal også nævnes, at de ændringer, vi taler om her, normalt kun er front-end ændringer i PHP-koden. Skal der rulles helt nye features på, ændres i database-schema'er eller lignende, er der stadig en mere
omfattende proces for dette.

Men en af pointerne er, at mange ændringer er relativt simple og ligeså godt kan komme ud og tjene penge med det samme. Og skulle der ske fejl i forbindelse med udrulningen, er det betydeligt nemmere for en udvikler at rette fejlen kort tid efter, at han har lavet ændringen, end flere måneder senere, når man måtte lave en "stor" udrulning. I øvrigt fortalte John Allspaw, at den gennemsnitlige tid for at opdage, at der er sket en fejl, er i størrelsesordenen 6 minutter, og den tid, det tager at rette den, er ca. tilsvarende. Selve det at deploye et stykke kode tager mindre end et minut - men det er DIG, som udvikler, der trykker på knappen, som også har ansvaret for, at det faktisk virker. Og det er nok i grunden en ganske sund tankegang!

Interesserede kan naturligvis læse videre i John Allspaws egen bog: "Web Operations" fra O'Reilly.

Kommentarer (2)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Nikolaj Brinch Jørgensen

På netop overståede JavaOne, så jeg eBays chef arkitekt fortælle om noget lignende, hvor han fortalte om hvar mange gange om ugen de releaser features (2-cifret antal). De havde en koplet løsning hvor de også samtidigt kunne rulle tilbage, så man kan sige håndtaget kører begge veje. Det interessante var, at deres produktionsmiljø består af 5.000+ servere, og dermed kan de ikke dynamisk udrulle alt på en gang, og det gøres derfor løbende, så systemet samtidigt faktisk kører 2 version af softwaren (f.eks. noget kører version 71 og noget version 72). Dette sker helt ned på schema niveau i databaserne.

For mere information kan man nok støve noget af dette op hos eBay. Iøvrigt var indlægget meget interessant, da det var 10 råd om hvordan man bygger massivt skalerbare applikationer. F.eks. få nu de distribuerede transaktioner ud - altså eventual consistency og den slags. At de også har søgning vha. inverted index, men at de normale produkter (OSS/Proprietary) ikke kan bruges så de har lavet deres eget som er fuldt distribueret in memory med lock free updates - det er vældig interessant.

Nå nok om det, bare en teaser, hvis folk er interesseret i at hører mere om hvordan de rigide deployment scenarier vi alle idag kender, kan gøre bedre, og nogen har gjort det, så det er ikke kun på papir.

Ha' en god dag.

  • 0
  • 0
#2 Anders Poulsen

Og jeg som troede at vi bare gjorde sådan fordi vores afdeling er for lille og "cowboy"-kode-agtig til at opføre os mere professionelt. Så er vi i virkeligheden helt med på beatet med "continuous deployment"? Den må jeg huske!

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