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