Hi, zum Ende meiner Ausbildung reicht es jetzt doch nicht immer nur hier zu lesen sondern auch mal eine Frage zu stellen  

Unsere Firma "macht ihr Geld" zu einem großen Teil durch Entwicklung von Portallösungen für Kunden. Die FISI-Kollegen und ich sind eher im DEVOPS und Support-Bereich tätig. Der Abteilungsleiter (nicht mein Ausbilder) der Entwicklungsabteilung hat mich nun gefragt ob ich denn für mein Abschlussprojekt eine Lösung finden kann für das automatisierte Frontend-Testing der Webanwendungen (produktiv Webanwendungen) - diese sollen regelmäßig oder basierend auf Events aus dem CI/CD-Prozess angestoßen werden und am Ende sollen Reports (z.B.) per Mail herauspurzeln. 

Er stellt sich so etwas vor wie Screenshot der Seiten, Datum des gelaufenen Tests, Antwortzeit der Webanwendungen usw. 

Mein Ausbilder meinte er hätte das Thema eher bei einem FIAE gesehen aber wenn ich darauf Lust hätte könnte ich es doch damit versuchen.

Mich persönlich motiviert dabei das es ein echtes Projekt wäre und echten Mehrwert generieren würde.

Bei meiner Recherche habe ich schon Dinge wie Ansible gefunden also vermutlich müsste ich solche Lösungen heraussuchen, diese vergleichen basierend darauf eine Entscheidung treffen und die finale Lösung dann vorallem konfigurieren, in den CI/CD-Prozess einklinken.

Kann das ein gutes FISI Projekt sein oder soll ich wie mein Ausbilder sagt eher die Finger davon lassen? Eine Meinung von den erfahrenen Leuten würde mich interessieren. 

Ohne formulierten Antrag ist das schwer zu sagen. Es kling aber wirklich für FiSi ungeeignet

Ist das Testen selbst schon ein Teil der CI/CD Pipeline? 
Es gibt verschiedene Anbieter, die das Testen von Web Oberflächen anbieten. Hierfür müsste aber das Produkt während die Pipeline läuft von außen erreichbar sein. Man könnte dies auch innerhalb der eigenen Infrastruktur abbilden, doch ist hier der Programieranteil relativ hoch.

Das Finden von Fehlern bevor das Produkt ein Kunde erreicht ist sicherlich ein guter Zeitpunkt einen Fehler zu finden, doch ist es schwer eine halbwegs genaue wirtschaftliche Betrachtung zu machen.

Beim ersten Gedanken hätte ich das Projekt eher bei einem FIAE gesehen.

Mir sind hier zu viele Begriffe durcheinander gewürfelt (Docker, CI/CD, Pipeline, Ansible, Tests, ...) um mir etwas konkret vorstellen zu können. Trotzdem folgend meine Gedanken.

Ich weiß jetzt ja nicht was für ein Tooling ihr habt aber je nachdem ob man GitLab oder GitHub einsetzt ist die ganze Docker-Geschichte mit integriert (bei GitLab muss man halt noch einen Docker-Runner installieren/konfigurieren). Bei GitHub läuft soweit ich weiß eine Pipeline immer in einem Container. Wenn ihr Jenkins habt, müsst ihr das halt noch irgendwie bauen. Wenn ihr was anderes habt (Circle CI oder so) dann weiß ich nicht wie es damit aussieht. Das ist jetzt aber keine Sache von einer Woche sondern von wenigen Stunden. Ansonsten muss halt noch ein Server dafür aufgesetzt werden. Soweit so gut, hier sehe ich schon einen FISI.

Wo Ansible hier mit rein soll, verstehe ich noch nicht so ganz. Du kannst natürlich auch einen Server wohin stellen, auf dem per Ansible die Tests gestartet werden aber dann brauchst du eigentlich kein Docker mehr. Außer du startest die Tests dann dort in einem Docker, kannste aber auch mit SSH machen. Oder ich habe nicht ganz verstanden worauf du mit Ansible hinaus möchtest. Ansible macht vor allem dann Sinn, wenn du Konfigurationen auf mehreren Servern in einem Rutsch deployen möchtest. 

Kommen wir nun zu den Tests: Die Tests zu schreiben ist meiner Ansicht nach nicht der Job des FISI, sondern von den Entwicklern. Da von "Screenshots" geredet wird, nehme ich an, dass damit End-User- bzw. UI-Tests gemeint sind. Hier sehe ich einen Fisi nicht. Ich denke die Screenshots sind auch eher Dinge vom Testing-Framework? Das ganze dann in die Pipeline zu packen ja gut, dass ist halt ein Befehl um die Tests auszuführen. Hier sehe ich nicht die Komplexität.

Long story short: Wenn du jetzt einen Server installierst, dort dann Jenkins aufsetzt, noch irgendwo eine Docker-Umgebung aufbaust etc. hört es sich für mich schon irgendwie nach FISI an - wenn auch noch nicht ganz rund. Wenn du aber nur eine Pipeline schreibst, ist das für mich zu wenig fachliche Tiefe und ein FIAE-Thema. 

Danke für euer Feedback!

 

Zum Umfeld: 

Die jetzige Architektur ist ausgehend vom programmierten Code über GitLab in eine (produktiv) Docker-Umgebung. 
D.h. für Kunde X stehen dort je nach Geldbeutel Y Microservices mit 1-Z Instanzen seiner Webanwendung bereit. Diese Webanwendungen sollen nun "gemonitoret" werden - Sind sie erreichbar? Sehen Sie gut aus? Sieht die Seite Y mit Microservice X gut aus? Wie sehen die Seiten auf Mobile aus usw.

@Gooose

Also die Lösung müsste zeitlich NACH dem Deployment laufen, also nachdem Codeänderungen gemacht worden sind (und dementsprechend auch alle codeseitigen Tests der Entwickler gelaufen sind) - sozusagen als "finales Result" / "Outcome" für den Projektverantwortlichen.

Es geht erstmal nicht um codeseitig geschriebene Tests das wäre wirklich ein FIAE-Thema und da haben wir "FISI-Kollegen" auch bisher nichts damit am Hut. 

Ich selbst habe von Ansible immer nur gehört ich dachte das wäre eine Lösung dafür aber beim Googlen würde ich sagen das Puppeteer z.B. eine bessere Lösung wäre: Damit sollte man mit etwas konfiguration aurtomatisiert Screenshots von X URLs machen können und laut Feature-Liste das ganze auch für Mobile Devices. 

Heruntergebrochen: Eine Lösung wie Puppeteer über GitLab antriggern die jeweilige Produktivumgebung des Projektes anzusteuern, die definierten URLs zu überprüfen und die Screenshots z.B. per Mail an Projektverantwortlichen o.ä. schicken. 

Ich habe jetzt mal einen Grobentwurf für meine Projektplanung gemacht... 

 

Initialisierung: ~ 5 Stunden
1 Stunden: IST-Analyse
4 Stunden: SOLL-Konzept

Planungsphase: ~ 10 Stunden
2 Stunden: Suche von möglichen Lösungen
6 Stunden: Vergleich der möglichen Lösungen und Abgleich mit Soll-Konzept
2 Stunden: Zeitplanung und Erstellen von konkreten Tasks der finalen Lösung für die Durchführungsphase.

Durchführungsphase: ~15 Stunden
3 Stunden: "Lauffähig machen" - Lösung (am Besten) als Docker Container (weil alles andere ja ebenfalls in der Docker Umgebung läuft) zum Laufen bringen 
3 Stunden: Anbindung an GitLab und "Verknüpfung mit jeweiliger Produktivumgebung". (Pipeline anpassen, wie findet der Service die zu testenden URLs usw.)
4 Stunden: Feinkonfiguration -> Online/Offline Test, Desktop Test (Screenshots), Mobile Test (Screenshots)
2 Stunden: Reportgenerierung -> Anbindung an SMTP und Mailversand der Results / Screenshots
2 Stunden: Test
1 Stunde: Puffer für Unabsehbare Dinge

Dokumentationsphase: ~ 10 Stunden
1 Stunde Soll/Ist-Vergleich
1 Stunde Abnahme des Projekts
1 Stunde Wirtschaftlichkeitsprüfung
7 Dokumentation

 

Nur damit auch deutlich wird wo die Schwerpunkte liegen würden  

 

 

 

Bearbeitet 28. Januar 20232 j von ichmagkurkuma

vor 2 Stunden schrieb ichmagkurkuma:

Heruntergebrochen: Eine Lösung wie Puppeteer über GitLab antriggern die jeweilige Produktivumgebung des Projektes anzusteuern, die definierten URLs zu überprüfen und die Screenshots z.B. per Mail an Projektverantwortlichen o.ä. schicken. 

Oder du machst es richtig, mit echten Akzeptanztests mit bspw. Selenium ...

Aber wie auch immer, das wird nichts. Die Komplexität ist einfach nicht da. Die Zeitplanung deiner Durchführung ergibt keinen Sinn. Einen Container zu starten dauert keine 3 Stunden ebensowenig wie die gitlab Pipeline anzupassen. Dafür liegt das Hauptproblem hier offenbar auf der Erstellung von Tests bzw. "Feinkonfiguration". Möglich das es komplexer wird wenn man wirklich den puppeteer weg geht und irgendwem Screenshots schickt, aber wenn ich raten soll ist da an irgendeiner Stelle sowieso ein webdriver eingebunden und du hast eigentlich keinen sinnvollen Grund nicht selenium zu nutzen.

Warum in dem Projekt nicht das offensichtliche Problem angehen? Warum passieren diese Tests auf dem Produktivsystem? Im Entwurf ist zwar nur noch von gitlab die Rede aber an anderer Stelle wird Monitoring angesprochen, was genau ist das Ziel, welches Problem wird denn gelöst?

Mir ist die Umsetzung einfach zu viel FIAE. Einen Docker-Container bauen, Pipelines anpassen, ... Das ist mir eher FIAE als wirklich FISI. Natürlich gibt es bei DevOps immer Überschneidungen und dein Docker-Container bauen kann auch viel Linux beinhalten. Aber Grundsätzlich sehe ich einen FISI ganz klassich mehr darin Clients, Server und Netzwerke zu planen, umzusetzen und zu warten. Außerdem stehen ja schon alle Server, so dass du auch hier nicht ganz FISI-typisch einen Server planst und umsetzt...

Sehe ich auch so. ich empfehle eine anderes Thema

vor 16 Stunden schrieb ichmagkurkuma:

Er stellt sich so etwas vor wie Screenshot der Seiten, Datum des gelaufenen Tests, Antwortzeit der Webanwendungen usw. 

Für Monitoring gibt es andere Lösungen, wie beispielsweise InfluxDB in Verbindung mit Grafana. Bei nicht so komplexen Anwendungen kann man in Grafana ein Alerting einrichten, welches die Verantwortlichen informiert, wenn beispielsweise die Antwortzeiten einer Anwendung einen Schwellwert überschreiten. Zudem müssen aber auch die Metriken gesammelt werden.

vor 12 Stunden schrieb ichmagkurkuma:

Also die Lösung müsste zeitlich NACH dem Deployment laufen, also nachdem Codeänderungen gemacht worden sind (und dementsprechend auch alle codeseitigen Tests der Entwickler gelaufen sind) - sozusagen als "finales Result" / "Outcome" für den Projektverantwortlichen.

End to End Tests finden normalerweise vor dem Deployment statt, um zu verhindern das fehlerhafte Anwendungen ausgerollt werden. 

vor 12 Stunden schrieb ichmagkurkuma:

Diese Webanwendungen sollen nun "gemonitoret" werden - Sind sie erreichbar? Sehen Sie gut aus? Sieht die Seite Y mit Microservice X gut aus? Wie sehen die Seiten auf Mobile aus usw.

Wie willst du automatisiert feststellen ob etwas gut aussieht? Das geht vielleicht mit einem Machine Learning Ansatz, würde das Projekt sicherlich sprengen (von den Kosten mal abgesehen).

Was passiert, wenn in diesem generierten Reports Fehler festgestellt werden? Soll es dann ein Rollback geben?
Man könnte vorher auf ein Staging System deployen, die Screenshots machen, und erst nach Freigabe des Verantwortlichen deployen. 

Ich sehe es nicht, dass hieraus ein FISI Projekt wird.

Sehr schade... Ich werde kommende Woche mit meinem Ausbilder und dem Entwicklungsabteilungsleiter sprechen und dann meine Zweifel an dem Projektthema mitteilen. Als ich jetzt den groben Zeitplan geschrieben hatte, hab ich mich eigentlich immer mehr in das Thema "verliebt" und es wäre gerade mit Hinblick auf Übernahme nicht schlecht gewesen ein so "wirklich gebrauchtes" Projekt zu machen. 

@pr0gg3r

Da gebe ich dir Recht, da meine spätere Arbeitswelt bei diesem Unternehmen (hoffentlich) allerdings auch eher DevOps bezogen wäre, habe ich halt gehofft, dass ich mir auch so ein DevOps - Thema als Projekt nehmen könnte. 

 

@Gooose 

Diverse automatisierte Tests laufen von Seiten der Entwickler schon innerhalb der Pipeline. Danach erfolgen automatisierte Deployments auf Testumgebungen auf denen teilweise auch je nach Kunde von Hand getestet wird. Die Kunden und deren Mitarbeiten können allerdings innerhalb ihrer Webanwendungen diverse Dinge konfigurieren oder benutzen ggf. Teile der Anwendung die sich (möglicherweise für sie unerwartet) nach einigen Jahren verändern. Das Aussehen könnte man nur anhand von Screenshots (Desktop/Mobile) einigermaßen effizient überprüfen und DAS wäre eben die Lösung die das Projekt löst. Innerhalb jeder Webanwendung können die Kunden soviele Unterseiten erstellen (von denen die Entwickler letztendlich gar nichts wissen) das es sehr umständlich wäre das händisch regelmäßig / unregelmäßig zu überprüfen.  

Beispiel: Sie (Kunden) benutzen ein Slidermodul aber konfigurieren die den Slider beinhaltente Box zu groß und undynamisch so das auf Mobile der Slider zu groß für das Device ist. 

 

Wahrscheinlich habe ich durch meinen ersten Post ein paar Dinge hier etwas falsch rübergebracht.  

 

@charmanta

Könntest du dir denn vorstellen das so ein DevOps-Thema mit einem leicht verschobenen Fokus trotzdem ein mögliches Projekt wäre?

 

Ich weiß dass schon mal darüber gesprochen worden ist eventuell eine Alternative für den NGINX der in jedem Projekt verwendet wird zu suchen also hier vielleicht die genauen Anforderungen sich zu besorgen und dann dafür eine bessere Alternative zu finden: Traefik oder Kong oder oder oder miteinander zu vergleichen und eine Auswahl anhand der Anforderungen zu treffen und diesen innerhalb des Microservices-Verbund dann einzubinden. (Wir wären dann aber immernoch in der gleichen Docker-Gitlab-Architektur unterwegs)  - Für Loadbalancing, Rate Limits usw. 

Wäre so etwas ein guter Alternativvorschlag den ich meine vorlegen könnte?  

 

Kann mich mein Ausbildungsbetrieb eigentlich zwingen ein bestimmtes Thema zu machen? 

 

Bearbeitet 29. Januar 20232 j von ichmagkurkuma

 

Erweiterung des CI/CD-Prozesses um eine Post-Deployment-Stage mit automatisiertem Screenshot-Report innerhalb von CMS-Projekten.

Die 😸GmbH ist ein ... in ... und ... .
Im vergangenen Jahr wurde mit der Entwicklung eines eigenen auf verschiedene Kundenwünsche zugeschnittenen CMS begonnen. Dieses befindet sich mittlerweile bei einer niedrigen zweistelligen Kundenzahl im Einsatz. 
Hauptbestandteil dieses CMS ist ein entkoppelter Frontend-Microservice der - die von der  😸GmbH entwickelten Komponenten - mit einer vom Kunden festgelegten Konfiguration und dem Inhalt des Kunden darstellt. Das CMS wird kontinuierlich weiterentwickelt und je nach Wartungsvertrag in verschiedenen Intervallen bei verschiedenen Kunden ausgespielt. 

Innerhalb des bestehenden CI/CD-Prozesses der aus Testing und Deployment besteht, soll eine Post-Deployment-Stage samt Funktion ergänzt werden. Die Hauptfunktion dieser Stage besteht in der Screenshoterstellung der live-geschalteten Kundenwebsites. Da das Zusammenspiel aus Konfiguration, individuellen Sonderanpassungen des Source-Codes und Inhalt mit dem sich ständig änderen "Core-Code" regelmäßig überprüft werden muss und die Seitenstrukturen der Kundenwebsites teilweise zu umfangreich sind, sollen automatisiert Screenshots von allen öffentlichen Seiten in zwei verschiedenen Auflösungen (Mobile und Desktop) erstellt werden.

 

Projektphasen:

Initialisierung: ~ 5 Stunden
1 Stunden: IST-Analyse
4 Stunden: SOLL-Konzept

Planungsphase: ~ 10 Stunden
2 Stunden: Suche von möglichen Lösungen
6 Stunden: Vergleich der möglichen Lösungen und Abgleich mit Soll-Konzept
2 Stunden: Zeitplanung und Erstellen von konkreten Tasks der finalen Lösung für die Durchführungsphase.

Durchführungsphase: ~15 Stunden
3 Stunden: Installation, Konfiguration, Ersteinrichtung - je nach gewählter Lösung ggf. Lizenzenkauf
2 Stunden: Anbindung an GitLab, Erweiterung des CI/CD-Prozesses und Übergabe von Projektparametern.
5 Stunden: Feinkonfiguration, ggf. Implementierung der gewünschten Funktionen
2 Stunden: Reportgenerierung 
2 Stunden: Test
1 Stunde: Puffer für unabsehbare Dinge

Dokumentationsphase: ~ 10 Stunden
1 Stunde Soll/Ist-Vergleich
1 Stunde Abnahme des Projekts
1 Stunde Wirtschaftlichkeitsprüfung
7 Dokumentation

 

Ich habe nun nochmal ausführlich mit meinem Ausbildungsbetrieb gesprochen und mir sind jetzt einige Dinge viel klarer geworden. Ich hoffe ich konnte das Projekt jetzt gut rüberbringen. Ist das Projekt für ein FISI-Projekt jetzt "in Ordnung"?  

@Gooose @charmanta Ich tagge euch mal frecherweise^^ 

 

Bearbeitet 6. Februar 20232 j von ichmagkurkuma

Ich kann meinen Hauptpost leider nicht mehr editieren um den (vorläufigen) Projektnamen jetzt dort reinzupacken. 

Kann das vielleicht jemand machen? [Projektantrag] Erweiterung des CI/CD-Prozesses um eine Post-Deployment-Stage mit automatisiertem Screenshot-Report

Ich hab die Befürchtung sonst sieht sich den Thread niemand mehr an.  

vor 23 Stunden schrieb ichmagkurkuma:

3 Stunden: Installation, Konfiguration, Ersteinrichtung - je nach gewählter Lösung ggf. Lizenzenkauf

was hier installiert wird bleibt unklar

vor 23 Stunden schrieb ichmagkurkuma:

2 Stunden: Anbindung an GitLab, Erweiterung des CI/CD-Prozesses und Übergabe von Projektparametern.

.

test_puppeteer:
  image:
    name: $CI_REGISTRY_IMAGE/tmp:$CI_PIPELINE_ID
  stage: container-test
  script:
    # Verify node/npm/yarn versions
    - node -v && npm -v && yarn -v
    # Install puppeteer and execute simple page test with screenshot
    - npm i puppeteer
    - node tests/puppeteer.js
  artifacts:
    paths:
      - puppeteer.png

 

vor 23 Stunden schrieb ichmagkurkuma:

5 Stunden: Feinkonfiguration, ggf. Implementierung der gewünschten Funktionen

.

'use strict';

const puppeteer = require('puppeteer');

// This is a simple test of the generated image to ensure
// puppeteer can launch and open a page.
(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('https://github.com/puppeteer/puppeteer');
  await page.screenshot({ path: 'puppeteer.png' });
  await browser.close();
})();

Das war deine ursprüngliche "Lösung". Es fällt immer noch schwer hier Komplexität zu erkennen, geschweige denn irgendeine wirtschaftliche Betrachtung noch wie du vorhast die 40 Stunden zu füllen.

Solche Snippets habe ich auch gefunden auch zu Playwright oder Selenium aber die sind weder dynamisch an die verschiedenen Projekte angepasst noch decken sie die Anforderung ab? Die Anforderung ist nicht mache ein Screenshot von einer Seite und speichere den screenshot ab und mach dann feierabend. 

- Mobile / Desktop

- x Seiten mit y Unterseiten - Linkverfolgung

- Performance der Seite, bei Puppeteer kann man glaube ich auch sowas wie Google Page Speed miteinfließen lasse

- Reportgenerierung & Mailversand

 

Ich weiß jetzt nicht für wie komplex du @_n4p_ andere Abschlussthemen hälst aber es geht doch darum die richtige Lösung zu finden für die Anforderung und den Weg dahin?? Für mich ist Gitlab bis auf das wir darin Dokumentation pflegen bisher nur einer von vielen Servern die wir als FISIs im Unternehmen betreuen... kann nicht jeder direkt Experte sein. 

 

In den 3 Stunden muss ich ja Playwright oder Selenium oder Puppeteer oder oder oder (vermutlich am besten in Docker) installieren und von dort das jeweilige Projekt und dessen Seiten "untersuchen". Mir kommt das vielleicht vorsichtig aber nicht überzogen vor ehrlich gesagt. 

Dein Feinkonfigurationbeispiel ist genauso blödsinn wenn ich das je nach tool mit ein paar Zeilen code anpassen muss dann muss man die dafür erst suchen und die ganzen anforderungen (siehe liste oben) inklusive folgestolpersteine beheben. mailversand heisst ja zb auch kommunikation mit smtp aus gitlab heraus

 

Bearbeitet 7. Februar 20232 j von ichmagkurkuma

Am 6.2.2023 um 19:50 schrieb ichmagkurkuma:

Die Hauptfunktion dieser Stage besteht in der Screenshoterstellung der live-geschalteten Kundenwebsites

vs.

vor 21 Minuten schrieb ichmagkurkuma:

- Mobile / Desktop

- x Seiten mit y Unterseiten - Linkverfolgung

- Performance der Seite, bei Puppeteer kann man glaube ich auch sowas wie Google Page Speed miteinfließen lasse

- Reportgenerierung & Mailversand

ist schon ein unterschied, der sich aber in dem ersten Beitrag nicht herauslesen lässt.
unterseiten und links verfolgen ist aber auch nur ein "await page.click("x")"
reports bekommt man mit lighthouse oder ähnlichem, mails nodemailer

an der stelle schreibst du aber ein puppeteer script, das ist kein FiSi Thema

vor 27 Minuten schrieb ichmagkurkuma:

In den 3 Stunden muss ich ja Playwright oder Selenium oder Puppeteer

das ist das was das erste snippet ausdrückt, man installiert halt nix. man konfiguriert den gitlab runner (wobei der schon da ist wenn du nur ne pipeline erweiterst) und der holt sich ein passendes docker image und führt das aus. in der -ci.yaml "installierst" du dann nodejs erweiterungen und bist fertig. 

 

Überarbeitete Version

Erweiterung des CI/CD-Prozesses um eine Post-Deployment-Stage innerhalb von CMS-Projekten.

Die 😸GmbH ist ein ... in ... und ... .
Im vergangenen Jahr wurde mit der Entwicklung eines eigenen auf verschiedene Kundenwünsche zugeschnittenen CMS begonnen. Dieses befindet sich mittlerweile bei einer niedrigen zweistelligen Kundenzahl im Einsatz. 
Hauptbestandteil dieses CMS ist ein entkoppelter Frontend-Microservice der - die von der  😸GmbH entwickelten Komponenten - mit einer vom Kunden festgelegten Konfiguration und dem Inhalt des Kunden darstellt. Das CMS wird kontinuierlich weiterentwickelt und je nach Wartungsvertrag in verschiedenen Intervallen bei verschiedenen Kunden ausgespielt.

Dieses Zusammenspiel aus Konfiguration durch den Kunden, individuellen Sonderanpassungen des Source-Codes für den jeweiligen Kunden und Inhalt (ebenfalls vom jeweiligen Kunden) mit dem sich ständig ändernden "Core-Code"  macht eine manuelle Überprüfung zeitaufwendig und fehleranfällig.

Innerhalb des bestehenden CI/CD-Prozesses der aus Testing und Deployment besteht, soll eine Post-Deployment-Stage samt Funktion ergänzt werden. Die Hauptfunktion dieser Stage besteht in der Überprüfung der live-geschalteten Kundenwebsite. Dies soll mit Page-Speed-Metriken sowie Screenshots in verschiedenen Auflösungen (Mobile & Desktop) gewährleistet werden. 

Das gewünschte Ergebnis soll sowohl der  😸GmbH als auch dem Kunden einen Mehrwert bieten, in dem die  😸GmbH den Kunden auf etwaige Bedienfehler seinerseits hinweisen kann, die Bedürfnisse des Kunden anhand seiner Contentpflege besser einschätzen kann und Fehler in Kombination mit der Konfiguration des Kunden frühzeitig erkannt werden können.

 

 

Projektphasen:

Initialisierung: ~ 5 Stunden
1 Stunden: IST-Analyse
4 Stunden: SOLL-Konzept

Planungsphase: ~ 10 Stunden
2 Stunden: Suche von möglichen Lösungen
6 Stunden: Vergleich der möglichen Lösungen und Abgleich mit Soll-Konzept
2 Stunden: Zeitplanung und Erstellen von konkreten Tasks der finalen Lösung für die Durchführungsphase.

Durchführungsphase: ~15 Stunden
3 Stunden: Initialisierung, Konfiguration, Ersteinrichtung - je nach gewählter Lösung ggf. Lizenzenkauf
2 Stunden: Anbindung an GitLab, Erweiterung des CI/CD-Prozesses und Übergabe von Projektparametern.
5 Stunden: Feinkonfiguration, ggf. Implementierung von notwendigen Funktionen
2 Stunden: Reportgenerierung - Anbindung an SMTP, Projektverantwortliche informieren 
2 Stunden: Test
1 Stunde: Puffer für unabsehbare Dinge

Dokumentationsphase: ~ 10 Stunden
1 Stunde Soll/Ist-Vergleich
1 Stunde Abnahme des Projekts
1 Stunde Wirtschaftlichkeitsprüfung
7 Dokumentation

 

Ich habe meine Projektbeschreibung jetzt nochmal überarbeitet. Wäre toll wenn du @_n4p_ oder @charmanta oder ein anderer "Erfahrener" nochmal darauf schauen würde.

Manche Formulierungen würde ich noch finalisieren... ich habe zur zeit einen schulblock und muss direkt danach spätestens das projekt beantragen deshalb formuliere ich zur zeit nicht alles bis ins detail aus. die schulblöcke liegen dafür echt blöd bei meinem jahrgang

 

Bearbeitet 8. Februar 20232 j von ichmagkurkuma

vor 2 Minuten schrieb ichmagkurkuma:

Erweiterung des CI/CD-Prozesses um eine Post-Deployment-Stage innerhalb von CMS-Projekten.

Ist mir zu Dev-Lastig. Ich bleibe dabei, ich würde es ablehnen weil es nicht zum Fisi passt. Das findet sich auch in der Zeitplanung wieder. Ich rate zu einem neuen Thema, aber zur Sicherheit beschwöre ich @skylakeoder @ickevondepinguinoder @euro

oder oder oder

 

Ich sehe es auch zu sehr im Dev Bereich und würde es ablehnen.

Dito. Neues Thema bitte.

vor 46 Minuten schrieb ichmagkurkuma:

3 Stunden: Initialisierung, Konfiguration, Ersteinrichtung - je nach gewählter Lösung ggf. Lizenzenkauf
2 Stunden: Anbindung an GitLab, Erweiterung des CI/CD-Prozesses und Übergabe von Projektparametern.
5 Stunden: Feinkonfiguration, ggf. Implementierung von notwendigen Funktionen
2 Stunden: Reportgenerierung - Anbindung an SMTP, Projektverantwortliche informieren 

Außer das du im Text nun etwas schwammig umreißt was du genau machen willst, hat sich an dem Punkt das du ein puppeteer script und etwas gilab konfiguration nichts machst. Dachte es wäre klar gewesen das das gestern schon kein FiSi Thema war und auch das die fachliche Tiefe weder für FiSi noch einen FiAE reichen würde.

Okay schade aber dann ist das sehr eindeutig... in unserer Firma machen meine FISI-Kollegen einfach soviel DevOPs Themen dass ich hoffe dass die das verstehen und mir ein neues Projekt geben. So wie ich meinen betrieb kenne gibts dann einfach nur ein thema was schon x andere Azubis gemacht haben. 

Danke für eure Rückmeldungen  

 

@_n4p_ ich glaube du verstehst nicht dass die komplexität doch gar nicht im script von puppeteer oder was weiß ich liegen soll. wenn ich stattdessen zum hundertsten mal irgendwelche verschiedenen  Grafana, Kibana, Elastic vergleiche und danach konfiguriere was ist da denn der unterschied? irgendwo steht die lösung oder irgendjemand kennt die lösung bereits. 

Wenn ich aber die verschiedenen lösungen miteinander vergleiche, die anforderung analysiere und eben plane was wie zu erledigen ist ist das doch exakt das gleiche in grün nur das am ende statt einem grafana ein headless browser puppeteer oder playwright oder selenium oder oder rauspurzelt.

Grafana (als sich dann herauskristallisierte lösung) ist ja oft genug FISI Abschlussprojekt. Nur braucht mein betrieb scheinbar kein dashboard und liveview sondern eine POST-deployment-stage mit anforderung x y und z  

Die Azubikollegen (FIAE) mit denen ich mich austausche sind fachlich jetzt auch nicht überfordert mit ihren themen. (ich als supportesel wäre das aber gefühlt bei dem thema trotzdem^^ will nur meinen betrieb mit meinem projekt auch "glücklich machen" und übernommen werden)

Bearbeitet 8. Februar 20232 j von ichmagkurkuma

Irgendein grafana dashboard zu konfigurieren ist meiner meinung nach auch kein FiSi Thema, auch für sonst keinen. (also für ein abschlussprojekt)

Ich habe die Beispiele nicht gebracht um zu zeigen das die Lösung schon irgendwem bekannt ist, sondern um darzulegen das der Umfang der Lösung zu gering ist. Das du das noch nie gemacht hast und daher vermutlich etwas mehr Zeit benötigst, ist kein Argument. Wenn jemand eine Monitoring-Lösung installiert, kann man die 3 Tage Schulung die er dafür braucht auch nicht als Projektzeit zählen.

vor einer Stunde schrieb ichmagkurkuma:

ich glaube du verstehst nicht dass die komplexität doch gar nicht im script von puppeteer oder was weiß ich liegen soll.

worin dann? in der Analyse? In der Planung? die Komplexität sehe ich nicht. Das du dich in das Thema einarbeiten müsstest zählt nicht als Komplexität. 

Am 28.1.2023 um 18:44 schrieb pr0gg3r:

Aber Grundsätzlich sehe ich einen FISI ganz klassich mehr darin Clients, Server und Netzwerke zu planen, umzusetzen und zu warten.

Ich kann das nur wiederholen. Ansonsten schau dir bei den Projektanträgen hier im Forum mal Beispiele an, was FISIs so als Projekte machen. Wenn du jetzt nochmal mit nem CI/CD-Pipeline kommst drehen wir uns noch einmal im Kreis...

Ich glaube @ichmagkurkumas Problem ist das sein Betrieb ihm diesen Arbeitsauftrag als Abschlussprojekt aufdrücken will. Das ist oftmals so weil es "gerade ansteht und gebraucht wird".

Es läßt sich mit etwas Fokusänderung und viel Mühe FiSi-tauglich machen - aber ehrlich - damit gewinnst Du @ichmagkurkuma keinen Blumentopf oder FiSi-Abschluss . Ich habe das einmal erlebt, dass der Betrieb es nicht anders wollte. Und bevor der Prüfling deswegen nichts abgibt haben wir mit festen Vorgaben da was gestrickt vor ein paar Jahren. Ende vom Lied war: Durchfallen weil er nur die BAsis geschaffen hat, die jemand mit viel Erfahrung innerhalb einer Stunde aufgesetzt hätte. Die selbe Gefahr sehe ich hier auch!

Beerdige das Thema als Abschlussprojekt und mach etwas FiSi-taugliches bitte. Das Forum ist voll von Projektanträgen.

Bearbeitet 9. Februar 20232 j von ickevondepinguin