Jump to content

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

Empfohlene Beiträge

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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 von Visar

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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.

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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^^

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Nimm an der Diskussion teil

Du kannst jetzt hier posten und Dich später registrieren. Wenn Du bereits über eine Konto verfügst, melde Dich jetzt an, um mit Deinem Konto zu posten.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.


Fachinformatiker.de, 2020 SE Internet Services

fidelogo_small.png

if_icon-6-mail-envelope-closed_314900.pnSchicken Sie uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App


Get it on Google Play

Kontakt

Hier werben?
Oder senden Sie eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...

Wichtige Information

Fachinformatiker.de verwendet Cookies. Mehr dazu in unserer Datenschutzerklärung