pantrag_fiae Projektantrag: Entwicklung eines Werkzeugs zur Datenmigration sowie Anbindung der neues Datenbank via REST Schnittstelle

[0x00]

Nachdem mein altes Thema laut euch zu FISI-lastig war, habe ich es nochmal umformuliert. Ja, das Thema ist mehr oder weniger immer noch das selbe, allerdings ist es jetzt deutlich programmierlastiger. Würde mich über Feedback freuen^^

---

Geplanter Bearbeitungszeitraum

30. März - 17. April 2020

Ist-Analyse

Die XXX bietet das gleichnamige Dokumentenmanagementsystem sowohl als installierbares On-Premises System als auch als Cloudlösung an. Wenn ein neues On-Premises System installiert, oder ein Bestehendes modifiziert, werden soll geschieht dies über das XXX Setup. Nach jedem Lauf schickt das Setup Metadaten in Form einer .xml-Datei an XXX. Darin sind Information über das Kundensystem und die Installation enthalten, wie zum Beispiel die Kunden ID oder das Installationsdatum. Sollte das Setup fehlgeschlagen sein, kommen zusätzlich zur .xml-Datei noch .log-Dateien hinzu.

Diese Daten werden noch von XXX in einer Azure Ressource als Blob (Binary Large Object) Storage gespeichert, welche mithilfe von Azure Classic Deployment erstellt wurde. Jedoch wird Azure Classic Deployment von Microsoft nicht mehr unterstützt und es wird empfohlen bestehende Azure Ressource nauf den Azure Resoure Manager zu migrieren. Des Weiteren ist das bestehende System aufgrund von Konzeptentscheidungen nicht performant genug um für interne Analysezwecke genutzt zu werden.

Soll-Konzept

Die existierenden .xml- und .log-Dateien, welche in einer, mithilfe von Azure Classic Deployment erstellten, Blob Storage gespeichert wurden, sollen auf den Azure Resource Manager umgezogen werden. Der Azure Resource Manager ist hierbei aufgrund der Projektvorgaben alternativlos.

Als erstes muss eine neue Azure Ressource angelegt werden. Danach muss eine geeignete Datenbank gefunden werden, wobei geprüft werden soll welcher Datenbanktyp hier den geeignetsten darstellt. Für diese Datenbank muss daraufhin ein Konzept erstellt und implementiert werden.

Sobald dies geschehen und die Datenbank bereit für die Migration ist muss das Migrationswerkzeug entwickelt werden. Hier müssen, je nach gewählter Datenbank, die Dateien nicht nur umgezogen, sondern auch ausgelesen und verändert werden.

Da das XXX Setup die Daten immer noch an den alten Speicherort sendet reicht es nicht, wenn das Werkzeug einmal ausgeführt wird. Deswegen soll das Werkzeug automatisiert per Zeitsteuerung regelmäßig gestartet werden. Das Setup anzupassen ist hierbei keine Option, da dies in das Aufgabengebiet eines anderen Teams innerhalb der Entwicklungsabteilung fällt.

Schlussendlich muss die Datenbank noch eine REST (REpresentational State Transfer)-Schnittstelle bekommen, soddas die Daten automatisiert ausgelesen werden können.

Projektumfeld

Die XXX bietet das gleichnamige Dokumentenmanagementsystem in X Sprachen für über XX Kunden in über X Ländern an. XXX ist sowohl als On-Premises System, als auch als Cloudlösung erhältlich, wobei etwa X% der Neukunden die Cloudlösung wählen.

Das Setup für die On-Premises Systeme wird von der Entwicklungsabteilung entwickelt und gepflegt, welche auch für die kontinierliche Weiterentwicklung und Verbesserung, sowie das Testen von XXX verantwortlich ist. Innerhalb der Entwicklungsabteilung wird auch dieses Projekt stattfinden

Zeitplan

Projektteil	Schritt	Zeit in h
Analyse Ist-Zustand	Analyse Ist-Zustand	1
Aufstellen Soll-Konzept	Anforderungsanalyse	2
	Vergleich von Datenbanken	2
	Konzepterstellung für die Datenbank	2
Konfiguration	Aufsetzen der Datenbank	1
	Aufsetzen der Testumgebung	1
Entwicklung des Migrationswerkzeugs	Implementierung	5
	Unit Tests	8
	Integration Tests	4
	End-To-End Tests	4
	Bau einer Releasepipeline	5
REST-Schnittstelle	Implementierung	5
	Unit Tests	8
	Integration Tests	4
	End-To-End Tests	2
Dokumentation	Projektdokumentation	10
	Codedokumentation	4
Sonstiges	Puffer	2
Gesamt		70

[charmanta]

Tonnenweise Kommafehler. Inhaltlich nicht mein Thema, da halte ich mich raus. Mein Gefühl ist aber gespalten ... ich lese immer noch FiSi zwischen den Zeilen, zumindest teilweise.

Ist das nicht was für @stefan.macke ?

[Visar]

In aller erdenklichen Kürze: Taugt meines Erachtens weiterhin nichts, das Projekt und der zugehörige Plan sind Mist.

Entscheidungen im kaufmännischen Sinne sehe ich da nicht. Gar nicht.
Da wird nix evaluiert, bewertet, da wird stumpf abgearbeitet weil muss.

Das zweite, noch größere Problem:

10 Stunden Implementierung rechtfertigen keine 30 Stunden Tests.

Wenn es anders herum wäre, hätte ich bei Draufsicht weniger Bauchschmerzen.
Ich weiß auch gar nicht, wo die ganzen Testcases herkommen sollen, wenn fast nichts programmiert wird. Das liest sich so als würdest du einfach 1000 Bibliotheken und Frameworks einbinden und testen wollen. Das ist allerdings nicht Sinn der Übung.

Bearbeitet 27. März 2020 von Visar

[0x00]

Danke euch beiden schonmal für eure Einschätzung. 

vor 29 Minuten schrieb Visar:

Entscheidungen im kaufmännischen Sinne sehe ich da nicht. Gar nicht.
Da wird nix evaluiert, bewertet, da wird stumpf abgearbeitet weil muss.

Naja zumindest bei den Datenbanken gibt es einen (auf Azure beschränkten Vergleich). Den Punkt versteh ich jedoch noch relativ gut.

vor 23 Minuten schrieb Visar:

10 Stunden Implementierung rechtfertigen keine 30 Stunden Tests.

Wenn es anders herum wäre, hätte ich bei Draufsicht weniger Bauchschmerzen.

Das hier kann ich persönlich nicht nachvollziehen, gerade bei einer Komponente, welche mit Kundendaten arbeitet. Okay, vielleicht ist das Verhältnis ein wenig zu hoch, aber bei mir nehmen die Tests immer mehr Zeit ein, als die eigentlich Implementierung. 

Mit dem umgekehrten Verhältnis, hätte ich persönlich starke Bauchschmerzen, da so ja gar nicht alles (wichtige) getestet werden kann. Ist aber glaube ich eher eine Grundsatzdiskussion. Vielleicht wäre hier das Verhältnis 15:10 statt 3:1 (Tests:Implementierung) besser gewesen, aber für mich hat es sich so richtig angefühlt. Wenn es gut getestet ist spart mir das hinterher Arbeit mit Bugs fixen usw.

Aus aktuellem Mangel an Alternativen, werde ich das Projekt jetzt trotzdem mal abschicken. Sollte es abgelehnt werden, habe ich zumindest die Kritikpunkte und kann dann dementsprechend dieses Projekt anpassen. Im schlimmsten Fall muss halt doch irgendwie was ganz anderes her.

[MartinSt]

Ich würde ja gerne mal live sehen, wie Du in 2 Stunden bspw. PostgreSQL, Oracle und MySQL vergleichst.

[Visar]

vor 18 Stunden schrieb 0x00:

Naja zumindest bei den Datenbanken gibt es einen (auf Azure beschränkten Vergleich). Den Punkt versteh ich jedoch noch relativ gut.

Aus der Beschreibung des Vergleichs geht allerdings nicht hervor, dass die unterschiedlichen Typen ggf. auch unterschiedliche Kosten verursachen, die im Projektkontext irgendeine Relevanz haben könnten. Es las sich mehr nach: Du hast einen Resource Manager und musst kurz überlegen, ob du auf A oder B klickst, was du gerade eben lieber hast. Interessant wäre dagegen, ob es in Azure auch Möglichkeit von NoSQL-Datenbanken wie z.B. Redis gibt oder du zwingend auf eine relationale Datenbank setzen musst. Da könnte bestimmt vieles zu geschrieben werden, aber kaum in den vom Vorredner bereits angesprochenen zwei Stunden ...

vor 18 Stunden schrieb 0x00:

Das hier kann ich persönlich nicht nachvollziehen, gerade bei einer Komponente, welche mit Kundendaten arbeitet. Okay, vielleicht ist das Verhältnis ein wenig zu hoch, aber bei mir nehmen die Tests immer mehr Zeit ein, als die eigentlich Implementierung. 

Im Grunde genommen kann ich den Gedanken ja verstehen, du möchtest deine Komponente auf Herz und Nieren prüfen, bevor das produktiv geht. Auf der anderen Seite bist du eben Anwendungsentwickler und nicht bloß Software-Tester. Die veranschlagte Zeit für die Implementierung ist derart dünn, dass ich mich auch frage, worüber du in deiner Projektdokumentation großartig schreiben möchtest. Immerhin geht fast die Hälfte deiner Bearbeitungszeit für Tests drauf.

Ich glaube die IHK wird dich nicht steinigen, wenn du etwas komplexes entwickelst und aus Zeitmangel ein paar Tests weglassen musst. Wenn du am Ende aber bloß zwei kleine Skripts schreibst und da dann 50.000 Tests drüberjagst, nur weil Kundendaten involviert sind ... ich weiß ja nicht. Vor allem: Es ist eine Migration. 

Und zu Migrationen gibt es von Microsoft auch Anleitungen. Woher weiß ich jetzt, dass deine "Implementierung" nicht bloß im Hintergrund das ausführt, was User auch in der GUI zusammen klicken könnte? Ich meine... Technical deep dive on platform-supported migration from classic to Azure Resource Manager. Das ist jetzt sicher nicht zu 50% oder 100% das, worum es hier geht, aber... du verstehst...

Das Projekt will in der Form auf mich einfach nicht so wirken als wäre es geeignet.

 

[0x00]

Habs nochmal leicht überarbeitet und abgegeben. Was ich gemacht habe, ist 10h von den Tests wegzunehmen und neu zu verteilen (u.a. Wahl der Datenbank von 2h auf 8h). Die NoSql Datenbanken wollte ich hier abhandeln, allerdings habe ich das hier zu spät gelesen und nicht mehr explizit in den Antrag geschrieben...

Jetzt heißt es erstmal aufs Feedback der IHK warten. Wenn das denen auch so gar nicht taugt, kann ich ja mal die Augen und Ohren offenhalten, ob ich was besseres finde^^

[0x00]

Die IHK hat das Projekt ohne Murren angenommen. Danke euch für euer Feedback, ich bin mir sicher ohne eure Vorschläge wäre das nicht so durchgegangen 👍