ichmagkurkuma

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)

Ü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

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

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.

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

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?

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

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.