Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- wiki:software:beuthbot:berichte:ws2020:zwischen:geplanter-stand-preambel [22.11.2020 20:13]
Dennis Walz [Präambel]
+++ wiki:software:beuthbot:berichte:ws2020:zwischen:geplanter-stand-preambel [25.11.2020 02:12] (aktuell)
Lukas Danke
@@ Zeile 2: / Zeile 2: @@
 ===== Präambel =====
-Neben einigen wünschen der Projektleitung konnte die Projektgruppe eigene Schwerpunkte in die Feature Planung einbringen. Die nachfolgende Feature-Planung ist ein resultat der folgenden Überlegungen
+Neben einigen Wünschen der Projektleitung konnte die Projektgruppe eigene Schwerpunkte in die Feature Planung einbringen. Die kommende Feature-Planung ist ein Resultat der folgenden Überlegungen
 ==== Content First ====
-Der BHT-Bot besteht bisher aus lediglich zwei Services, die Content zur Verfügung stellen: Mensa- und Wetter-Service. Aufgrund der Covid19-Pandemie findet keine Präsenzveranstaltungen an der Hochschule statt und in Folge dessen hat die Mensa geschlossen, der Bot-Service ist entsprechend auch eingestellt. Defakto kann der BHT-Bot damit derzeit ausschließlich das Wetter ansagen. Für uns ist es daher umso wichtiger dieses Semester neuen Content zu erzeugen bzw. nutzbare Features in den BHT-Bot zu integrieren, damit dieses Projekt überhaupt eine Daseinsberechtigung bekommt.
+Der BHT-Bot besteht bisher aus lediglich zwei Services, die Content zur Verfügung stellen: Mensa- und Wetter-Service. Aufgrund der Covid19-Pandemie finden keine Präsenzveranstaltungen an der Hochschule statt und in Folge dessen hat die Mensa geschlossen, der Bot-Service ist entsprechend auch eingestellt. Defakto kann der BHT-Bot damit derzeit ausschließlich das Wetter ansagen. Für uns ist es daher umso wichtiger dieses Semester neuen Content zu erzeugen bzw. nutzbare Features in den BHT-Bot zu integrieren, damit dieses Projekt überhaupt eine Daseinsberechtigung bekommt.
+==== Hands-On & Dokumentation ====
+Wenn man neu in ein Projekt kommt gibt es viel Dokumentation aufzuarbeiten, als auch undokumentierte Zustände zu entdecken. Wir hatten Gelegenheit den BHT-Bot in einem Hands-On Workshop von Lukas Dankwerth aus SoSe2020 vorgestellt zu bekommen. Im Workshop haben wir uns neben all dem Guten, was die letzten Semester geschaffen haben (danke vor allem für die docker-compose zentralisierung der infrastruktur!) beispielsweise angeschaut a) Warum der Bot eine Telegram-ID braucht in allen Requests b) Dass der Bot derzeit zwei fast identische Datenbankservices hat, die zusammengeführt werden könnten c) Dass die Services derzeit inkonsistenzen aufweisen, die bis zu essentiellen Debugging-Strategien wie der Request-History reichen, die nicht gepflegt wurde d) Dass Dokumentation auf verschiedene Projekte und Plattformen verteilt wurde.
+Ohne einen persönliche Hands-On-Workshop ist eins der größten Probleme um ins Projekt zu finden, dass es verschiedene Stellen gibt, an denen Dokumentation, Code, Infrastruktur, etc. verteilt ist, aber keine zentrale Stelle, die als "Single Point of truth" registerartig auf die weiteren Quellen verweist.
+Wir wollen diese Situation verbessern, indem wir falsche und für uns nicht-nachvollziehbare Dokumentation verbessern, Wikistrukturen bereinigen, eine Landing-Page für den Bot unter einer zentralen Bot-Domain verfügbar machen und Abläufe und Strukturen in Code gießen.
 ==== Redundanter Code / Wartbarkeit der Microservices ====
 Beim Studium der einzelnen Services wurde sichtbar, dass fast ausnahmslos jeder Service des BHT-Bot die gleiche Grundstruktur hat: Alle Services stellen eine JSON-REST-Schnittstelle zur Verfügung, die via NodeJS + Express Framework implementiert ist. Vergleicht man die Services, sieht man, dass insbesondere Services, die Inhalte ausspielen sollen einer identischen Struktur folgen (müssen), dies aber individuell handhaben. Dadurch ist der Boilerplate Code für jeden Service unnötig hoch und zugleich ist das Warten der Services bei Änderung von globalen Schnittstellen mit hohem individuellen Aufwand verbunden. Wir wollen diese Common-Funktionalitäten identifizieren und in zentralen Bibliotheken bzw. Frameworks bündeln.
+Bei allem was wir tun und Planen gilt die alte Pfadfinder-Regel: "Hinterlasse das Camp immer aufgeräumter, als du es vorgefunden hast". Das beinhalte tbeispielsweise auch die Wartung bzw. Updates von bestehenden Dependencies wie express-js oder Rasa-NLP.
 ==== Qualitätsmanagement ====
@@ Zeile 18: / Zeile 27: @@
   - Releases werden durch Versionierte Git Tags erzeugt (und dann automatisch deployed) - Die Tags werden semantisch versioniert
   - Neue Features werden via Pull Request in das Repository übernommen. Nach Möglichkeit werden die Requests durch ein Projektmitglied reviewd und freigegeben
-==== Hands-On & Dokumentation ====
-FIXME
 ===== Übersicht geplante Tasks und Abhängigkeiten =====
 {{page>:wiki:software:beuthbot:berichte:ws2020:zwischen:geplanter-stand-tabelle}}
+{{ :wiki:software:beuthbot:berichte:ws2020:zwischen:gantt_final.png |}}
 ===== Architektur =====
-{{page>:wiki:software:beuthbot:berichte:ws2020:zwischen:geplanter-stand-diagramm}}
+Die Architektur-Entscheidungen orientieren sich an der bisherigen Infrastruktur. Durch die Verwendung der gleichen Programmiersprachen und Technologien wird Wartbarkeit gewährleistet und insbesondere die Abstraktion von Common-Funktionalitäten in Libraries begünstiget.
+Dies bedeutet für den BHT-Bot:
+  * Alle Features werden als Microservice-Architektur konzipiert
+  * Microservices werden via Docker Container betrieben
+  * Docker Container werden via docker-compose orchestriert
+  * Microservices kommunizieren via REST-Schnittstellen innerhalb des Docker-Network
+  * Services werden in Javascript geschrieben
+  * Libraries und Frameworks werden in Typescript geschrieben
+{{page>:wiki:software:beuthbot:berichte:ws2020:zwischen:geplanter-stand-diagramm}}
+<pagebreak>
 ===== Aufgaben Spezifikation =====
 {{page>:wiki:software:beuthbot:berichte:ws2020:zwischen:geplanter-stand-features}}

wiki.ziemers.de

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge