Hjelp, vi må prodsette!

Jørgen Wahlbergutviklingsleder,

A-pressen Digitale Medier

A-pressen Digitale Medier

• 65 nettaviserbl.a. RB.no, BA.no, Nordlys.no, AN.noselve nettavisene, fotball-live, skattelistene, rubrikkannonser, etc.

• Norges femte største nettaktørca. 350 000 unike brukere pr dagca. 1,2 millioner lesere i uken

• Zett.no, Derdubor.no, Mediehuset Digital, Nettsamfunnet Origo

• A-pressen eier ogsåhalve Nettavisenhalve TV2

Om oss

• Ca. 15 utviklere• Ca. 60 linux-servere• Drift satt ut til Linpro• Stort sett Java• Noe PHP• Varnish• MySQL• PostgreSQL• Escenic• FAST ESP

Produksjonssetting

• Endring medfører risiko for at noe går galt• Endring er nødvendig og det vi går på jobb for• Endring er like viktig som stabilitet

• Må balanseres mot hverandre

Hva har vi gjort for å redusere risikoen for feil ved utrullinger?• Automatisering• Kommunikasjon• Utviklingsfilosofi• Samarbeid utvikling/drift

Munin og Nagios

• Nagios viser status på systemene

og varsler når noe er galt

• Munin grafer utvikling for forskjellige parametre over tid

slik at vi kan se om endringer førte til uventet oppførsel

Dedikerte driftere

• Drift av tjenestene håndteres av Redpill Linpro• En person jobber fast med vår rigg• Slipper å forholde oss til nye ansikter for hver

henvendelse

Tett kommunikasjon mellom drift og utvikling

• Ticketsystem• Mail• Møter• Videokonferanse• IRC

Ikke bare menneskene kommuniserer på IRC • På kanalen er det en

bruker som heter “bot”• Bot er et program, ikke

et menneske• Bot forteller hva som

skjer med serverne:oppdateringerfeilmeldinger

http://www.flickr.com/photos/frogdna/3605073173/

Versjonskontroll

• Vi bruker Subversion som versjonskontrollsystem• For kildekode og konfigurasjon• Brukes av både utvikling og drift

• Alle vet hvor de skal se

Gjøre utviklings- og produksjonsmiljøer like• Jetty som

applikasjonsserver• Byttet fra Oracle til

MySQL• Samme oppsett

(porter, prefiks, osv.)• Feil i produksjon kan

stort sett reproduseres lokalt i utviklingsmiljøet

http://www.flickr.com/photos/8364507@N06/4048424056/

Kontinuerlig bygging

• Enhetstester• Integrasjonstester• Cruise Control• Reduserer risikoen for

at endringer fører til at noe brekker

• Muliggjør refaktorering

ADAM-A

Keep it simple

• Enkle tjenester• Spesialiserte• Heller flere enkle enn

færre kompliserte tjenester

• Kommunikasjon mellom tjenestene med HTTP

Enkelt å feilsøkeEnkelt å cache

http://www.flickr.com/photos/baileyfamily/2039427760/

Keep it simple (forts.)

• Koden vår er bygget på ryggen av hundrevis av biblioteker

eksempler: spring, hibernate, lucene, xstream, jawr, saxon, jqueryalle unntatt ett er åpen kildekode

• Så få avhengigheter som mulig• Hold egne og eksterne biblioteker oppdatert• Bruke biblioteker som gjør få ting, men gjør dem

bra

Puppet

• Verktøy for automatisk oppdatering av servere

• “Puppet-master”, en maskin, holder konfigurasjonen

• Sikrer at servere (“puppets”) blir oppdatert iht. reglene

• Endringer spores av Subversion

http://www.flickr.com/photos/eugene/18142113/

Test-, stage og snapshot-servere

• Kombinasjonen av kontinuerlig bygging...• ... og automatisert oppdatering av servere ...• ... gir oss en (nesten) kontinuerlig oppdatert server

som viser hva som er utviklet til nå.• Oppdateres flere ganger om dagen.

• Test- og stage-servere oppdateres også enkelt.

Tilgang til serverne

• Alle utviklerne har login men ikke fulle admin-rettigheter

• Både utviklere og driftere kan sette ny kode i produksjon

• Endringer kan spores, så drifterne har fortsatt kontroll over maskinen

http://www.flickr.com/photos/penguincakes/2826996407/

Driftsvennlig kode

• Status-sider som forteller om tjenestene har det bra

for f.eks. lastbalanserereog for mennesker

• Knapper, spaker og kontroller slik at man kan endre oppførselen til systemene i fart

http://www.flickr.com/photos/stephangeyer/

Eksempler: status og konsoll

Utviklerne er ansvarlige for koden også etter at den er i prod

• Man får problemene i fanget hvis det ikke fungerer som det skal

• Gjelder både ved ytelsesproblemer og ved funksjonelle feil

Alt som rulles ut er ikke nødvendigvis synlig med en gang • Skille lansering av ny funksjonalitet fra utrulling av

ny kode• Konfigurerbar oppførsel i koden

av/pågammel/ny

• Skru på ny funksjonalitet etter hvert, f.eks. på en avis først.

Dyktige medarbeidere

• Utviklere og driftsfolk som respekterer og stoler på hverandre

• ... og skjønner hverandres arbeidsoppgaver...• ... og som prater sammen om hva som fungerer og

ikke fungerer.

Ikke rulle ut på fredager

Suksessfaktorer

• IRC og bot• Likt oppsett i utvikling og produksjon• Hold kode og oppsett så enkelt som mulig• Kontinuerlig bygging• Enkel oppdatering av servere• Hyppig utrulling

Hva har åpen kildekode gitt oss?

• Fleksibilitetkan velge hvor og hvordan programmer skal kjørekan bytte ut biter som ikke virkermulighet til å sette opp så mange testmiljøer vi vil

• Trygghetkan bytte ut biter som ikke virkerkan fikse det som ikke fungerer bra nokkan selv velge hvor vi skal sette inn ressurser hvis noe ikke virker

• Skaleringikke bundet av lisenser som begrenser antall cpu-er eller maskinerfrihet til å sette sammen løsninger slik at de skalerer slik vi vil.

Mer informasjon

• http://www.linux.org/• http://java.sun.com/• http://php.net/• http://varnish-cache.org/• http://dev.mysql.com/• http://www.postgresql.org/• http://munin-monitoring.org/• http://www.nagios.org/• http://www.redpill-linpro.no/

• http://en.wikipedia.org/wiki/Internet_Relay_Chat

• http://www.mirc.com/ircintro.html• http://www.tandberg.com/• http://subversion.apache.org/• http://jetty.codehaus.org/jetty/• http://cruisecontrol.sourceforge.net/• http://blogg.api.no/-/bulletin/show/

557849_attention-all-personnel• http://www.puppetlabs.com/• http://www.erdetfredag.no/

jw@apdm.no@jorgenwahlberg

http://www.apdm.no/http://blogg.api.no/@apressen_apdm