Continuous Delivery Hva Hvordan Hvorfor
Oct 28, 2014
ContinuousDelivery
HvaHvordanHvorfor
Hvor lang tid tar det deg å deploye én endret kodelinje
til produksjon?
Og gjør du det regelmessig?
Hovedpoenger
Finne bugs tidlig/tidlig feedback
Trygghet og tillit til prosess og metode
Realisere verdi tidlig og ofte
Alltid releasebar software
Reproduserbare builds
Oversikt for alle involverte
Automatisert og ikke utsatt for
menneskelige feil
Configuration management
CI
Sjekk inn ofte (mange ganger daglig) god test coverageAldri sjekk inn broken build, kjør commit testerVent på commit tests på CI før du går videre på nytt arbeid
Vær alltid klar for å revertere Vurder: brekk bygget for arkitektur-feil, langsomme tester, checkstyle / findbugs / PMD etc DVCS: CI-build for alle repos eller bruke et repo som master som alle pusher til.
Testing
MålBygge kvalitet inn istedenfor
å inspisere i etterkant (Deming)
Automatiserte tester: unit, component (integration),
acceptance) (ATDD/TDD/BDD)
INVEST-prinsippet: Stories skal være, Independent,
Negotiable, Valuable, Estimable, Small and
Testable
Deploymentpipeline
end-to-end, ikke bare
development
Practices
Kompiler en gang, bruk flere ganger Deploy på samme måte til alle miljøer og deploy samme binærer Smoketest etter deployment (automatisert) Alle endringer skal gjennom pipeline med en gang Dersom ett sted feiler, stop the line
Commit stage
Compile og bygg binærer Unit tests Kodeanalyse (pmd, dependencies, coverage, complexity, style etc) Forberede databaser etc. for senere steg
Acceptance Reellt miljø Hele teamet må eie akseptanse-tester kost/nytte tradeoff for funksjonelle automatiserte tester Funksjonelle og ikke-funk.
Manuelle tester
Deploy automatisk til test-miljø Deploye i serie, slik at man ikke deployer til miljø "høyere opp" i rangeringen før lave er ok
Modeller verdistrømmen og lag skjelett Automatisér build og deployment Automatisér unit tester og kode-analyse Automatisér akseptansetester Automatisér releaser
Automatiserte akseptansetester
Hold deg unna GUI, gå mot public API Evt. Lag abstraksjonslag mellom GUI og kode
som brukes av tester
Scripting av build og deploy
Tips & triks Relative pather i alle script Eliminer manuelle steg Legg inn traceability fra versjonskontroll til
binær Ikke la test-steg feile builden, fortsett og feil til
slutt om noe feilet underveis
Release/Deploy
Deploy i første iterasjon Porter mellom hvert steg i DP som promoterer build (med alt!) og spesifikke brukere som kan deploye til hvilke Automatisert rollback (må testes) Logg av deployment-steg Involver drift Fail fast
Infrastruktur og env Nært samarbeid med drift og/eller devops-avdeling Om mulig sjekke på forhånd hvor lett tech kan
automatiseres Sjekk ut deployment-metoder før man skal i prod Automatiser miljø (kickstart/jumpstart ect), også konfig
(cfengine/puppet/chef) Begrens tilgang mest mulig (automatiserte prosesser
skal gjøre endringer)
ticket system/log på endringer av miljø. Automatisert deploy og automatisert test etterpå
Automatisert provisioning av servere
Spørsmål: hvor lang tid vil det ta å sette opp prod etter en katastrofal hw-krasj?
virtualisering med templates etc
Overvåking av applikasjoner, OS, infrastruktur og mellomvare
Logging og SNMP-traps
Lag dashboards
Komponenter og avhengigheter
Del opp i komponenter før det er for sent/dyrt Hold koden releaseable
Gjem ny funksjonalitet branch by abstraction (ikke svc-branches)
Avhengigheter Maven: spesifiser versjoner av alt sjekk inn dersom man ikke bruker verktøy for deps
Avansert versjonskontroll Utvikle mot main/master Branch for release Branch by feature Branch by team
Antipatterns