Deliver software fast. Release features elke twee weken naar productie door een continue stroom automatisch geteste user stories. Die met een drukknop live kunnen. In deze presentatie deel ik mijn ervaringen en de toegepaste inrichting.

1. Continuous Delivery
Deliver software fast
Elke twee weken naar
productie
Léon Tebbens
met Jenkins, Gradle, Twist en Puppet

2. Wat is Continuous Delivery
https://www.youtube.com/watch?v=SIaVsG7m8n4

3. Resultaat Continuous Delivery
Een continue stroom van
geteste user stories.
Die met knopdruk live
kunnen

4. Wat is Continuous Delivery
Automatiseer al het werk na
schrijven van de code:
Builds
Testen
Deployment (ook naar productie)
En maak het supersnel

5. Wat is Continuous Delivery
1.Developer checks-in code
wijziging
2.Automatische tests voor
codekwaliteit en integratie
3.Software wordt automatisch op
server gezet
4.Automatische user story tests
5.Bij fout -> email naar developer
en naar stap 1
6.Software live zetten (knopdruk)

6. Jenkins
Continuous Delivery met Jenkins
Check Out
Unit
tests
code
kwaliteit
Packag
e
Deploy
Twist &
Seleniu
m Grid
FAT
Chrome
browser
Puppe
t
Webserve
r
SVN /
Git
Artifactory
repo
kwaliteit
Developer
Commit

7. Continuous Delivery met Jenkins
Demo

8. Continuous Delivery Tooling
Subversion/Git: codebeheer
Gradle: builds
Jenkins: CD-pipelineserver
Puppet: provisioning & roll-out
Twist: testscenario's
Selenium: testcode
Chrome: browser
OpenVAS: security tests (toekomst)

9. Waarom willen we dit?

10. Wanneer testen?

11. Wanneer testen?
Testen na livegang zoals Dilbert: nope
Testen aan eind van project?:
Groot risico op uitloop of livegang met veel
restpunten (onvoltooid werk), dus ontevreden
business
Het meest efficiënt is testen tijdens de ontwikkeling,
je hebt dan directe feedback

12. Dit geldt ook voor integratietesten en ketentesten!

13. Flow = efficiënt
Software maken is complex, lukt alleen in stukjes (user stories)
"Must fit in my head": als developer kan ik 1 story per keer
helemaal in mijn hoofd hebben.
Story afronden, direct testen (laptop, testomgeving, continu),
en dus directe feedback zorgt voor flow
Flow is hét Lean principe! Naast built quality in, first time right

14. CD is must voor Scrum
Scrumteams: iedereen is developer
Geen full-time testers, testen doet het team
Elke twee weken een release(kandidaat)
Automatiseren is een must:
- builds
- unit & integratietests
- user scenario tests
- regressietests

15. Changes na livegang
Change-release Geen CD Met CD
Development 8 dagen 10 dagen
Integreren 1 week Continu
Testen & rework 2 weken 2 dagen
Time-to-market: 5 weken 2 weken + 2 dgn
Ervaringscijfers Alliander webteam

16. Wrap up: waarom CD?
• Must voor Scrum projecten
• Geen "waste" na livegang
• Voorspelbaar opleveren
• DevOps
• Best practise in de wereld, bv ING-bank
• Elke twee weken werkende software in productie!

17. Appendix: Testen bouwen
Omdenken: testen maken is een teameffort
• Test-scenario: bedenkt de tester (TMap)
• Testcode om browser mee te sturen: schrijft een
ontwikkelaar
• Dit is een best practise die werkt!
• Geloof niet in record&play tooling, die breekt

18. Vragen?