1. Hjelp, vi må prodsette!
Jørgen Wahlberg
utviklingsleder,
A-pressen Digitale Medier

2. A-pressen Digitale Medier
• 65 nettaviser
bl.a. RB.no, BA.no, Nordlys.no, AN.no
selve nettavisene, fotball-live, skattelistene, rubrikkannonser, etc.
• Norges femte største nettaktør
ca. 350 000 unike brukere pr dag
ca. 1,2 millioner lesere i uken
• Zett.no, Derdubor.no, Mediehuset Digital,
Nettsamfunnet Origo
• A-pressen eier også
halve Nettavisen
halve TV2

3. 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

4. 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

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

6. 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

7. 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

8. Tett kommunikasjon mellom drift og
utvikling
• Ticketsystem
• Mail
• Møter
• Videokonferanse
• IRC

9. 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:
oppdateringer
feilmeldinger
http://www.flickr.com/photos/frogdna/3605073173/

10. Versjonskontroll
• Vi bruker Subversion som versjonskontrollsystem
• For kildekode og konfigurasjon
• Brukes av både utvikling og drift
• Alle vet hvor de skal se

11. Gjøre utviklings- og
produksjonsmiljøer like
• Jetty som http://www.flickr.com/photos/8364507@N06/4048424056/
applikasjonsserver
• Byttet fra Oracle til
MySQL
• Samme oppsett
(porter, prefiks, osv.)
• Feil i produksjon kan
stort sett
reproduseres lokalt i
utviklingsmiljøet

12. Kontinuerlig bygging
• Enhetstester
• Integrasjonstester
• Cruise Control
• Reduserer risikoen for
at endringer fører til at
noe brekker
• Muliggjør refaktorering

13. ADAM-A

14. Keep it simple
• Enkle tjenester
• Spesialiserte
• Heller flere enkle enn
færre kompliserte
tjenester
• Kommunikasjon
mellom tjenestene
med HTTP
Enkelt å feilsøke
Enkelt å cache
http://www.flickr.com/photos/baileyfamily/2039427760/

15. Keep it simple (forts.)
• Koden vår er bygget på ryggen av hundrevis av
biblioteker
eksempler: spring, hibernate, lucene, xstream, jawr, saxon, jquery
alle 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

16. 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/

17. 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.

18. 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/

19. Driftsvennlig kode
• Status-sider som
forteller om tjenestene
har det bra
for f.eks. lastbalanserere
og for mennesker
• Knapper, spaker og
kontroller slik at man
kan endre oppførselen
til systemene i fart
http://www.flickr.com/photos/stephangeyer/

20. Eksempler: status og konsoll

21. 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

22. 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.

23. 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.

24. Ikke rulle ut på fredager

25. 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

26. Hva har åpen kildekode gitt oss?
• Fleksibilitet
kan velge hvor og hvordan programmer skal kjøre
kan bytte ut biter som ikke virker
mulighet til å sette opp så mange testmiljøer vi vil
• Trygghet
kan bytte ut biter som ikke virker
kan fikse det som ikke fungerer bra nok
kan selv velge hvor vi skal sette inn ressurser hvis noe ikke virker
• Skalering
ikke bundet av lisenser som begrenser antall cpu-er eller maskiner
frihet til å sette sammen løsninger slik at de skalerer slik vi vil.

27. Mer informasjon
• http://www.linux.org/ • http://en.wikipedia.org/wiki/
• http://java.sun.com/ Internet_Relay_Chat
• http://php.net/ • http://www.mirc.com/ircintro.html
• http://varnish-cache.org/ • http://www.tandberg.com/
• http://dev.mysql.com/ • http://subversion.apache.org/
• http://www.postgresql.org/ • http://jetty.codehaus.org/jetty/
• http://munin-monitoring.org/ • http://cruisecontrol.sourceforge.net/
• http://www.nagios.org/ • http://blogg.api.no/-/bulletin/show/
557849_attention-all-personnel
• http://www.redpill-linpro.no/
• http://www.puppetlabs.com/
• http://www.erdetfredag.no/

28. jw@apdm.no
@jorgenwahlberg
http://www.apdm.no/
http://blogg.api.no/
@apressen_apdm