Stabile und skalierbare Testumgebungen sind seit jeher schwer aufzusetzen und zu warten. Besonders in Zeiten von Continuous Delivery ist das Aufsetzen von Build-Pipelines in Verbindung mit automatisierten Integration- und UI-Tests eine besonders große Herausforderung. Einen eleganten Ausweg bieten containerbasierte Testumgebungen, die dynamisch zum Build-Zeitpunkt bereitgestellt werden. Der Talk zeigt anhand von mehreren Live-Demos, wie mit Hilfe von OpenShift-Build-Pipeline sowohl Server-APIs als auch grafische Web- und Rich-Client-Oberflächen getestet werden können. Zum Einsatz kommen hierfür die Open-Source-Test-Frameworks Citrus und Sakuli, die bereits für die Verwendung in OpenShift vorbereitet sind.

1. Continuous Testing:
Integration- und UI-Testing mit
OpenShift-Build-Pipelines.
Tobias Schneck, ConSol Software GmbH
München, 11. Juli 2017
„OpenShift – everything Continuous „

2. Seite 3
OpenShift CI/CD Pipeline Konzept

3. Seite 4
DEV
Prozess Development -> QA Stage
Code
Build & Test
Deploy in Dev
Container
Image
Container
Registry
POD
OPS
Deploy in QA
POD
AUTOMATISCH
MANUEL ODER AUTOMATISCH

4. Seite 5
OPS
Prozess QA -> Production Stage
Deploy in
Produktion
Container
Image from QA Stage
Container
Registry
POD
MANUEL

5. Seite 6
CI / CD
Build Pipeline?
OpenShift Komponenten

6. Seite 7
Execution Node
OpenShift Builds (tradional)
Builder Image
OpenShift
Builder Pod
Docker native
Build
Source-2-
Image Build
Base Image
OpenShift
Master
Scheduler
Image Artifcat
OpenShift
Internal
Registry
Image Stream
(Project/Global)
Dockerfilebuild.yml

7. Seite 8
Execution Node
OpenShift Builds (CI Pipeline)
Jenkins Image
OpenShift
Builder Pod
Jenkins
Pipeline Build
OpenShift
Master
Scheduler
Image Artifcat
OpenShift
Internal
Registry
Image Stream
(Project/Global)
Jenkinsfile
Maven Image
…
OpenShift
Regular Build

8. Seite 9
Build up a Build Pipelines !

9. Seite 10
Bakery App

10. Seite 11
Bakery App

11. Seite 12
Transformation to OpenShift
Ziele:
• Sourcecode der Apps nicht verändern
• Testcode nicht verändern
• Vollautomatisiert bis in die Produktion
• All-in-OpenShift (CI, Build, Test, Deployment)
• Jenkins v1 -> v2

12. Seite 13
Stage I: CI-Build bis zum Artefakt

13. Seite 14
CI Build -> Docker Image
Docker Image
Artifcat
Jenkinsfile.dev
Maven Image
build.pipeline.yml
Dockerfiles
OpenShift
regular build

14. Seite 15
DEMO
toschneck/openshift-example-bakery-ci-pipeline

15. Seite 16
Stage II: Automated Testing

16. 17Seite
Citrus Integration Testing
Automatisierte Schnittstellentests

17. 18Seite
Citrus Integration Testing
Automatisierte Schnittstellentests

18. 19Seite
Sakuli End-2-End Testing

19. 20Seite
Sakuli End-2-End Testing

20. Seite 21
QA -> tested Docker Image
Docker Image
Artifcat
Jenkinsfile.qa
Citrus Image
build.pipeline.yml
Sakuli Image

21. Seite 22
DEMO
toschneck/openshift-example-bakery-ci-pipeline

22. Seite 23
Review
• Migration zu Jenkinsfiles
• Viele Wrapper-Scripte, um flexibel zu sein
• Verteiltes CI-Design erfordert ein Umdenken
• CI-Daten schwerer zugänglich
(Logs, Screenshots, Artifakte)
• Technologie-Mix
• Verteilte Dokumentation
(OpenShift, Jenkins, Jenkins-Plugins, Docker, …)

23. Seite 24
Review
• Skalierung übernimmt der Cluster
• "oc CLI client" anstatt Openshift-Jenkins-Plugin
• Parametrisierte YAML Templates für OpenShift
• Infrastractur as Code
• Neue Stages sind einfach zu erstellen
• Deployment wird automatisch mitgetestet
• Secrets durch Cluster-Admins verwaltbar
• Builds Steuerbar von CLI und UI

24. Seite 25
Links
toschneck/openshift-example-bakery-ci-pipeline
christophd/citrus www.citrusframework.org
ConSol/sakuli www.sakuli.org
@toschneck
@citrus_test
@sakuli_e2e

25. Seite 26
Danke!
Fragen?

26. Seite 27
ConSol Software GmbH
Franziskanerstraße 38
D-81669 München
Tel: +49-89-45841-100
Fax: +49-89-45841-111
info@consol.de
www.consol.de