Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Continuous Delivery für Legacy Systeme

Richard
November 09, 2018

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.

Richard

November 09, 2018
Tweet

More Decks by Richard

Other Decks in Technology

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