Continuous Delivery
•Download as PPT, PDF•
0 likes•477 views
Overview of the field of Contiuous Delivery (in Norwegian)
More Related Content
Similar to Continuous Delivery
Similar to Continuous Delivery (20)
Continuous Delivery
- 1. Continuous Delivery Hva Hvordan Hvorfor
- 2. Hvor lang tid tar det deg å deploye én endret kodelinje til produksjon? Og gjør du det regelmessig?
- 3. Hovedpoenger
- 4. Finne bugs tidlig/tidlig feedback
- 5. Trygghet og tillit til prosess og metode
- 6. Realisere verdi tidlig og ofte
- 9. Oversikt for alle involverte
- 10. Automatisert og ikke utsatt for menneskelige feil
- 12. CI
- 15. Testing
- 16. Mål Bygge kvalitet inn istedenfor å inspisere i etterkant (Deming)
- 17. Automatiserte tester: unit, component (integration), acceptance) (ATDD/TDD/BDD)
- 18. INVEST-prinsippet: Stories skal være, Independent, Negotiable, Valuable, Estimable, Small and Testable
- 20. end-to-end, ikke bare development
- 21. Practices
- 28. Scripting av build og deploy
- 30. Release/ Deploy
- 36. Antipatterns
Editor's Notes
- 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.