<commit_before>= Explizite Serviceversionierung ist möglich
<NAME> <<EMAIL>
2017-09-07
:revnumber: {project-version}
:example-caption!:
ifndef::imagesdir[:imagesdir: images]
ifndef::sourcedir[:sourcedir: ../../main/java]

== Tritt dem Hackergarten Bern bei!

image::hackergartenLogo.jpeg[background]
* Contributing to OpenSource Projekte
* jeden zweiten Dienstag alle zwei Monate in der SBB Effigerstrasse
* https://www.meetup.com/de-DE/Hackergarten-Bern/

== Introduction

[%step]
* Begrissdefinitionen
* Benötige ich explizite Versionierung?
* Wie vermeide ich explizite Serviceversionierung?
* Mit welchen Pattern kann ich explizite Servierversionierung umsetzen?
* Welche nicht technischen Aufgaben muss ich mit der expliziten Servieversionierung lösen?

== Welche Begriffe werden in der Presentation verwendet?

=== Service

image::service.png[background]
[%step]
* ein Stück Software, das irgendwo läuft

=== Serviceschnittstelle

image::schnittstelle.png[background]
[%step]
* über diese kann mit derm Service kommuniziert werden

=== Konsumenten

image::konsument.png[background]
[%step]
* verwenden einen Serviceschnittstelle um etwas sinnvolles mit dem Service zu tun

=== explizite Versionierung

image::expliziteVersionierung.png[background]
[%step]
* werden zwei Versionen einer Serviceschnittstelle angebunden, würde ich von expliziter Versionierung sprechen
* Konsument kann sich aussuchen, mit welcher Version der Serviceschnittstelle er kommuniziert

== Benötige ich explizite Versionierung?

=== Was spricht für explizite Serviceversionierung

[%step]
* Hauptgrund: Konsumenten von Änderungen verschonen
* Ein nicht rückwärtskompatible Änderung ist nicht vermeidbar
* Abgeschlossene Verträge mit Konsumenten
* Unterschiedliche Lifecycle zwischen Service und Konsument
* Es sind nicht alle Konsumenten bekannt

[NOTE.speaker]
--
* nicht vermeidbar: Abbau von Altlasten, Vereinfachungen, entfernen von Redundanzen
* Konsumenten:
** Integration eines Servies kann aufwendig sein mit
** Verträgen können das Risiko reduziert werden, dass Konsument häufig integrieren muss
** Verträge regeln, wie lange eine Version verfügbar sein muss (z.B. Schnittstelle SNCF: alle halbe Jahre migration notwendig)
*  Unterschiedliche Lifecycle
** Konsument und Service können nicht gleichzeitg aktualisiert werden
** Beispiel Backendsysteme vom neuen Vertriebssystem und die vNext
** Alte Version müssen unterstützt werden, weil Wechsel zu einem beliebigen Zeitpunkt erfolgen kann
* Es sind nicht alle Konsumenten bekannt
** Wenn nicht alle Konsumenten bekannt sind, können unterschiedliche Schnittstellenversionen von alten Konsumenten noch im Einsatz sein
** Ich weiss nicht, ob ich immer alle erreichen kann
--

=== Was spricht gegen explizite Serviceversionierung

[%step]
* Hauptgrund: Erhöht die Komplexität
* es gibt nur einen Konsumenten, den ich steuern kann
* Konsumenten sind von einem Service abhängig
* Lebenszyklus Konsumenten und Service ist gleich
* Ressourcenmangel
* Änderungen können immer rückwärtskompatibel durchgeführt werden

[NOTE.speaker]
--
* nur ein Konsument : Ich kann mit dem Konsumenten schauen, wie ich die Schnittstelle
* Abhängig
** wenn ein Abhängigkeitsverhältnis von Konsumenten zum Service besteht, kann ich das nutzen und nur eine Version anbietem
** nicht sehr nett
* lebenszyklus gleich
** gleicher Lebenszyklus, es gehen beide gleichzeitig in Produktion
** in unteren Umgebungen Test ist es OK, wenn der Service eine definierte Zeit nicht angebunden ist
* Resourcenmangel
** Es fehlen die Ressourcen, um zwei Versionen eines Services zur Verfügung zu stellen
* rückwärtrskompatibel
** Wenn Änderungen immer rückwärtskompatibel durchgeführt werden können, dann ist es nicht nötig mehrere Versionen zu haben
** Beispiel ein sehr einfacher Service

--

== Wie vermeide ich explizite Versionierung?

[%step]
* blah

== Welche Pattern kann ich für eine explizite Versionierung verwenden?

[%step]
* blah


== An welche Dinge, muss ich bei der expliziten Versionierung noch denken?

[%step]
* blah

=== Service lifetime

* link:../../src/main/resources/visualizeServiceAvailablity.html[Blah]

== Zusammenfassung

[%step]
. Explizite Versionierung ist notwendig
. Einen einfachen Service auswählen
. Ein Pattern auswählen und implementieren
. Ausprobieren
. dem Hackergarten Bern beitreten

== Vielen Dank

* Material
** https://github.com/ehmkah/service_versioning_example
** https://www.meetup.com/de-DE/Hackergarten-Bern/

=== Extension material

* http://blog.restcase.com/restful-api-versioning-insights/
* https://www.troyhunt.com/your-api-versioning-is-wrong-which-is/
* http://www.oracle.com/technetwork/articles/web-services-versioning-094384.html


<commit_msg>ehmkah: what are breaking changes<commit_after>= Explizite Serviceversionierung ist möglich
<NAME> <<EMAIL>
2017-09-07
:revnumber: {project-version}
:example-caption!:
ifndef::imagesdir[:imagesdir: images]
ifndef::sourcedir[:sourcedir: ../../main/java]

== Tritt dem Hackergarten Bern bei!

image::hackergartenLogo.jpeg[background]
* Contributing to OpenSource Projekte
* jeden zweiten Dienstag alle zwei Monate in der SBB Effigerstrasse
* https://www.meetup.com/de-DE/Hackergarten-Bern/

== Introduction

[%step]
* Begrissdefinitionen
* Benötige ich explizite Versionierung?
* Wie vermeide ich explizite Serviceversionierung?
* Mit welchen Pattern kann ich explizite Servierversionierung umsetzen?
* Welche nicht technischen Aufgaben muss ich mit der expliziten Servieversionierung lösen?

== Welche Begriffe werden in der Presentation verwendet?

=== Service

image::service.png[background]
[%step]
* ein Stück Software, das irgendwo läuft

=== Serviceschnittstelle

image::schnittstelle.png[background]
[%step]
* über diese kann mit derm Service kommuniziert werden

=== Konsumenten

image::konsument.png[background]
[%step]
* verwenden einen Serviceschnittstelle um etwas sinnvolles mit dem Service zu tun

=== explizite Versionierung

image::expliziteVersionierung.png[background]
[%step]
* werden zwei Versionen einer Serviceschnittstelle angebunden, würde ich von expliziter Versionierung sprechen
* Konsument kann sich aussuchen, mit welcher Version der Serviceschnittstelle er kommuniziert

== Benötige ich explizite Versionierung?

=== Was spricht für explizite Serviceversionierung?

[%step]
* Hauptgrund: Konsumenten von Änderungen verschonen
* Ein nicht rückwärtskompatible Änderung ist nicht vermeidbar
* Abgeschlossene Verträge mit Konsumenten
* Unterschiedliche Lifecycle zwischen Service und Konsument
* Es sind nicht alle Konsumenten bekannt

[NOTE.speaker]
--
* nicht vermeidbar: Abbau von Altlasten, Vereinfachungen, entfernen von Redundanzen
* Konsumenten:
** Integration eines Servies kann aufwendig sein mit
** Verträgen können das Risiko reduziert werden, dass Konsument häufig integrieren muss
** Verträge regeln, wie lange eine Version verfügbar sein muss (z.B. Schnittstelle SNCF: alle halbe Jahre migration notwendig)
*  Unterschiedliche Lifecycle
** Konsument und Service können nicht gleichzeitg aktualisiert werden
** Beispiel Backendsysteme vom neuen Vertriebssystem und die vNext
** Alte Version müssen unterstützt werden, weil Wechsel zu einem beliebigen Zeitpunkt erfolgen kann
* Es sind nicht alle Konsumenten bekannt
** Wenn nicht alle Konsumenten bekannt sind, können unterschiedliche Schnittstellenversionen von alten Konsumenten noch im Einsatz sein
** Ich weiss nicht, ob ich immer alle erreichen kann
--

=== Was spricht gegen explizite Serviceversionierung?

[%step]
* Hauptgrund: Erhöht die Komplexität
* es gibt nur einen Konsumenten, den ich steuern kann
* Konsumenten sind von einem Service abhängig
* Lebenszyklus Konsumenten und Service ist gleich
* Ressourcenmangel
* Änderungen können immer rückwärtskompatibel durchgeführt werden

[NOTE.speaker]
--
* nur ein Konsument : Ich kann mit dem Konsumenten schauen, wie ich die Schnittstelle
* Abhängig
** wenn ein Abhängigkeitsverhältnis von Konsumenten zum Service besteht, kann ich das nutzen und nur eine Version anbietem
** nicht sehr nett
* lebenszyklus gleich
** gleicher Lebenszyklus, es gehen beide gleichzeitig in Produktion
** in unteren Umgebungen Test ist es OK, wenn der Service eine definierte Zeit nicht angebunden ist
* Resourcenmangel
** Es fehlen die Ressourcen, um zwei Versionen eines Services zur Verfügung zu stellen
* rückwärtrskompatibel
** Wenn Änderungen immer rückwärtskompatibel durchgeführt werden können, dann ist es nicht nötig mehrere Versionen zu haben
** Beispiel ein sehr einfacher Service
--

=== Welche Änderungen können nicht rückwärtskompatibl sein (SOAP)?

[%step]
* entfernen und umbennen von Operationen
* verändern (Reihenfolge oder Typen) der Parameter in Operationen

[NOTE.speaker]
--
* KÖNNEN, weil ich im Moment der Anpassung nicht weiss, ob der Teil den ich ändere tatsächlich von einem Konsumenten genutzt wird
* wir haben eine SOAP und REST Welt
--

=== Was sind nicht rückwärtskompatible Änderungen bei SOAP & REST ?

[%step]
* löschen von Attributen in Datenstrukturen
* umbennen von Attributen in Datenstrukturen
* bei Requests Attribute von optional auf mandatory setzen
* bei Antworten Attribute von mandatory auf optional setzen
* bei enums hinzufügen/löschen von Werten
* bei Strings, andere Werte zurückschicken, z.B. "1. Klasse" statt "1. KLASSE"

[NOTE.speaker]
--
* Listen statt einzelner Werte
* enums: weil wenn ich neue Werte schicke, kann ein Client darauf nicht reagieren und Fehler machen (z.B. 3. Klasse)
* Strings, wenn ich einen String als Basis nehme um daraus etwas abzuleiten, oder nach einem bestimmten Pattern parse
--

== Wie vermeide ich explizite Versionierung?

[%step]
* blah

== Welche Pattern kann ich für eine explizite Versionierung verwenden?

[%step]
* blah


== An welche Dinge, muss ich bei der expliziten Versionierung noch denken?

[%step]
* blah

=== Service lifetime

* link:../../src/main/resources/visualizeServiceAvailablity.html[Blah]

== Zusammenfassung

[%step]
. Explizite Versionierung ist notwendig
. Einen einfachen Service auswählen
. Ein Pattern auswählen und implementieren
. Ausprobieren
. dem Hackergarten Bern beitreten

== Vielen Dank

* Material
** https://github.com/ehmkah/service_versioning_example
** https://www.meetup.com/de-DE/Hackergarten-Bern/

=== Extension material

* http://blog.restcase.com/restful-api-versioning-insights/
* https://www.troyhunt.com/your-api-versioning-is-wrong-which-is/
* http://www.oracle.com/technetwork/articles/web-services-versioning-094384.html
* https://www.ibm.com/developerworks/webservices/library/ws-version/#1



{'fraction_non_alphanumeric': 0.07321918456153628, 'fraction_numerical': 0.0030271497493141613, 'mean_word_length': 5.574626865671642, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 7, 'https://': 9, 'lorem ipsum': 0, 'www.': 9, 'xml': 0}, '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': '3931325', 'n_tokens_mistral': 3424, 'n_tokens_neox': 3485, 'n_words': 1108}