Verschiedene entities für gleichen Code….

[Thallius]

die Überschrift ist vielleicht etwas verwirrend. Also muss ich weiter ausholen.

Die Firma für dich ich mehrere Apps erstellt habe stellt nun ihr CMS um auf Service Max. Ich habe nun die aufgabe mein Interface zum CMS an SMax anzupassen. Erstmal soweit kein Problem. Im Prinzip gibt es eine API der ich die Daten in Form von JSON Objekten übergebe. Diese sind relativ komplex Da viele Werte übergeben werden. ich habe nun also z.b. eine Klasse Case erstellt, welche Attribute enthält, welche den benötigen Werten entspricht.
um nun einen Case in SMax zu erzeugen erzeuge ich eine Instanz der Klasse Case, fülle sie mit den daten, erzeuge mit einem object wrapper daraus einen JSON String und verschicke ihn an die API.
Das funktioniert auf dem Test-Server einwandfrei. Nun stehen wir unmittelbar vor der Release und wir haben den Prod-Server bekommen.
Also normalerweise einfach nur API URL, credentials etc ändern und alles fertig….

Aber da habe ich die Rechnung ohne unsere globale IT gemacht. Fragt mich nicht was die sich dabei gedacht haben aber tatsächlich werden einige Attribute plötzlich nicht mehr benötigt, bzw. es gibt sie gar nicht mehr. Andere wiederum heißen plötzlich anders…..

ich muss nun also theoretisch unterschiedlich Klassen für unterschiedliche Server haben. Klar kann man machen. Hat man halt zwei unterschiedliche interfaces in ein und dem selben Code. Aber irgendwie widerstrebt mir das.

ich fände es schöner, wenn ich beim Build einfach entweder die einen oder die anderen Klassen ins .jar linke. Ist da die einzige Möglichkeit das ich die Klassen in ein jeweils eigenes Framework packe und je nach Build mit maven unterschiedliche .jar Abhängigkeiten einbinde? Oder habt ihr noch eine Idee wie man das machen kann ohne mehrere „Projekte“ daraus machen zu müssen, so dass es im Endeffekt ein Repository mit einer maven Datei bleibt?

 

[mihe7]

Was funktionieren sollte:
1. https://www.baeldung.com/maven-project-multiple-src-directories
2. Und das mit Profiles steuern.

 

[Thallius]

Sieht auf den ersten Blick aus wie das was ich brauche.

danke

 

[kneitzel]

Also ich würde erst einmal zumindest darauf hinweisen, dass das Test System so absolut wertlos ist. Eigentlich bei allen Tests kann es sein, dass es in Produktion Probleme gibt.

Aber generell würde ich mir hier überlegen, wie man das kapseln kann. Ich denke da immer gerne an kleine Web Services, die da als Wrapper dienen. Damit hast Du einmal eine saubere API für Dich definiert, die Du dann ansprechen kannst. Fehler sind dann in einem (hoffentlich nicht zu komplexen) Bereich, die dann hoffentlich auch in Produktion schnell "getestet" sind. Hintergrund hier ist halt auch die Erfahrung, dass so Dinge dann auch gerne von Anderen benutzt werden - saubere Schnittstellen lieben ja alle 🙂

Wenn ein eigener Web Service dafür nicht gewünscht ist, dann wäre das aber dennoch vom eigentlichen Projekt abgekapselt. Alleine schon um sicher zu gehen, was für Änderungen da ungetestet in Produktion gehen (weil ja Test unterschiedlich ist!)
Und auf unterschiedliche Server zugreifen - da sehe ich direkt Parallelen: JDBC. Da würde ich das 1:1 aufbauen. Also auch mit den entsprechenden Services. Dann kann da die korrekte jar Datei in den Classpath gelegt werden und schon funktioniert der Zugriff.

 

[kneitzel]

Was funktionieren sollte:
1. https://www.baeldung.com/maven-project-multiple-src-directories
2. Und das mit Profiles steuern.

Wie sind da Deine Erfahrungen? Ich hätte da Bauchschmerzen, einen Build in Produktion zu geben, den ich nicht getestet habe. Ein (komplett) anderer Build war im Test. Da waren halt nur irgendwelche Source Pfade und natürlich die meisten Projekt Settings gleich. Oder ist das eine Form der Paranoia von jemandem, der in einem Projekt arbeitet, wo nichts raus geht, wo eben nicht ein Wochenende lang extrem viele Regression Tests (auf Production Like Systemen - also 1:1 gleiche Software Versionen und so) durchgelaufen sind. Und die Probleme, die selbst kleine Änderungen mit sich bringen bei z.B. Datenbank Updates / Fixes mit auftreten können ...)

 

[Thallius]

Also ich würde erst einmal zumindest darauf hinweisen, dass das Test System so absolut wertlos ist. Eigentlich bei allen Tests kann es sein, dass es in Produktion Probleme gibt.

Tja, so ist das halt wenn die individuellen Anpassungen des CMS an die Firma von einem Team aus Projektleitern und jede Menge Indern gemacht wird… Die Release wurde jetzt schon insgesammt um knapp 2 Jahre verschoben und das Management hat jetzt langsam die Schauze voll also muss es fertig werden. Und da jede Änderung ja eine Riesen Rattenschwanz von, erstmal definieren, dann ausformulieren, dann pflichtenheft für den Inder schreiben, dann programmieren, dann Tests schreiben, dann testen und dann ab in die QC hinter sich herzieht dauert jede Änderung um die 3 Monate.…

Aber generell würde ich mir hier überlegen, wie man das kapseln kann. Ich denke da immer gerne an kleine Web Services, die da als Wrapper dienen. Damit hast Du einmal eine saubere API für Dich definiert, die Du dann ansprechen kannst. Fehler sind dann in einem (hoffentlich nicht zu komplexen) Bereich, die dann hoffentlich auch in Produktion schnell "getestet" sind. Hintergrund hier ist halt auch die Erfahrung, dass so Dinge dann auch gerne von Anderen benutzt werden - saubere Schnittstellen lieben ja alle 🙂

Ist halt auch wieder ein Frage des Verwaltungaufwandes. Für jede neue „eigenständige“ Applikation (und das wäre ein eigener webservice ja dann) muss ein eigener server angefordert, installiert, bezahlt und gewartet werden. Jede App muss angemeldet werden, muss durch die Cyber Security Tests Validiert werden wegen ISO27001 etc etc….

Wenn ein eigener Web Service dafür nicht gewünscht ist, dann wäre das aber dennoch vom eigentlichen Projekt abgekapselt. Alleine schon um sicher zu gehen, was für Änderungen da ungetestet in Produktion gehen (weil ja Test unterschiedlich ist!)
Und auf unterschiedliche Server zugreifen - da sehe ich direkt Parallelen: JDBC. Da würde ich das 1:1 aufbauen. Also auch mit den entsprechenden Services. Dann kann da die korrekte jar Datei in den Classpath gelegt werden und schon funktioniert der Zugriff.

In Mihe seiner Lösung wäre es halt auf Sourcecode Ebene gekapselt was ich eigentlich ok finde.

 

[Thallius]

Wie sind da Deine Erfahrungen? Ich hätte da Bauchschmerzen, einen Build in Produktion zu geben, den ich nicht getestet habe. Ein (komplett) anderer Build war im Test. Da waren halt nur irgendwelche Source Pfade und natürlich die meisten Projekt Settings gleich. Oder ist das eine Form der Paranoia von jemandem, der in einem Projekt arbeitet, wo nichts raus geht, wo eben nicht ein Wochenende lang extrem viele Regression Tests (auf Production Like Systemen - also 1:1 gleiche Software Versionen und so) durchgelaufen sind. Und die Probleme, die selbst kleine Änderungen mit sich bringen bei z.B. Datenbank Updates / Fixes mit auftreten können ...)

da bin ich deutlich schmetzbefreiter. Ich definiere vor einem deploy immer den worse case Und kann daraus das Risiko abschätzen.
in diesem Fall wäre der worse case. Dass das erstellen der cases z.b. fehlschlagen würde Was aber direkt dem User mit einem Fehler quittiert würde. Mehr als das der User unglücklich ist das es nicht geklappt hat kann aber nicht passieren 🙂

 

[mihe7]

Wie sind da Deine Erfahrungen?

Ich habe mit 1. gar keine Erfahrungen, sondern - da in Maven ja Convention over Configuration gilt - mir gedacht, dass es ja eine Möglichkeit geben wird, mehrere Source-Dirs anzugeben -> Google -> Baeldung.

Mit 2. habe ich durchaus Erfahrungen - im Zusammenhang mit Libs, Plugins und CI. Das funktioniert sehr gut.

 

[mrBrown]

Was ist denn der Test-Server für ein Server? Auch von der zentralen IT bereit gestellt und muss die gleichen Anforderungen erfüllen wie jeder andere Anwendung oder sind die dort lascher?
Dann könnte man dort u.U. die gleiche API bereitstellen, die der Prod-Server bietet.


Tests gegen extra Code-Basis laufen zu lassen bringt im wesentlichen halt gar nichts und ist im Worst-Case nur negativ. Da kann man meinst besser einfach drauf verzichten.
Wenn man da wirklich keine Möglichkeit hat, die APIs anzugleichen, würde ich nur den gemeinsamen Teil testen und es soweit abstrahieren, dass der nicht-getestete Code auf ein Minimum reduziert ist. Interfaces für beide APIs wäre ein eine Möglichkeit, dass umzusetzen.

Getrennte Sourcen für test und Prod bringt eigentlich nur Nachteile und sollte immer vermieden werden...