Continuous Delivery für Groß und Klein

Continuous Integration und Delivery oder Pipeline as Code sind in aller Munde. Trotzdem gibt es noch einige Projekte, die gänzlich ohne automatisierte Builds und Tests auskommen.

Anhand eines Beispielprojekts zeigen wir euch die Schritte von einem manuellen Deployment über einfachere Buildskripte, bis hin zu einer vollautomatisierten Deliverypipeline. Dabei werden wir Fragen wie „Gibt es das eine Tool für alle Anwendungsfälle?“ und „Wieviel Automatisierung ist zu viel?“ beantworten.

Transcript

1. Jannis Schaefer | cosee jannis.schaefer@cosee.biz | @jannisschaefer Jonas Bechstein | cosee jonas.bechstein@cosee.biz Continuous Delivery für Groß und Klein
2. Continuous Delivery • Was ist das? • Wie geht das? • Welche Tools sollte ich wann benutzen?
3. Was ist Continuous Delivery?
4. Wer benutzt CI/CD?
5. Feedback
6. Warum Continuous Delivery? • Feedback an Entwickler • Bugs früh erkennen • Verbessert Zusammenarbeit • Jeder sieht aktuellen Status des Projekts CC-BY Thomas Ferris Nicolaisen tfnico.com
7. Warum Pipelines?
8. Wie hängen einzelne Schritte zusammen? Jenkins 2.37
9. ☺ Pipelines
10. • Kompilieren • UnitTests • Erstellen eines Buildartefaktes zur weiteren Verwendung
11. • UI Tests laufen in separater Testumgebung • „Klicken“ die Anwendung durch
12. • Zusammenspiel der Komponenten einer Anwendung • Integrität mit externen Abhängigkeiten
13. https://twitter.com/ThomasArdal/status/830121519347036160
15. • Auslieferung auf Stagingumgebung • Stagingumgebung gleicht Produktionsumgebung bis auf Skalierung • Testet Integrität mit altem Datenbestand • Erste Möglichkeit eigene Änderungen live zu sehen
16. • Oft manueller Schritt • Release auf Produktivumgebung • Anwendung hat vorher komplette Pipeline durchlaufen
17. Infrastructure as Code
18. • Builddefinition soll versioniert werden • CI Server schneller konfigurierbar • Modularisierbar & Wiederverwendbar Pipeline as Code
20. Pipeline as Code build: stage: build image: maven:3.3.9-jdk-8 script: - 'mvn $MAVEN_CLI_OPTS verify' artifacts: paths: - target/ .deploy: &deploy stage: deploy image: quay.io/cosee-concourse/heroku-cli script: - cp ./Procfile ./target/Procfile - heroku deploy:jar target/continuous-0.0.1-SNAPSHOT.jar #--app $APPNAME deploy-staging: #<<: *deploy variables: APPNAME: techtalk-gitlab-stage environment: name: staging url: https:#//techtalk-gitlab-stage.herokuapp.com/
21. Schon aufwendig, oder?
22. Resümee • CI/CD nur in sinnvollem Maße einsetzen • Für kleine Projekte Pipelines nicht immer sinnvoll • Es gibt nicht das eine Tool
23. Tools
24. • Online Bash-Skript++ • Testen mit unterschiedlichen SDKs (‚Matrix Builds‘) • Sinnvolle Standardeinstellungen und Templates
25. • Quellcodeverwaltung mit integriertem CI Service • Funktionsumfang wächst stetig • Redeployment alter Versionen einfach möglich
26. Concourse • Pipeline as Code „Hardliner“ • Jeder Task in eigenem Container • Debuggen von Containern einfach möglich
27. Los geht’s …
28. Nächster Talk … Redis 4 <Tobias Breitwieser/> 27.04.2017 > blog.cosee.biz > talks.cosee.biz