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

Continuous Delivery für Legacy Systeme (v1) 🇩🇪 ...

Richard
November 09, 2018

Continuous Delivery für Legacy Systeme (v1) 🇩🇪 @Xp Days 2018

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. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. … 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
  10. Team Tätigkeiten 09.11.18 Richard Gross @arghrich 28 Sanierung Archäologie Infrastruktur

    aufbauen Konfigurier barkeit herstellen Vollständige Lieferung Verifizieren
  11. 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
  12. 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
  13. 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
  14. Anti-Pattern: Branch by Obscurity • Branch by (Un) Comment •

    Branch by Entity-Id 09.11.18 Richard Gross @arghrich 37
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. Golden Master für Refactoring 09.11.18 Richard Gross @arghrich 45 Saniertes

    System Legacy System Input for UI/API/DB Output Output Compare
  21. (Refactoring) Branching Strategy • Don‘t Branch • Don‘t Branch •

    Don‘t Branch • Stop Continuous Isolation Dave Farley
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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
  27. Done Fragen, Anmerkungen, Mitleid? J 30 Mio 410 Mitarbeiter*innen 9.

    Jahr 23 Nationen 300 Wochen München, Augsburg, Berlin, Frankfurt