Zum Inhalt springen

Projektantrag: Wahl und Konfiguration eines geeigneten Speichersystems für Metadaten von Kundensystemen und Entwicklung eines Migrationstools


 Teilen

Empfohlene Beiträge

Geplanter Bearbeitungszeitraum

23. März - 17. April 2020

Projektbeschreibung
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 Besthendes modifiziert werden soll, passiert das über das XXX Setup. Nach jedem Lauf schickt das Setup Metadaten in Form einer .xml-Datei an XXX. Darin sind Informationen über das Kundensystem und die Installation enthalten, wie zum Beispiel die Kunden ID oder das Installationsdatum. Sollte das Setup gehlgeschlagen sein, kommen zusätzlich zur .xml-Datei noch .log-Dateien hinzu.
Diese Daten werden von XXX in einer Azure Resource als Blob (Binary Large Object) Storage gespeichert, welche mithilfe von Azure Classic Deployment erstellt wurde. Jedoch wird Azure Classic Deployment von Microsoft nicht mehr untersützt und es wird empfohle bestehende Azure Ressourcen auf den Azure Resource Manager zu migrieren. Desweiteren ist die bestehende Azure Ressource nicht performant genug um für interne Analysezwecke genutzt zu werden.

Soll-Konzept

Unter wirtschaftlichen und datenschutzrechtlichen Gesichtspunkten soll nun ein neuer Speicher für bestehende und zukünftige Daten gefunden werden. Dies beeinhaltet sowohl die Wahl des Speichers an sich, als auch die Wahl einer geeigneten Datenbank. Weitere Auswahlkriterien sind die Performanz und eventuelle API-Anbindungen um eine Grundlage für eine spätere automatisierte Analyse zu bilden.
Im zweiten Schritt soll dann der neue Speicher und die neue Datenbank so aufgesetzt und konfiguriert werden, dass die Datenmigration beginnen kann. Schlussendlich muss noch ein Werkzeug geschrieben werden, welches bestehende Daten auf das neue System migriert. Dieses Werkzeug muss nicht nur einmalig alle Daten transferieren, sondern in regelmäßigen Zeitabständen ausgeführt werden, da das XXX Setup die Daten weiterhin an den alten Speicherort senden wird.

Projektumfeld

Die XXX bietet das gleichnamige Dokumentenmanagementsystem in X Sprachen für über XXX Kunden in über XX Ländern an. XXX ist sowohl als On-Premises Syswtem, als auch als Cloudlösung erhältlich, wobei in etwa 2/3 der Neukunden die Cloudlösung wählen.
Das Setup für die On-Premises Systeme wird von der Entwicklungsabteilung entwickelt und gepflegt, welche auf für die kontinuierliche Weiterentwicklung und Verbesserung, sowie das Testen von XXX verantwortlich ist. Innerhalb der Entwicklungsabteilung wird auch dieses Projekt durchgeführt werden.

Zeitplan

Analyse Ist-Zustand Analyse Ist-Zustand 1
Aufstellen Soll-Konzept Anforderungsanalyse 3
  Konzepterstellung 4
Projektplanung Auswahl einer geeigneten Speichermöglichkeit (inkl. Storage und Datenbank) 8
Aufsetzen der Umgebung Aufsetzen der Storage 2
  Aufsetzen der Datenbank 2
  Aufsetzen einer Testumgebung 2
Schreiben des Tools Implementierung 8
  Unit Tests 10
  Integration Tests 5
  Automatisierte End-To-End Tests in der Testumgebung 5
  Bau einer Releasepipeline 5
Dokumentation
Schreiben der Projektdokumentation
10
 
Schreiben der Codedokumentation
4
Sonstiges Puffer 1

 

Würde mich wahnsinnig über ein wenig Feedback freuen ^.^

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Die Auswahl des Systems war eher gedacht, um den kaufmännischen Aspekt abzudecken. Wenn ich das Projekt unformulieren würde in Migration auf Azure Resource Manager und mich auf Aufsetzen der Datenbank und Schreiben des Migrationstools konzentrieren würde, dann hätte ich bessere Karten? 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Du implementierst 8 Stunden (+ 5 Stunden für die Pipeline) und willst das dann 20 Stunden lang testen?

Nee.

An deiner Stelle würde ich mir etwas suchen, wo du zwischen die 30 bis 40 Stunden mit der Implementierung beschäftigt bist. Aber gerne im Azure-Umfeld, denn ich denke, dass alles rund ums Thema Cloud immer noch verhältnismäßig gut ankommt.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Habe soeben mit meinem Ausbilder Rücksprache gehalten und der meinte man könne das Projekt ja leicht anpassen. Die Idee ist es, die Auswahl der Storage rausfallen zulassen (Migration auf X wird zu Migration auf MSSQL Datenbank auf dem Azure Resource Manager). Dafür wird hinterher noch eine (REST-)API für die neue Datenbank geschrieben.

Prinzipiell finde ich die Idee ziemlich gut, allerdings weiß ich nicht, ob es Probleme geben könnte, wenn ich einfach sage "Wir ziehen auf Azure Resource Manager und MSSQL" um, ohne einen Vergleich zu machen. Könnte das ein Ablehnungsgrund sein? Bzw. gibt es eine Möglichkeit das "IHK-verträglich" zu verpacken?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

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

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

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

 Teilen

Fachinformatiker.de, 2022 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

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

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende 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