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

Von Continuous Deployment zu Microservices

Von Continuous Deployment zu Microservices

Die technische Geschichte hinter EUROPACE2 - Architektur, Build, Testen, Deployment, Entwicklungsprinzipien.

Jörg Pfründer

September 14, 2016
Tweet

More Decks by Jörg Pfründer

Other Decks in Programming

Transcript

  1. Version Update Altes Schema: Version 27 { "id" : 9586729475,

    "version" : "345", "modelVersion" : "27", "firstname" : "John", "surname" : "Doe", "street" : "Klosterstraße" "number" : "71" "zip" : "10279" "city" : "Berlin" }
  2. Version Update Neues Schema: Version 28 { "id" : 9586729475,

    "version" : "345", "modelVersion" : "28", "firstname" : "John", "surname" : "Doe", "address" : { "street" : "Klosterstraße" "number" : "71" "zip" : "10279" "city" : "Berlin" } }
  3. VersionConverter DBObject address = new DBObject(); address.put("street", dbObjectRoot.get("street")); address.put("number", dbObjectRoot.get("number"));

    address.put("zip", dbObjectRoot.get("zip")); address.put("city", dbObjectRoot.get("city")); dbObjectRoot.put("address", address));
  4. VersionConverter • migriert das Modell immer von Version n auf

    Version n+1 • Mehrere VersionConverter können kombiniert werden • Lazy Conversion vs. Batch Conversion
  5. Benutze die Client Implementierung für Tests: Consumer Driven Tests in

    einer Consumer Driven Test Suite (CDTS) Contract Tests
  6. Keine Breaking Changes! 1. Altes Schema { "id" : 9586729475,

    "firstname" : "John", "surname" : "Doe", "name" : "John Doe" }
  7. Keine Breaking Changes 1. Altes Schema 2. Kompatibilitätsversion die sowohl

    altes als auch neues Schema unterstützt { "id" : 9586729475, "firstname" : "John", "surname" : "Doe", "name" : "John Doe", "displayName" : "John Doe" }
  8. Keine Breaking Changes 1. Altes Schema 2.Kompatibilitätsversion die sowohl altes

    als auch neues Schema unterstützt 3.Neues Schema { "id" : 9586729475, "firstname" : "John", "surname" : "Doe", "name" : "John Doe", "displayName" : "John Doe" }
  9. • Persistenz soll schnelle Änderungen unterstützen • Incremental Build hilft,

    aber nicht so viel, wie nötig • Andere Teams müssen ihre eigenen Lösungen finden • Consumer Driven Tests statt Komplettintegrationstests • Geht‘s noch einfacher? • Leicht und schnell – kann auf lange Sicht Probleme ergeben • Replaceability statt Reuse: kein „Utils“-Keller! • Das wichtigste: Was dem Kunden hilft!
  10. Zum Weiterdenken... • Mike Cohn: http://www.mountaingoatsoftware.com/blog/the-forgotten- layer-of-the-test-automation-pyramid • J.B. Rainsberger:

    Integration Tests Are a Scam http://www.infoq.com/presentations/integration-tests-scam • Ian Robinson: Consumer-Driven Contracts: A Service Evolution Pattern http://martinfowler.com/articles/consumerDrivenContracts.html • Brandon Byars: Enterprise Integration Using REST http://martinfowler.com/articles/enterpriseREST.html • Sam Newman: Building Microservices • Uwe Friedrichsen: The Broken Promise of Reuse https://blog.codecentric.de/en/2015/10/the-broken-promise-of-re- use/ • Russ Olsen: To the Moon! https://www.youtube.com/watch? v=4Sso4HtvJsw