Continuous Delivery für Legacy Systeme

Gehalten auf den Xp Days 2018: https://www.xpdays.de/2018/sessions/142-continuous-delivery-fuer-legacy-systeme.html

Basierend auf einer wahren Begebenheit.

Ich bin Softwarearchäologe. Ich habe wirklich Spaß daran alten Code auszugraben und wieder fit zu machen. Gleichzeitig freue ich mich auch über Neuentwicklungen, bei denen die Software auf Continuous Delivery ausgelegt werden kann. Doch ist Continuous Delivery wirklich nur für Projekte auf der grünen Wiese geeignet? In meinem vorigen Projekt konnte ich das untersuchen anhand der schlimmsten Codebasis die ich je gesehen habe.

Ein Monolith aus 5 Millionen Zeilen Code in verschiedenen Sprachen (Java, Classic ASP, VBA, JavaScript, T- und PL-SQL). Die Fachlichkeit erstreckte sich vom UI (Scripting, SQL Queries) bis zur Datenbank (Stored Procedures). Keine Versionskontrolle, keine Testabdeckung und keine Testumgebung. Die Mandantenfähigkeit erhielt man in dem man Code ein oder auskommentierte. Dieses System war eine große Herausforderung.

Ein Neubau war keine Option. Etwa 20 Menschen hatten gut 15 Jahre Entwicklungszeit investiert. In 9 Monaten musste das System für 10 Mandanten live sein. Es sollte in der Cloud betrieben werden und die Infrastruktur war nicht spezifiziert. Es gab viele Probleme zu lösen.

Transcript

1. Continuous Delivery für Legacy Code Richard Gross @arghrich
2. Grundlage 09.11.18 Richard Gross @arghrich 2 Richard Software Archäologe Sanierungsprojekte Audits Die schlimmste Codebasis die ich je gesehen habe
3. Dylan Beattie @dylanbeattie Legacy Code is code that’s too scary to update and too profitable to delete. Michael Feathers @mfeathers Legacy Code is code without tests. 09.11.18 Richard Gross @arghrich 3
4. Dylan Beattie @dylanbeattie Legacy Code is code that’s too scary to update and too profitable to delete. Continuous Delivery If somebody thinks of a good idea, how do we deliver it to users as quickly as possibly? 09.11.18 Richard Gross @arghrich 4
5. 09.11.18 Richard Gross @arghrich 6 Continuous Delivery mit Zuversicht?
6. Problemstellung 09.11.18 Richard Gross @arghrich 7
7. Ideale Architektur 09.11.18 Richard Gross @arghrich 8 UI / API BL DL DB P T C C C /
8. Ideale Business Logik Tests 09.11.18 Richard Gross @arghrich 9 UI / API BL DL DB P T C C / C
9. Legacy Architektur 09.11.18 Richard Gross @arghrich 10 BL/DB in UI / API BL BL in DB P T C C /
10. BL in DB BL BL/DB in UI / API Initiale Legacy Business Logik Tests 09.11.18 Richard Gross @arghrich 11 P T / C C
11. Classic ASP Architektur 09.11.18 Richard Gross @arghrich 12 BL/DB in UI / API BL in DB P T C /
12. Ambitionierte Ziele üSoftware nach 15 Jahren vom Dienstleister übernehmen üEventueller Umzug in die Azure Cloud üWeiterentwicklung ermöglichen üStatt 40, nur 10 Personen im Team üBetrieb für 10 Kunden 09.11.18 Richard Gross @arghrich 13
13. 5M 4M Lines of Code Lieferung 09.11.18 Richard Gross @arghrich 14 T-SQL JavaScript VBA C# Asp.NET + C# Classic Asp + VBScript Excel WinForms + C# Fat Client Webservice Database Kein Code geliefert MIA Jobs Website
14. Unsichtbare Aufrufe 09.11.18 Richard Gross @arghrich 15 Excel Webservice Website Fat Client Jobs C C C Database C P T C C C C (BL in) UI / API C BL DB T
15. Connascence 2 elements A,B are connascent if there is at least 1 possible change to A requires a change to B in order to maintain overall correctness Meilir Page-Jones | Jim Weirich‘s “Grand Unified Theory of Software Development” J
16. 3-axes of Connascence 10 Strength Level How explicit Locality How close Degree Size of Impact Meilir Page-Jones | Jim Weirich‘s “Grand Unified Theory of Software Development” J
17. 10 Kundeninstallationen 09.11.18 Richard Gross @arghrich 19 Frobozz Co. Oceanic Airlines … Umbrella Corp Soylent Corp
18. … Oceanic Airlines Soylent Corp 10x Softwarestände 09.11.18 Richard Gross @arghrich 20 Frobozz Co. Umbrella Corp Gleich C/P Copy/ Paste Feature Copy/Paste
19. 10x Softwarestände 10x Datenbankschemata 09.11.18 Richard Gross @arghrich 21 Gleich Gleich
20. Oh Boy 09.11.18 Richard Gross @arghrich 22
21. Empfehlungen Team, Vorgehen 09.11.18 Richard Gross @arghrich 23
22. Signifikante Veränderung im Team und in Kultur notwendig 09.11.18 24
23. Neues Co-located Cross-functional Team mit gemeinsamen Ziel 09.11.18 25 DEV TEST OPS Endkunde
24. 09.11.18 26 DEV TEST OPS Endkunde Collective Legacy, Test, Product Ownership
25. Vielleicht besser: Ein „Startup“ für die Legacy Übernahme DEV TEST OPS Endkunde 09.11.18 27
26. Team Tätigkeiten 09.11.18 Richard Gross @arghrich 28 Sanierung Archäologie Infrastruktur aufbauen Konfigurier barkeit herstellen Vollständige Lieferung Verifizieren
27. Version Everything Sollte man nicht sagen müssen, aber leider gilt: • Code – oft nicht versioniert • Config – sehr selten • Deploymentscripte – Fast nie • Infrastruktur - Nie 09.11.18 Richard Gross @arghrich 29
28. Anti-Pattern: Folder Version 09.11.18 Richard Gross @arghrich 30
29. Anti-Pattern: File Version 09.11.18 Richard Gross @arghrich 31
30. Vorgehen: Infrastruktur • Dev/Prod-Parity • Phoenix Server • Jeder Build ist potentielles Release • Unternehmen vom Mehrwert von Infrastructure Automation überzeugen • Standard IA-Tools nutzen • Nicht: Ansible nachbauen mit Powershell Scripten 09.11.18 Richard Gross @arghrich 34
31. Vorgehen: Konfigurierbarkeit •Eine konfigurierbare Software, nicht 10 fest-verdrahtete •z.B.: msdeploy.exe, sqlpackage.exe • (String) replacement bei publish • Umgebungsvariablen 09.11.18 Richard Gross @arghrich 35
32. Anti-Pattern: Branch by Obscurity • Branch by (Un) Comment • Branch by Entity-Id 09.11.18 Richard Gross @arghrich 37
33. Vorgehen: Software-Archäologie https://fs.blog/2013/07/the-difference-between-science-and-engineering/ Archeological Inquiry
34. Lernen mit Inverse Object Mother • Anwendung Starten mit leerer Datenbank und ohne Domain Modell • UseCase klicken • Fehler analysieren • Domain Modell erweitern um Erkenntnis • Benötigten Zustand in DB mit Modell herstellen • Dokumentieren als Test • Repeat 09.11.18 Richard Gross @arghrich 39
35. Inverse BDD ist sehr schwierig • Was will wollte der Anwender • Gherkin wird für Data-Scripting missbraucht • Gherkin bei uns deplatziert und zu teuer 09.11.18 Richard Gross @arghrich 40
36. Vorgehen: Sanierung Prio 1Technisch und/oder fachlich obsoleten Code entfernen 09.11.18 Richard Gross @arghrich 41
37. Obsoleten Code finden • Anwenderumfragen • IDE gibt Vorschläge • grep auf FROM, JOIN, INSERT, UPDATE, DELETE und rein in Excel • Analytics / Activity-Log für Seiten einbauen • Legacy Toggles / Inverse Circuit Breaker • Vergessen Teile zu deployen 09.11.18 Richard Gross @arghrich 42
38. Startpunkt festlegen • Linter • Profiler • CodeMaat https://github.com/ adamtornhill/code-maat • Structure101 http://structure101.com/ • SonarQube https://www.sonarqube.org/ • CodeCharta https://github.com/ MaibornWolff/codecharta Art by Zaufishan
39. Startpunkt festlegen • Linter • Profiler • CodeMaat https://github.com/ adamtornhill/code-maat • Structure101 http://structure101.com/ • SonarQube https://www.sonarqube.org/ • CodeCharta https://github.com/ MaibornWolff/codecharta 09.11.18 Richard Gross @arghrich 44
40. Golden Master für Refactoring 09.11.18 Richard Gross @arghrich 45 Saniertes System Legacy System Input for UI/API/DB Output Output Compare
41. (Refactoring) Branching Strategy • Don‘t Branch • Don‘t Branch • Don‘t Branch • Stop Continuous Isolation Dave Farley
42. Refactoring Big Ball of Mud Isolate • Stable von Unstable • R/W mit Fassaden trennen • Interfaces • Dependency Injection • Table Views Small • Baby Steps • Feathers Techniken • Mob Programming 09.11.18 Richard Gross @arghrich 47 • Branch by abstraction • Parallel Change • Strangler Application Big
43. Strangler Application https://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/
44. Commit Compile Unit Tests Code Analysis Package Source Code Version Control Pipeline Stages Artifact Repo Environ- ment V8.4.0 Acceptance Deploy Package Smoke Tests Acceptance Tests Categorization Tests Env & App Config 10x Staging Staging Integration V8.4.0 tag V8.4.0-acc UAT Deploy Package Smoke Tests Manual Tests Env & App Config 10x Staging Staging Staging Self-Service Tester tag V8.4.0-uat/released Production Deploy Package Smoke Tests 10x Staging Staging Production PO Self-Service
45. Deployment Agility 09.11.18 Richard Gross @arghrich 50 • Minimum Time to UAT/Prod 10min 10 minutes for Build • Regular Time to UAT 50min 10: Build | 20: DB Migrate INT | 20: DB Migrate STAGE • Nightly Infrastructure Updates 2h 30: Powershell | 60: DB Create + Init | 20: DB Migrate • Canary Builds & Releases wären besser • Alle 2 Wochen 1w manuelle Testphase • Perspektivisch durch mehr E2E ersetzen
46. Hat sich der Aufwand gelohnt? • Anwender haben sich riesig gefreut • Stabiler als jemals zuvor • Bis heute kann keiner Beschreiben was „so wie vorher“ bedeutet à wie soll man das neu bauen • Hätte man auch mit Anforderungen nicht in einem Jahr neu bauen können • Fließende Übergang à min. Feature Freeze • No Second System-Syndrome 09.11.18 Richard Gross @arghrich 51
47. CD für Legacy Tätigkeiten • Lieferung • Infrastruktur • Konfigurierbarkeit • Archäologie • Sanierung Erfolgsfaktoren • Mut • Team • Infra-Automation • Pipeline • Situativ angehen • Strangler • Mut zum Mob • Connascence 09.11.18 Richard Gross @arghrich 52
48. Done Fragen, Anmerkungen, Mitleid? J 30 Mio 410 Mitarbeiter*innen 9. Jahr 23 Nationen 300 Wochen München, Augsburg, Berlin, Frankfurt
49. Reading • https://trello.com/b/Fdd876S8/continuous- delivery-checklist-template • Uvm. Ich dachte nicht, dass ich diese Folie zeigen werde 09.11.18 Richard Gross @arghrich 54