NETWAYS Blog

HUGO: GitLab-CI/CD-Pipeline für eine statische Website

von Björn Berg | Mai 19, 2022 | GitLab

Vor etwa 4 Monaten habe ich hier einen Blogpost geschrieben, in dem ich Hugo vorgestellt habe – eine Software zum Generieren statischer Webseiten aus Markdown-Dateien.

Im Lauf meiner Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS habe ich vor kurzem an einer GitLab Fundamentals Schulung teilgenommen, um mehr über Git im allgemeinen und die Besonderheiten von GitLab im speziellen zu lernen. Auf Basis dieser Schulung und dem Projekt hinter oben genannten Blogpost habe ich nun eine CI/CD-Pipeline – CI/CD steht für Continous Integration and Continous Deployment – zum automatisierten Testen, Bauen und Ausrollen einer mit Hugo erzeugten Website gebaut.

Für dieses Projekt habe ich NETWAYS Web Services (NWS) eine GitLab CE App gestartet und außerdem in der Cloud von NWS zwei Webserver – einen als Testumgebung, einen als Produktivumgebung. Mithilfe meines Laptops als Client habe ich an der Website gearbeitet und die anfallenden Daten regelmäßig in ein eigenes GitLab Repository gepusht. Zum Testen, Bauen und Ausrollen auf die beiden Webserver laufen in der GitLab App zwei GitLab Runner. Das sind im Prinzip Agenten die für die GitLab App auf einem anderen System Befehle ausführen können.

Die CI/CD Pipeline

Die CI/CD Pipeline wird über die .gltiab-ci.yml gesteuert. Anfangs werden in der Pipeline die Quelldateien mithilfe zweier Markdown-Linter (vale.sh und markdownlint) getestet – in der .gitlab-ci.yml schaut das so aus:

lint:
   stage: lint
   tags: 
    - hugo
   allow_failure: true
   script:
    - cd tutorial
    - mdl ./content
    - vale ./content

Diese überprüfen die Inhalte der Website auf die Einhaltung eines Styleguides und auch auf die Sprachliche Korrektheit. Anschließend wird die Webseite mit Hugo gerendert, das heißt aus den Markdown-Dateien für den Websiteinhalt entsteht nun die wirkliche Website:

testBuild:
   stage: build
   tags:
    - test
   script:
    - cd tutorial
    - mkdir test
    - hugo -DEF --debug -d test
   artifacts:
   paths:
    - tutorial/test

Falls diese Operation auf der Testumgebung erfolgreich ist, wird sie auch auf der Produktivumgebung durchgeführt. Als Abschluss wird die gerenderte Webseite noch für den genutzten Webserver (z.B. Apache HTTPD oder nginx) bereitgestellt):

testDeploy:
   stage: deploy
   needs: [testBuild]
   tags:
    - hugotest
   script:
    - cp -r tutorial/test/* /var/www/html/
   only: 
    - main

Grafisch sieht diese Pipeline so aus:

Wenn auch Du solche interessanten Projekte in Deiner Ausbildung zum Fachinformatiker machen möchtest, kannst du Dich gerne für eine Ausbildung ab Herbst 2022 bewerben!

Björn Berg

Junior Consultant

Björn hat nach seinem Abitur 2019 Datenschutz und IT-Sicherheit in Ansbach studiert. Nach einigen Semestern entschied er sich auf eine Ausbildung zum Fachinformatiker für Systemintegration umzusteigen und fing im September 2021 bei NETWAYS Professional Services an. Auch in seiner Freizeit sitzt er viel vor seinem PC und hat Spaß mit diversen Spielen, experimentiert auch mit verschiedenen Linux-Distributionen herum und geht im Sommer gerne mal campen.

Lies mehr von Björn und triff unser Team

Chrome Devtools: CSS Helfer

von Jannis Mosshammer | Aug 7, 2013 | Development

Wer kennt das nicht: Man baut ein wenig an einer HTML Seite/Webanwendung (wohlmöglich einer, die man nicht selbst entwickelt hat) herum und möchte das Styling eines Elementes anpassen. Doch egal was man macht und wie laut man brüllt: Der Browser übernimmt die Änderungen einfach nicht. Grund sind meist irgendwelche zusätzliche CSS Regeln die die eigenen Überscheiben, oder sonstiger CSS Voodoo der (scheinbar) keinen Sinn ergibt.
Oft rutscht man dabei in ein iteratives Try & Error Prinzip:

CSS Anpassen
Seite neu aufrufen
Fluchen
CSS Anpassen
…

Spätestens ab Punkt 4. sollte man merken, dass hier etwas Ineffizient ist. Tools wie die eingebaute Entwicklerkonsole im Chrome können hier den totalen Nervenzusammenbruch (ungefähr bei der zehnten Iteration) verhindern. Natürlich gibt es ähnliche Features auch für die anderen Browser. Die Chrome Entwicklertools sind meiner Meinung nach nur am umfangreichsten und effizientesten, darum gehe ich hier nicht auf andere Tools ein.
Ruft man die Tools auf (Ctrl-Shift-i, Cmd-Shift-I (Mac) oder Tools->Developer tools) und geht in den Elements Dialog, begrüßt einen folgendes Fenster (hier habe ich eine Seite des W3C CSS Tutorials aufgerufen) :

Developer tools

Während die linke Seite den aktuell gerenderten DOM Baum anzeigt (also mit dynamisch hinzugefügten/geänderten Elementen) gibt die rechte Spalte Auskunft über das aktuelle ausgewählte Element (CSS Regeln, Maße, Eventlistener, etc).

Das ‚Computed style‘ Feld zeigt alle Regeln, die angewendet werden

Interessant für die CSS-Fehlersuche sind eigentlich nur die ersten drei Sektionen :

Computed Style gibt an, welche Regeln für dieses Element letztenendes wirklich angewendet werden, also in das Rendering einfliessen
Style gibt an, welche Regeln im ’style=‘ Attribut des Objektes hinterlegt sind
Matched CSS Rules zeigt alle CSS-Regeln und deren Quelldateien an, die für den aktuellen Knoten gelten. Dabei ist die Reihenfolge gleich der CSS Hierarchie, d.h.
weiter oben liegende Regeln unterschreiben die generischen Regeln aus der Ebene darunter (Ausnahme: Regeln mit !important)

Sollte etwas nicht gehen muss der Blick zuerst auf die Computed Style Sektion gehen: Ist meine Regel hier vorhanden?
Wenn ja sollte die Regel überprüft werden: Passt das CSS auf das angegebene Element? Gibt es spezielle Bedingungen für die Regel? Passt der Kontext (z.B. bei Problemen mit float, hier müssen auch andere Knoten berücksichtigt werden).
Wenn die Regel nicht im Computed Style steht, kann man in dem Matched CSS Rules Feld hoffentlich sehen warum das so ist:

Kein tingting.mp3 für mich – nicht unterstützte Regeln zeigt Chrome netterweise an

Erscheint die Regel nicht ist das CSS schlicht und ergreifend nicht korrekt (ist das CSS geladen? Passt die CSS Query auf den Knoten?)
Erscheint die Regel, jedoch durchgestrichen, lohnt sich ein Blick auf das gelbe Ausrufezeichen: Dann ist die Regel entweder invalide (hat z.b. einen Tippfehler) oder wird nicht unterstützt.
Ist die Regel vorhanden, aber der Wert im Computed Style ein anderer, sollte man schauen ob die Regel irgendwo überschrieben wird: Gibt es Regeln die über der eigenen liegen? Ist die Regel mit !important definiert?

Zum Experimentieren ausserdem sehr nett: Click man auf eine Regel kann man neue Attribute hinzufügen oder bestehende Attribute verändern. Chrome greift einem mit den Eigenschaften und Werten ein wenig unter die Arme. Kleinere CSS Experimente oder Wertänderungen kann man so direkt im Browser ausprobieren.
Man darf aber nicht vergessen dass einem die Tools nur helfen können Fehler zu finden – ein Blick in die Doku sollte bei Problemen immer als erstes Erfolgen. Wer nicht weiß, was sein CSS bewirkt wird auch mit den besten Tools nicht weit kommen (spätestens wenn ein anderer Browser das Dokument anders rendert).

Nicht nur für mobile Endgeräte: Responsive-Web mit Media-Queries

von Jannis Mosshammer | Jan 31, 2013 | Development

Im Buzzwort-Bingo hat beim heutigen Blogpost ‚Responsive Web‘ zugeschlagen.
Nachdem Tablets und Smartphones in sehr kurzer Zeit zur potentiellen Zielgruppe für die meisten Webapplikationen gelten, geistert ‚Responsive Web‘ als Paradigma durch das Web – und meint damit eigentlich nur, dass man jetzt wirklich darauf achten sollte dass Webseiten auch auf kleineren Displaygrößen benutzbar sind. Man tut dem ganzen aber Unrecht wenn man es nur als Mobile-Thema abtut – auch wer ’nur‘ mit dem Desktopbrowser surft kann von den Techniken profitieren.
Kernelement des ganzen sind CSS Media Queries. Diese stellen im Grunde eine Verfeinerung der media-types da, die alle Browser (ausser IE, der kann es ohne Hacks erst ab Version 9) seit Urzeiten unterstützen. mit
@media print { ... CSS für Druckausgabe ... } @media screen { ... CSS für Bildschirmausgabe ... }
… stellen unzählige Angebote bereits Ihre Druckseiten anders dar als die Browseransicht (z.B. andere Schriftgrößen).
Media-Queries gehen noch einen Schritt weiter: Mit ihnen kann man CSS in Abhängigkeit der Fenstergröße, der Bildschirmorientierung (z.B. wenn man das Tablet dreht), des Höhe/Breite Verhältnisses, der Pixeldichte und vielen mehr anpassen. Die Query
@media screen and (max-width: 1024px) { ... css ... }
definiert z.B. Regeln,die nur dann gelten, wenn das Browserfenster 1024px klein ist und greift auch, sobald der Nutzer das Fenster kleiner zieht. Meistens sieht man so etwas wenn es darum geht Mobilgeräte zu unterstützen, z.B. indem Werbebanner anders angezeigt werden sobald ein Gerät mit bestimmter Pixeldichte und Auflösung auf die Seite kommt. Man muss sich jedoch bewusst sein dass auch ein Desktopbrowser mit den gleichen Eigenschaften gerade die Seite anschauen könnte. Einen eigenen Medientyp für Smartphones oder Tablets gibt es nämlich nicht.
Allerdings sind media-queries in variablen Umgebungen wie dem Desktop-Browser fast praktischer: Da die Fenstergröße hier von sehr groß bis klein variieren kann sollte man als Entwickler auf Skalierbarkeit achten. Das fängt bei Netbooks an, geht zu Nutzern weiter die auch mal ein einzelnes Fenster klein gezogen haben, bis zu der (nicht mal so unpraktischen) Split-View von Windows 8.
Hier kann man mit Media-Queries ohne viel Aufwand auf Größenänderungen reagieren und die Seite anhand des vorhandenen Platzes anpassen. Denkbar wäre es je nach vorhandener Breite z.B. Icons kleiner zu machen, Bereiche nicht mehr nebeneinander, sondern untereinander darzustellen, u.v.m.
Als Demo habe ich mal ein kleines (extrem gestyltes) Szenario erstellt. Zieht man das Result-Fenster kleiner, ändert sich die Icongröße, der Text wird abgeschnitten und nur bei Mouseover angezeigt.
Zwar ist das keine Wunderwaffe für alle Szenarien, gezielt eingesetzt kann man damit aber den vorhandenen Platz oft besser Ausnutzen – ohne massig JavaScript schreiben zu müssen.

Simpel, schnell und praktisch – Webapplikationen mit Flask erstellen

von Jannis Mosshammer | Jan 3, 2013 | Development

Auf dem Planeten der serverseitigen Webtechnologien herrscht eine unbegrenzte Artenvielfalt. In den verschiedensprachigen Ländern und Inseln (Java, Pythonien, etc.) tummeln sich viele kleine Technologievölker und verehren ihre vielen Frameworks, die allesamt unermesslich Mächtig und Allumfassend sind. Unerbittliche Kriege werden geführt, welches Framework und welche Sprache besser ist, Neulinge kämpferisch missioniert und für die eigene Sache geworben.
Manchmal wünscht man sich einen kleinen Kometen, der ein wenig für Ordnung sorgt. Daher will ich zumindest in Python einen kleinen Tipp geben, wenns mal weniger sein darf:
Zur Vorgeschichte: Auch ich bin auf den Raspberry Pi Zug aufgesprungen und finde die Kiste als kleinen Programmierspielkasten wirklich sehr spaßig. Da ich für kleinere Spielereien Python oder NodeJS bevorzuge, war ich also auf der Suche nach einem kleinen Python Webframework – direkt gegen die WSGI zu programmieren empfinde ich doch als etwas unkomfortabel. Nun ist es hier nicht so einfach, ein passendes Framework zu finden, das mir nicht von vornherein MV* aufdrängt (manchmal braucht man das nicht, ehrlich), klein ist und sich ‚elegant anfühlt‘.
Nachdem die Liste im Python wiki überflogen habe, bin ich erstmal aus dem Raum gegangen und habe ein wenig geweint. Django, Pylon, Zope… das war mir alles (auf den ersten Blick) zu groß, zu Vereinnahmend. Klar, große Frameworks mit ORM, SOAP support, MVC und allen möglichen Schnittstellen, Helfern und Features haben Ihren Sinn, aber manchmal ist auch bei der Webentwicklung weniger mehr (und mit NodeJS habe ich ja auch in ein paar Zeilen einen HTTP Server laufen ohne vorher ein Projektskeleton auf der Konsole zu erstellen).
Dann bin ich über Flask gestolpert und allein schon das Beispiel auf der Startseite hat die Tränen etwas trocknen lassen. Ein paar Zeilen, schon hat man einen Webdienst am Laufen, ein paar Zeilen mehr und man kann komplexe Templates einbinden. Formulare, Uploads, Routing, etc. – alles ist vorhanden. Dabei ist es egal ob man ein paar Funktionen über Urls ansprechen will oder man auf Klassenbasierte Views setzt – das Framework skaliert hier recht gut mit (aber zugegeben: Letzteres haben andere Frameworks schon eleganter umgesetzt).
Für mich wird das wohl das Pythonframework meiner Wahl für kleine und mittelgroße Projekte im Web (auch wenn es natürlich auch andere Frameworks, wie z.B. bottle gibt, die ähnlich kompakt sind). Für wirklich größere Anwendungen mit vielen Schnittstellen, Ausgabeformaten, Lokalisierung, etc. würde ich dann allerdings doch auf Django oder Zope umsteigen, hier ergibt der Mehraufwand beim Konfigurieren und der Größe dann auch wirklich Sinn.

Animationen für alle: CSS3 Transitions

von Jannis Mosshammer | Sep 16, 2010 | Development

In diesem Blogpost möchte ich mal ein wenig auf CSS3 eingehen. Das meiste, dass durch CSS3 ermöglicht wird, ging auch schon vorher – allerdings nicht selten mit hunderten Zeilen zusätzlichen Javascript-Code.
Wenn CSS3 erstmal in allen Browsern hinreichend unterstützt wird, ist vieles von diesem Code hinfällig.
Ein nettes Beispiel dafür bieten CSS Transisitons (die von den meisten WebKit Browsern wie Safari, Chrome, etc. bereits unterstützt werden):
Mit ihnen kann man CSS3 Transformationen auf ein HTML Element animieren.
Einfaches Beispiel: Eine Box soll sich um 30° drehen und dabei die Farbe und Größe ändern wenn man mit der Maus darüber geht.
Klingt aufwändig, ist aber ganz einfach, man definiert einfach ein Element mit der CSS Eigenschaft ‚transition-duration‘, z.B.
#Element { transition-duration: 1s linear; -webkit-transition-duration: 1s linear; -moz-transition-duration: 1s linear; width: 200px; height: 200px; ... }
Will man das Objekt jetzt beim Mouseover animieren, benötigt man nur noch eine ‚transform‘ Eigenschaft im CSS File:
#Element:hover { transform: rotate(350deg) rotate(-30deg); -webkit-transform: rotate(350deg) rotate(-30deg); -moz-transform: rotate(350deg) rotate(-30deg); }
Dieses Beispiel habe ich an einem Blogpost von Mozilla angelehnt (deren Firefox das auch bald unterstützt) und etwas abgespeckt, live im Browser kann man sich das hier anschauen (Safari, Chrome oder Opera vorrausgesetzt).
Das ganze sollte mit allen HTML Tags, die im Browser gezeichnet werden funktionieren – also kann man damit auch z.B. Videoflächen animieren.
Dezent eingesetzt lassen sich damit Schaltflächen schnell, einfach und ohne Programmierkenntnisse betonen.