<commit_before>== Wie vermeide ich neue Serviceversionen?

[%step]
* Ziel: Vermeiden neuer Serviceversionen
* Grund: Kosten und Komplexität reduzieren

[NOTE.speaker]
--
* neue Version nur bei nicht rückwärtskompatiblen Änderungne notwendig
* eine neue Version unseres wichtigsten Services kostet uns 2 Tage
* wenn ich Techniken kenne, die verhindern, dass ich neue Version brauche. spare ich Zeit und Geld
--

=== Postels Law

[quote, Jon Postel]
Be conservative in what you send, be liberal in what you accept.

=== Postels Law

[%step]
* Tolerant Reader
* Manificient Writer

[NOTE.speaker]
--
* Magnificient Writer : Kurzform, ich schicke nichts, breakendes, und sichere das technisch ab
* Tolerant Reader: Ignoreiren von unbekannten Elementen, keine Validierung des WSDLS
* Wir machen das zum Beispiel, wenn wir unseren Vertriebsservice vnext zur Verfügung stellen
* Die WSG validiert die Anfragen und Anfragen gegen kein Schema
* Validierung gegen das WSDL ausschalten (erlaubt, dass ältere Versionen verwendet werden können
--

=== Consumer Driven Contract Tests

[%step]
* Konsumenten definieren Erwartung in Tests
* Tests laufen beim Serviceanbieter automatisiert mit
* Tests validierung Struktur und Inhalts
* Nach Änderung kein Test kaputt => keine neue Servieversion

[NOTE.speaker]
--
 wenn erstellen einer neuen Version zwei Tage dauert, und ich durch einen Test herausfinden kann, dass ich die Änderung durchführen kann ohne eine neue Version zu erstellen, dann spare ich zweit Tage (dann sollten die Tests), die Kosten für die Clientanpassungen (mindestens Endpoints nicht einberechnet), ausserdem erlecihtert es die Kommunikation, wer was anpassen muss
--

=== * DEMO [Schematron für SOAP]

*  vielleicht am DevDay fertig, wenn es neue Erkenntnisse liefert

=== Consumer Driven Contract Tests (PACT)

image:consumer_driven_contract_konsument.png[]

[NOTE.speaker]
--
* Client schreibt, was er erwartet in einen Mockserver
* Client schreibt Test, dieser generiert eine "pact" Datei
* TODO : wie kann ich ein kleineres JSON verwenden, als das volle
--

=== Consumer Driven Contract Tests (PACT)

image:consumer_driven_contract_service.png[]

[NOTE.speaker]
--
* Pact Datei wird dem Service zur Verfügung gestellt
* Service führt die Pact Datei aus
--

=== Consumer Driven Contract Tests (PACT)

video::consumer_driven_contract_tests_demo.mp4[options=autoplay]

[NOTE.speaker]
--
* Schreiben eines Consumenten
* Starten des Tests
* Datei kopieren
* Spring boot starten
* änderungen an Servicedefinition vornehmen
* schauen, ob der Test noch läuft
--

=== Consumer Driven Contract Test (PACT, Advanced)

[%step]
* Tool erlaubt die einfache Verwaltung der Pacts
* Konsumenten können Ihre Pacts hochladen
* es entsteht im Idealfall eine grosse Menge von Beispielen

//=== Alternativen zu Pact
//
//* assertj-swagger (https://github.com/RobWin/assertj-swagger)
//* swagger::diff (https://github.com/civisanalytics/swagger-diff)
//* image:restassured_logo.png[] (http://rest-assured.io/)

=== Kleine Schnittstellen

image:grosseSchnittstelle01.png[]

[NOTE.speaker]
--
* das ist eine Version unserer Schnittstelle
--

=== Kleine Schnittstellen

image:grosseSchnittstelle02.png[]

[NOTE.speaker]
--
* jetzt mache ich eine kleine nicht rückwärtskompatible Änderung an der Schnittstelle
* der grüne Teil unterscheidet sich nicht zwischen der neuen Verison und der alten
* grosse Schnittstellen haben die Tendenz, dass es Bereiche gibt, die sich nicht ändern,
die aber trotzdem permanent nachzeogen werden müssen
--

=== Kleine Schnittstellen

image:grosseSchnittstelle03.png[]

[NOTE.speaker]
--
* kleine Änderung hat sich in die gesamte Schnittstelle ausgestrahlt
* Umso kleiner die Schnittstelle ist, desto 
--

=== Extension Points

* in soap world use of xsd:any element
[source,xml]
----
 <xs:any namespace="##any"
                             processContents="lax"
                             minOccurs="0"
                             maxOccurs="unbounded"/>
----

[NOTE.speaker]
--
* neue Attribute können hinzugefügt werden
* Nachteile:
** bei vielen any Elementen verschwindet der Sinn mit einer mit xsd definierten Schnittstelle
--


=== Unsere Entscheidung

[%step]
* Conttract Tests => ja, aber noch nicht etabliert
* Kleine Schnittstellen => ja in Arbeit aber aufwendig hinzubauen
* Extension points => nein, Typisierung für uns zu wichtig
<commit_msg>Im Moment erstmal kein Schematron Beispielπ<commit_after>== Wie vermeide ich neue Serviceversionen?

[%step]
* Ziel: Vermeiden neuer Serviceversionen
* Grund: Kosten und Komplexität reduzieren

[NOTE.speaker]
--
* neue Version nur bei nicht rückwärtskompatiblen Änderungne notwendig
* eine neue Version unseres wichtigsten Services kostet uns 2 Tage
* wenn ich Techniken kenne, die verhindern, dass ich neue Version brauche. spare ich Zeit und Geld
--

=== Postels Law

[quote, <NAME>]
Be conservative in what you send, be liberal in what you accept.

=== Postels Law

[%step]
* Tolerant Reader
* Manificient Writer

[NOTE.speaker]
--
* Magnificient Writer : Kurzform, ich schicke nichts, breakendes, und sichere das technisch ab
* Tolerant Reader: Ignoreiren von unbekannten Elementen, keine Validierung des WSDLS
* Wir machen das zum Beispiel, wenn wir unseren Vertriebsservice vnext zur Verfügung stellen
* Die WSG validiert die Anfragen und Anfragen gegen kein Schema
* Validierung gegen das WSDL ausschalten (erlaubt, dass ältere Versionen verwendet werden können
--

=== Consumer Driven Contract Tests

[%step]
* Konsumenten definieren Erwartung in Tests
* Tests laufen beim Serviceanbieter automatisiert mit
* Tests validierung Struktur und Inhalts
* Nach Änderung kein Test kaputt => keine neue Servieversion

[NOTE.speaker]
--
 wenn erstellen einer neuen Version zwei Tage dauert, und ich durch einen Test herausfinden kann, dass ich die Änderung durchführen kann ohne eine neue Version zu erstellen, dann spare ich zweit Tage (dann sollten die Tests), die Kosten für die Clientanpassungen (mindestens Endpoints nicht einberechnet), ausserdem erlecihtert es die Kommunikation, wer was anpassen muss
--

//=== * DEMO [Schematron für SOAP]
//
//*  vielleicht am DevDay fertig, wenn es neue Erkenntnisse liefert

=== Consumer Driven Contract Tests (PACT)

image:consumer_driven_contract_konsument.png[]

[NOTE.speaker]
--
* Client schreibt, was er erwartet in einen Mockserver
* Client schreibt Test, dieser generiert eine "pact" Datei
* TODO : wie kann ich ein kleineres JSON verwenden, als das volle
--

=== Consumer Driven Contract Tests (PACT)

image:consumer_driven_contract_service.png[]

[NOTE.speaker]
--
* Pact Datei wird dem Service zur Verfügung gestellt
* Service führt die Pact Datei aus
--

=== Consumer Driven Contract Tests (PACT)

video::consumer_driven_contract_tests_demo.mp4[options=autoplay]

[NOTE.speaker]
--
* Schreiben eines Consumenten
* Starten des Tests
* Datei kopieren
* Spring boot starten
* änderungen an Servicedefinition vornehmen
* schauen, ob der Test noch läuft
--

=== Consumer Driven Contract Test (PACT, Advanced)

[%step]
* Tool erlaubt die einfache Verwaltung der Pacts
* Konsumenten können Ihre Pacts hochladen
* es entsteht im Idealfall eine grosse Menge von Beispielen

//=== Alternativen zu Pact
//
//* assertj-swagger (https://github.com/RobWin/assertj-swagger)
//* swagger::diff (https://github.com/civisanalytics/swagger-diff)
//* image:restassured_logo.png[] (http://rest-assured.io/)

=== Kleine Schnittstellen

image:grosseSchnittstelle01.png[]

[NOTE.speaker]
--
* das ist eine Version unserer Schnittstelle
--

=== Kleine Schnittstellen

image:grosseSchnittstelle02.png[]

[NOTE.speaker]
--
* jetzt mache ich eine kleine nicht rückwärtskompatible Änderung an der Schnittstelle
* der grüne Teil unterscheidet sich nicht zwischen der neuen Verison und der alten
* grosse Schnittstellen haben die Tendenz, dass es Bereiche gibt, die sich nicht ändern,
die aber trotzdem permanent nachzeogen werden müssen
--

=== Kleine Schnittstellen

image:grosseSchnittstelle03.png[]

[NOTE.speaker]
--
* kleine Änderung hat sich in die gesamte Schnittstelle ausgestrahlt
* Umso kleiner die Schnittstelle ist, desto 
--

=== Extension Points

* in soap world use of xsd:any element
[source,xml]
----
 <xs:any namespace="##any"
                             processContents="lax"
                             minOccurs="0"
                             maxOccurs="unbounded"/>
----

[NOTE.speaker]
--
* neue Attribute können hinzugefügt werden
* Nachteile:
** bei vielen any Elementen verschwindet der Sinn mit einer mit xsd definierten Schnittstelle
--


=== Unsere Entscheidung

[%step]
* Conttract Tests => ja, aber noch nicht etabliert
* Kleine Schnittstellen => ja in Arbeit aber aufwendig hinzubauen
* Extension points => nein, Typisierung für uns zu wichtig

{'fraction_non_alphanumeric': 0.07928913192071087, 'fraction_numerical': 0.002050580997949419, 'mean_word_length': 4.415792720542875, 'pattern_counts': {'":': 0, '<': 6, '<?xml version=': 0, '>': 14, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 2}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4665178', 'n_tokens_mistral': 2899, 'n_tokens_neox': 2957, 'n_words': 980}