• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Continuous Delivery
 

Continuous Delivery

on

  • 1,124 views

Overview of the field of Contiuous Delivery (in Norwegian)

Overview of the field of Contiuous Delivery (in Norwegian)

Statistics

Views

Total Views
1,124
Views on SlideShare
1,123
Embed Views
1

Actions

Likes
0
Downloads
8
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Tar utgangspunktet i boka med samme navn av Jez Humble og David Farley. Inneholder mange ting som mange av oss gjør i dag, men også en del nytt og kombinasjonen er nok ny. Og hvor langt man trekker det.
  • Dette er hovedspørsmålet man bør stille seg. Det har betydning for det hvor fort du kan levere verdi til brukerne.
  • Feedback er det sentrale. Feedback på mange forskjellige nivåer og til forskjellige deler av organisasjonen.
  • Deployment skal ikke være stressende og preget av nervøsitet, det skal være dagligdags.
  • From concept to cash. Tiden må være kort.
  • Gjenskape en tidligere release med alt som er involvert, inkludert miljø, avhengigheter etc.
  • Transparens i organisjonen. Informasjon til de som trenger det, når de trenger det.
  • Robust og sikkert. Så hvordan gjør vi dette?
  • Alt skal sjekkes inn! Ta vare på konfig for absolutt alt i versjonskontroll. OS-pakker, patching av infrastruktur, dns-oppsett, firewall-config, databasescripts, bibliotek, versjoner. Kort sagt alt. Målet er å kunne gjenopprette en bestemt versjon med miljø med automatisert prosess. Gode commit-meldinger Hold kontroll på external dependencies og biblioteker
  • CI er basis for CD.
  • Om commit stage feiler, fiks den umiddelbart.
  • Vær streng.. Hvor streng avhenger av kontekst.
  • Teststrategi * Start på starten av prosjektet, bare noen iterasjoner ut øker kostnaden fort. * Business med på test-strategi * Midtveis i prosjekt: Identifiser high value og viktigste use cases og lag happy path akseptansetester for dem (regresjon) * Legacy: Skaff automatiserte tester rundt kode du skal endre på og litt av samme som forrige punkt * Legacy: Validering av state for applikasjon etter testrun (for å fange opp ripple effect i andre deler av system * Teknikker for robust integrasjonstesting: o Simulere nettverksfeil av ulik art (nekte connection, opprette conenction og droppe, ekstremt lang svartid, svare med tulledata, Sende exceptions, * Testere kan pulle en release til testmiljø fra vcs/ci
  • Egenskaper ved automatiserte akseptansetester o Raskere feedback loop for utviklere o mindre manuell jobb for testere og frigjør tid til exploratory testing o regresjon o Kan være dyre å vedlikeholde o Treffe gui? Helst ikke.
  • # Prosessen blir transparent og tryggere # Release er hverdagslig og ikke skummelt. # Eliminer waste # Mål er å få tidlig feedback og luke ut builds som ikke kan prodsettes så tidlig som mulig
  • * Separate kompileringer kan introdusere endringer og krever konfigurasjonsstyring av kompilere på flere steg. Tar også ekstra tid *separasjon mellom kode og konfig (ear/war er dårlige her, siden de pakker alt inn) * Smoketest etter deployment (automatisert) * Deploy til en kopi av prod (så lik som overhodet mulig) * alle endringer skal gjennom pipeline med en gang (alle commit trigger pipeline (hvor pipeline ender er en annen sak) * Dersom ett sted feiler, stop the line (fra lean)
  • Fremgangsmåte for å lage en deployment pipeline
  • * Mavens bruk av plugins gjør at du ikke kan reprodusere builds (ut av boksen i alle fall) * rake og buildr er bedre valg for java når man skal automatisere og ha full track på builds? * Lag ett skript for hvert steg i pipeline * Bruk native tools for deployment, ikke rå scripting dersom mulig. Script heller bruken av verktøyet (wsadmin for websphere f.eks) * involver alle som skal deploye i design av deployment-metode * OS-pakker der det er mulig * deploy alt fra scratch, ikke inkrementelt (unntak: clustre og komonenter fra ulike kildekodetrær) * Utvikle deployment-systemet over tid, ikke big bang * Test konfigurasjonen av et miljø
  • # Blue-green deployment * To sett av prodmiljø * brukere er på blå, deploy til grønn, switch over i router # Canary releasing * Deploye til ekstra miljø eller deler av miljø som ikke er i bruk * rute brukere over for å avdekke problemer * vanskelig med databaseoppgraderinger/migreringer
  • Branch by abstraction:Lag et abstraksjonslag over den delen som skal endres. Endre/lag ny funksjonalitet og ta vekk gammel versjon/abstraksjonslag når ferdig.
  • Forskjellige kontekster har forskjellige behov og løsninger. De er forskjellige, men ikke nødvendigvis bedre eller dårligere enn andre.
  • * manuelle steg i release-prosess * manuell konfigurasjon i produksjon * Ventetid i prosess-steg * Detaljert doc på release-steg * Hyppige endringer på release-prosess under release * Dagen-derpå releaser * Uforutsigbart utfall av releaser * Lite tillit til releasing. * Deploy til prod (eller prod-like) først når man er ferdig.

Continuous Delivery Continuous Delivery Presentation Transcript

  • Continuous Delivery Hva Hvordan Hvorfor
  • 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 coverage
    • Aldri sjekk inn broken build, kjør commit tester
    • Vent 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ål Bygge 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
  • Deployment pipeline
  • 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
    • Hold deg unna GUI, gå mot public API
    • Evt. Lag abstraksjonslag mellom GUI og kode som brukes av tester
    Automatiserte akseptansetester
  • 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