CONTINUOUS DELIVERY. codecentric AG

Transkript

1 CONTINUOUS DELIVERY

2 AGENDA Einstieg Was ist Continuous Delivery Welche Ziele werden verfolgt? Voraussetzungen Technisch Organisatorisch Kulturell Umsetzung und Einführung 6 Disziplinen der Continuous Delivery Konsequenzen (neue Möglichkeiten) Technisch Organisatorisch Kulturell

4 WAS IST CONTINUOUS DELIVERY Wertvollen Kundennutzen wiederholt, automatisiert, schnell und qualitativ hochwertig in Betrieb nehmen, warten und erweitern

5 WELCHE ZIELE WERDEN MIT CD VERFOLGT Fachbereiche Raum für Innovation! Neue Ideen schnell ausprobieren können Direktes Kunden-Feedback Entwicklung & Test Dem Release die Bedrohung nehmen Ständig aktuelle Testumgebungen haben Qualität garantieren können Betrieb Stabilität und Kontrolle! Keine Anrufe um Mitternacht Keine Anrufe beim Date Keine Anrufe in der Badewanne Oder eine beliebige Kombination davon

7 TECHNISCHE VORAUSSETZUNGEN Handwerkszeug Automatisierung analyse build architect test code deploy

8 ORGANISATORISCHE VORAUSSETZUNGEN Überwinden von organisatorischen Grenzen zwischen Betrieb und Entwicklung Alle an der Wertschöpfung Beteiligten einbinden Cross-funktionale Teams Fachlichkeit Entwicklung Test Dokumentation Installation Betrieb Ergänzung der Definition of Done

9 KULTURELLE VORAUSSETZUNGEN Verständnis und Ausgleich der Ziele und Interessen Fachbereich: Innovation und neue Produkte Entwicklung und Test: Technische Innovation Betrieb: Stabilität und Kontrolle Annahme der Verantwortung für reibungslose Deployments

11 6 DISZIPLINEN DER CONTINUOUS DELIVERY Handwerkszeug Automatisierung analyse architect code build test deploy User Stories Personas Evolutionäre Architektur Test Driven Development Mocks & Stubs Continuous Integration Distributed Version Control Continuous Testing Acceptance Test Driven Development Continuous Deployment Delivery Pipeline Story Mapping Mockups Ausreichende Dokumentation Design Refactoring Dependency Management Feature Branches / Toggles Statische Code- Analyse & Metriken NFA Testing Release Process (Version, Notes, Migration)

12

13 Sprints STORY MAPPING PRODUCT BACKLOG 2D Einfacher Workflow Aus Mehreren Schritten Story Story Story Story Story Story Story Story Story Story Story Story Story Story Story Story Story Story Story

14 MOCKUPS

15

16 ARCHITEKTUR IM PROJEKTVERLAUF Funktionalität Funktionalität validiert Architektur Architektur Niemals ohne Funktionalität t

17 DOKUMENTATION IM IT LEBENSZYKLUS Initiale Systementwicklung Scrum IT System Lebenszyklus System ist in Produktion & Wartung... wird hauptsächlich hier erstellt Dokumentation... wird hauptsächlich hier benötigt

18 AUSREICHENDE DOKUMENTATION Externe Partner Support Wartung Entwicklung Benutzer Interface Guide Support Guide Architekturübersicht Build/ Deployment Online Hilfe System Documentation Fachadmin Admin. Guide Betriebsleitfaden QA Betrieb Datenschutz / Sicherheit Planung Installation

19

20 ALLES UNTER (VERSIONS-) KONTROLLE!? Datenbankschema Build- Skripte Config Resourcen Sourcen Install- Skripte Tests Laufzeitumgebung

21 TRUNK/MAIN/DEFAULT IST STÄNDIG AUSLIEFERBAR Feature Branches Feature Toggles Verteiltes VCS Kurzlebige Branches Automatisierte Fachtests Negativtest CI für Branches Toggle Lifecycle

22 TDD CYCLE: RED GREEN REFACTOR [Start] Simplest Solution Refactor Write Test Red Green Write Test

23 TDD ERFORDERT ÜBUNG Coding Katas Kleine Problemstellungen Erlernen der Techniken, bis sie in Fleisch und Blut übergegangen sind Code Retreat Thema: Game Of Life 45 Minuten Pair Programming Code löschen & Retrospektive Unterschiedliche Aufgabenstellungen Ohne Maus TDD as if you mean it

24 REFACTORING Es gibt mehr als Extract Method Extract Variable Die Eclipse Hilfe ist als Start sehr gut nur weiß das kaum jemand Nicht refaktorisierter Code führt unweigerlich zu technischen Schulden Lerne, die Tastatur zu benutzen!

25 SOLID EMERGENTES DESIGN SRP OCP LSP ISP DIP Single Responsibility Principle Open Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle Für eine Klasse gibt es nur genau einen Grund sie zu ändern. Offen für Erweiterungen, Abgeschlossen für Änderungen: Es ist möglich, das Verhalten einer Klasse zu erweitern ohne sie zu ändern Abgeleitete Klassen müssen ihre Basisklasse vollständig ersetzen können. Clients sollten nicht gezwungen sein von Schnittstellen abhängig zu sein, die sie nicht benutzen: Clientspezifische Feingranulare Schnittstellen Sei von Abstraktionen abhängig, nicht von Konkretisierungen: Abstraktes hängt nicht von Details ab, Details hängen von Abstraktem ab

26

27 CONTINUOUS INTEGRATION

28 UMGANG MIT ABHÄNGIGKEITEN Abhängigkeiten beschreiben und verwalten Maven, Gradle, Nexus, Artifactory, Inkrementelle Änderung von Schnittstellen 1. Neue Schnittstelle parallel live schalten 2. Clients Zug um Zug migrieren 3. Alte Schnittstelle abschalten Umgang mit Werkzeugen von Drittanbietern beim Versionswechsel nach Möglichkeit ähnlich behandeln

29

30 TESTQUADRANTEN

31 AUSFÜHRBARE SPEZIFIKATIONEN Beispiele Tests verifizieren Anforderungen 31

32 TABELLARISCHER AUFBAU Macht Unterschiede einfach sichtbar Im Specifikation Workshop können einfach die Randfälle abklopft werden GIVEN // Es existiert... WHEN // Wenn... THEN // Dann... Variable 1 Variable 2 Variable... Variable n 32

33 AUSFÜHRBARE SPEZIFIKATIONEN *** Keyword *** Verhalten [Arguments] ${Produkt} ${Feld} ${Wert} ${Fehler} ${Ort} Es existiert eine Produktseite für ${Produkt} Wenn im Feld ${Feld} der Wert ${Wert} eingegeben wird Dann wird der ${Fehler} angezeigt Und der ${Fehler} befindet sich bei ${Ort} Und der ${Fehler} ist als Fehler hervorgehoben Und das Feld ${Feld} ist als Validierungsfehler markiert *Test Case* *Produkt* *Feld* *Wert* *Fehler* *Ort* 1 Haftpflicht Geburtsdatum ABC Bitte TT.MM.JJJJ an. Hauptrechenblock 2 Haftpflicht Fassungsvermögen ABC ABC ist keine Zahl Risikorechenblock

34 EINIGE METRIKEN CODE COVERAGE Codeabdeckung: Menge an Source-Code, die von Unit-Tests ausgeführt werden Gut: Einfache Metrik um festzustellen, dass genug Tests geschrieben wurden Schlecht: Keine Aussage, ob gute Tests geschrieben wurden

35 EINIGE METRIKE KOMMENTARE UND DUPLIKATION Kommentare Anteil von Kommentaren am gesamten Sourcecode Auskommentierter Sourcecode Nicht dokumentierte APIs Copy & Paste DRY Don t Repeat Yourself

36 EINIGE METRIKEN ZYKLOMATISCHE KOMPLEXITÄT Misst die möglichen Ausführungspfade durch eine Methode If, while, switch, for Entspricht der Anzahl notwendiger Unit- Tests Sollte nicht viel größer als 10 sein Methoden mit hoher Komplexität sind schwierig Zu verstehen Zu ändern Zu testen

37

38 DEPLOYMENT PIPELINE Commit & Push Build Quality Test Stage Produktion Compile Unit tests Package Metrics Documentation Deployment auf Testumgebung Fach- & Regressionstests Performancetests Deployment auf Integrationsumgebung Exploratives Testen Deployment auf Produktionsumgebung

39 DEPLOYMENT PIPELINE - ROLLBACK Commit & Push Build Quality Test Stage Produktion Benutze identisches Deploymentverfahren! Tests erfolgreiches Deployment (Smoke Tests) Sei auf ein Rollback vorbereitet

41 TECHNISCHE AUSWIRKUNGEN Testen in Produktion A/B Testing Canary Releases Cherry-Picking Kleinere, autarke Module Zero Downtime Rollback vs. Forward-Fixing

42 ORGANISATORISCHE AUSWIRKUNGEN Von der Titanic zum Release Train Messen sinnvoller Metriken Wie viele Kunden nutzen die neuen Features? Schnelles, relevantes Feedback

43 AUSWIRKUNGEN AUF PROZESSFRAMEWORKS Fragen über Fragen Gibt es noch Iterationen? Darf innerhalb eines Sprints mit CD ausgeliefert werden? Was wird am Ende eines Sprints beim Review gezeigt? Wichtig ist die Fähigkeit dem Kunden ständig neuen Nutzen ausliefern zu können In welchem Rahmen das geschieht ist dabei schon (fast) nebensächlich

45 6 DISZIPLINEN DER CONTINUOUS DELIVERY Handwerkszeug Automatisierung analyse architect code build test deploy User Stories Personas Evolutionäre Architecture Test Driven Development Mocks & Stubs Continuous Integration Distributed Version Control Continuous Testing Acceptance Test Driven Development Continuous Deployment Delivery Pipeline Story Mapping Mockups Ausreichende Dokumentation Design Refactoring Dependency Management Feature Branches / Toggles Statische Code- Analyse & Metriken NFA Testing Release Process (Version, Notes, Migration)

46 FRAGEN? Andreas Ebbert-Karroum Merscheider Straße Solingen tel +49 (0) fax +49 (0) Andreas.Ebbert-Karroum@codecentric.de blog.codecentric.de