Fu\u0308r das Proof-of-Concept-Projekt eines neuen Webauftritts fu\u0308r die GWDG hat sich die AG C zun\u00e4chst einige Prim\u00e4rziele gesetzt, nach denen der Webauftritt entwickelt werden sollte. Das wichtigste Ziel war eine einfache M\u00f6glichkeit zur Kooperation zwischen Autor*innen. Bei der GWDG ist eine Vielzahl von Mitarbeiter*innen fu\u0308r die Produktion von Beitr\u00e4gen und Inhalten des bestehenden Webauftritts verantwortlich, alle mit unterschiedlichen
\nKenntnisst\u00e4nden in verschiedenen Webtechnologien. Aus diesem Grund war es von Anfang an das erste Prim\u00e4rziel des Webseitenprojekts, einen Arbeitsablauf zu schaffen, der es allen Mitarbeiter*innen erm\u00f6glicht, unabh\u00e4ngig vom bisherigen Kenntnisstand mit nur minimalem zus\u00e4tzlichem Training Inhalte fu\u0308r den Webauftritt zu erstellen. Das zweite Prim\u00e4rziel des Projekts war die Entwicklung eines Webauftritts, der, wo immer m\u00f6glich, auf einfache statische Text und Medieninhalte setzt, um den Webauftritt m\u00f6glichst barrierefrei zu halten sowie die Ladezeiten und den Ressourcenverbrauch des Webauftritts m\u00f6glichst gering zu halten. Weiterhin war eines der Sekund\u00e4rziele des Projekts, eine zentralisierte Verwaltung des Webauftritts zu erm\u00f6gichen. Diese sollte \u00fcber eine effektive Versionsverwaltung verf\u00fcgen und verteilte Arbeitsabl\u00e4ufe m\u00f6glich machen. Das zweite Sekund\u00e4rziel war es, den Webauftritt als zentrales Informationsverzeichnis der GWDG automatisiert lesbar zu machen.<\/p>\n
WAS IST HUGO?<\/strong><\/p>\n HUGO [1] ist ein statischer Open-Source Webseitengenerator, der explizit auf einfache Bedienbarkeit und schnelle \u00dcbersetzungsprozesse hin optimiert wurde. Mit HUGO k\u00f6nnen Seiten eines Webauftritts auf Basis einer einfachen Markdown-Quelldatei [3] geschrieben werden, welche von HUGO mit HTML- und CSSTemplatedateien kombiniert und dann in eine statische HTML-Seite u\u0308bersetzt wird. Dank dieser Arbeitsweise ist HUGO ein optimaler Kandidat fu\u0308r das erste Prim\u00e4rziel des Projekts, da, nachdem entsprechende Template- und HUGO-Konfigurationsdateien im Stil des bisherigen GWDG-Webauftritts einmal erstellt wurden, die Erstellung neuer Seiten des Webauftritts lediglich Kenntnisse in Markdown erfordert. Der Trainings- und Umstellungsaufwand fu\u0308r alle am Webauftritt beteiligten Mitarbeiter*innen h\u00e4lt sich dementsprechend in Grenzen. Es wird dadurch auch in einfacher Weise m\u00f6glich, neue Mitarbeiter*innen in das Projekt einzufu\u0308hren, insbesondere wenn diese einen gewissen technischen Hintergrund haben, da in Markdown geschriebene Dokumente bereits ein etablierter Standard in technischer Dokumentation sind. Au\u00dferdem erm\u00f6glichen in Markdown geschriebene Quelldokumente einer Webseite, dank dessen einfach lesbarer Syntax, dass die ersten Kontroll- und Korrekturzyklen ohne eigene HUGO-Testinstanzen auskommen k\u00f6nnen. Dies vereinfacht die Arbeitsabl\u00e4ufe in heterogenen Arbeitsumgebungen und verringert den administrativen Aufwand. Als statischer Webseitengenerator erstellt HUGO einen Webauftritt in einem Schritt aus den Markdown-Quelldateien und den HTML- und CSS-Templatedateien heraus. Das Resultat dieses Prozesses sind dann reine HTML- und CSS-Seiten sowie statische Inhalte wie Bilder oder Videos, welche mittels eines Webservers (HUGO kann einen solchen bereitstellen, aber u\u0308bliche Webserver wie Apaches httpd oder nginx eignen sich ebenso) an Besucher*innen des Webauftritts ausgeliefert wird. Aufgrund dieser Arbeitsweise eignet sich HUGO auch ausgezeichnet fu\u0308r das zweite Prim\u00e4rziel des Projekts, da die ausgelieferte Webseiten statisch sind und so den Ressourcenverbrauch fu\u0308r die Besucher*innen m\u00f6glichst gering halten. Der statische HTML-Inhalt der Webseiten kommt auch Screenreadern und anderer Unterstu\u0308tzungssoftware optimal entgegen und h\u00e4lt die Webseiten damit m\u00f6glichst barrierefrei. Um diese Vorteile von mit HUGO entwickelten Webseiten nicht zu konterkarieren und das zweite Prim\u00e4rziel weiter zu verfolgen, wurde w\u00e4hrend der Projektphase stets darauf geachtet, m\u00f6glichst auf clientseitige Webtechnologien wie JavaScript zu verzichten.<\/p>\n AUFBAU EINES HUGO-WEBSEITENVERZEICHNISSES<\/strong><\/p>\n Das Programm HUGO erstellt einen Webauftritt immer auf Basis eines Webseitenverzeichnisses (im folgenden auch Wurzelverzeichnis genannt). Dieses Verzeichnis enth\u00e4lt dann alle Dateien, die HUGO ben\u00f6tigt, um den Webauftritt zu erstellen. Am wichtigsten fu\u0308r HUGO ist dabei die Konfigurationsdatei config.toml, welche die generellen Konfigurationvariablen des Webauftritts enth\u00e4lt, den HUGO erstellen soll, zum Beispiel die BaseURL, unter der der Webauftritt sp\u00e4ter gefunden werden soll. Ebenso wichtig ist natu\u0308rlich auch der content-Ordner im Wurzelverzeichnis, in dem die Markdown-Quelldateien der einzelnen Seiten des Webauftritts abgelegt werden. Die entsprechenden URLs der einzelnen Seiten erstellt HUGO dann immer direkt aus der BaseURL aus der Konfigurationdatei sowie dem Pfad der Markdown-Datei in Relation zum content-Ordner. Weiterhin enth\u00e4lt das Wurzelverzeichnis auch den layouts-Ordner, in dem die HTML-Templatedateien des Webauftritts abgelegt werden. So ergibt sich die natu\u0308rliche Trennung, dass die Dateien im layouts-Ordner den Stil und das Design des Webauftritts steuern, w\u00e4hrend die Dateien des contents-Ordners den Inhalt des Webauftritts festlegen. Abbildung 1 zeigt das Wurzelverzeichnis unseres Projekts als Beispiel. Zus\u00e4tzlich zu den bereits beschriebenen Ordnern des Verzeichnisses enth\u00e4lt das Wurzelverzeichnis des Projekts noch einige weitere Dateien und Ordner, die hier noch kurz beschrieben werden sollen. All diese Ordner sind jedoch optional und werden fu\u0308r einen funktionierenden Webauftritt nicht zwangsl\u00e4ufig ben\u00f6tigt.<\/p>\n \u2013 assets:<\/em> Der assets-Ordner enth\u00e4lt Dateien des Webauftritts, die zun\u00e4chst noch durch einen Pr\u00e4prozessor bearbeitet werden m\u00fcssen, bevor sie von HUGO in den Webauftritt eingebunden werden k\u00f6nnen. In unserem Projekt wird dieser Ordner verwendet, um die CSS-Dateien des Webauftritts mit der Spracherweiterung SASS\/SCSS schreiben zu k\u00f6nnen, die dann von HUGO vor dem Einbinden in den Webauftritt durch einen Pr\u00e4prozessor in CSS \u00fcbersetzt werden. Aus den Inhalten dieser Ordner und Dateien setzt HUGO beim Aufrufen des Programms einen funktionsf\u00e4higen Webauftritt zusammen. Dabei hat HUGO zwei Betriebsmodi: Im hugo server-Modus startet das HUGO-Programm seinen eigenen Webserver, der den Webauftritt auf einem vordefinierten Port ausliefert; ein Prozess der insbesondere fu\u0308r das \u00dcberpru\u0308fen von \u00c4nderungen sehr wertvoll ist. Im standardm\u00e4\u00dfigen hugo-Modus erstellt das HUGO-Programm den fertigen Webauftritt als einen Set von HTML-Dateien, welche dann mit einem anderen Webserver (z. B. nginx [4]) ausgeliefert werden k\u00f6nnen.<\/p>\n SHORTCODES UND PARTIALS<\/strong><\/p>\n W\u00e4hrend das Verfassen von Seiten des Webauftritts durch Markdown-Dateien von HUGO sehr einfach gemacht wird, hat dieses Verfahren aber auch Nachteile. Einer davon ist, dass die Markdown-Quelldateien gewisser Seiten sehr repetitiv werden k\u00f6nnen, z. B. eine Teamseite, auf der sich jedes Teammitglied vorstellt und dasselbe Format sich dadurch immer wiederholt. Ein anderer Nachteil dieses Verfahrens ist es, dass durch die automatische Konvertierung von Markdown in HTML der direkte Zugriff auf die HTML-Elemente der resultierenden Dateien verlorengeht.<\/p>\n Dies erschwert die Entwicklung zum Beispiel von komplexen CSS-basierten Designs ungemein. F\u00fcr beide Probleme bietet HUGO eine L\u00f6sung: Shortcodes und Partials. Shortcodes und Partials sind kleine Dateien, die in HTML und GO\u2019s Templatesprache geschrieben werden. Diese Dateien k\u00f6nnen dann in anderen Markdown- oder HTML-Dateien aufgerufen werden, wobei HUGO die Templatesprache aufl\u00f6st und das resultierende HTML einfu\u0308gt. Auf diese Weise bringen Shortcodes und Partials Wiederverwendbarkeit in von HUGO erstellten Webseiten. Sie erm\u00f6glichen au\u00dferdem, da sie teilweise in HTML geschrieben werden, welches direkt in das resultierende HTML des Webauftritts eingefu\u0308gt wird, einen direkten Zugriff auf die HTML-Elemente des Webauftritts. Da GO\u2019s Templatesprache auch logische Konstrukte wie if<\/em> und else<\/em> und Schleifenoperationen wie for<\/em> kennt sowie Variablen erstellen und auf von HUGO bereitgestellte Variablen zugreifen kann, erm\u00f6glichen Shortcodes und Partials au\u00dferdem eine Form der Logik innerhalb der Generierung des Webauftritts.<\/p>\n Auf diese Weise werden in unserem Projekt beispielsweise dynamisch w\u00e4hrend der Erstellung des Webauftritts YAML-Dateien aus dem data<\/em>-Verzeichnis ausgelesen, die jeweils die Informationen u\u0308ber ein Teammitglied der AG C oder der AG E enthalten. Der verwendete Shortcode erstellt dann anhand der Zugeh\u00f6rigkeit eines Teammitglieds entweder eine Teamu\u0308bersicht der AG C oder der AG E. Derselbe Shortcode wird auch verwendet, um Mitglieder verschiedener Projektgruppen auf den entsprechenden Projektseiten anzuzeigen, welche teilweise auch AG u\u0308bergreifend aufgestellt sind. Dies wird erreicht, indem die YAML-Dateien einzelner Mitarbeiter*innen jeweils eine Liste an \u201eTags\u201d enthalten, die beispielsweise ihre AG- oder Projektzugeh\u00f6rigkeit anzeigen. Der Teamlisten-Shortcode ist dann in der Lage, anhand dieser Tags zu filtern und Teamlisten auszugeben, die jeweils alle Teammitglieder mit einem entsprechenden Tag enthalten. Auf diese Weise kann mit HUGO\u2019s Shortcodes und Partials ein hohes Ma\u00df an Wiederverwendbarkeit erreicht werden. Der Unterschied zwischen Shortcodes und Partials ist im \u00dcbrigen so marginal, dass sie in diesem Abschnitt austauschbar verwendet werden. Abgesehen von einer leicht unterschiedlichen Art und Weise, mit der sie in Quelldateien aufgerufen werden, liegt der prim\u00e4re Unterschied nur darin, dass Partials in (HTML-)Layoutdateien benutzt werden, w\u00e4hrend Shortcodes in Markdown-Quelldateien benutzt werden Beispielhaft zeigen die Abbildungen 2 und 3, wie ein Shortcode einerseits erstellt wird und wie er dann andereseits im Anschluss im Markdown-Dokument genutzt werden kann.<\/p>\n WORKFLOW MIT GIT UND GITLAB<\/strong><\/p>\n In diesem Abschnitt wird exemplarisch unser Workflow der Webseitenerstellung mit HUGO und git beschrieben. Auf Details der Benutzung und Einrichtung von git wird hierbei nicht n\u00e4her eingegangen. Dadurch, dass im Grunde der komplette Webauftritt aus Textdateien in einer Ordnerstruktur besteht, bietet sich die Nutzung von git geradezu an. So k\u00f6nnen viele Autor*innen zur gleichen Zeit an den Inhalten arbeiten und gleichzeitig hat man ein Versionierungstool an der Hand \u2013 im Vergleich zu vielen klassischen Content-Management-Systemen (CMS) ein klarer Vorteil. Au\u00dferdem bietet git in Verbindung mit HUGO die M\u00f6glichkeit, sowohl komplett offline als auch komplett online am Webauftritt zu arbeiten. Damit ist man entsprechend der eigenen Arbeitsweise maximal flexibel. Jede*r Autor*in erstellt fu\u0308r neuen Content eine eigene Working Branch. So wird sichergestellt, dass der neue Content den bestehenden Content nicht beeinflusst. Gleichzeitig kann man sich u\u0308ber den lokalen Server von HUGO das Endergebnis auf der eigenen Maschine oder u\u0308ber die mit einem Git-Runner ausgelieferte Vorschau schon ansehen. Jede*r kann einen Working Branch erstellen. Ist der Content erstellt, wird ein merge request gestellt, um die neuen Inhalte der working branch mit den bestehenden Inhalten zusammenzufu\u0308hren. In unserem Workflow wird das zun\u00e4chst in einem Staging-Bereich gemacht. Hier wird u\u0308berpru\u0308ft, ob die neuen Inhalte prinzipiell den redaktionellen, also inhaltlichen Anspru\u0308chen genu\u0308gen, und ob die neuen Inhalte st\u00f6rungsfrei integriert werden k\u00f6nnen. Das hei\u00dft insbesondere, dass gepru\u0308ft wird, ob die neuen Inhalte bestehende Bausteine des Webauftritts beeinflussen. Werden hier keine gr\u00f6\u00dferen Probleme festgestellt, wird der merge request zugelassen und im Staging-Bereich verfeinert. Gibt es gr\u00f6\u00dfere Probleme, wird diese Anfrage abgewiesen und der\/die Autor*in muss nochmal nachbessern. Auf der staging branch<\/em> hat nur eine kleine Gruppe Schreibrechte. Diese Gruppe ist dafu\u0308r zust\u00e4ndig, dass eingehende merge requests u\u0308berpru\u0308ft werden und kleinere Probleme, sofern vorhanden, behoben werden. Sind alle Arbeiten hier abgeschlossen, wird erneut ein merge request<\/em> auf die publication branch<\/em> gestellt. In diesem Zweig liegen alle final abgenommenen Dateien, die dann auch als Webseiten ver\u00f6ffentlicht werden. Der Zugriff auf die publication branch kann dabei noch weiter beschr\u00e4nkt werden, so dass am Ende nur noch wenige Personen stehen, die dazu berechtigt sind, Inhalte freizugeben.<\/p>\n AUSLIEFERUNG DES WEBAUFTRITTES<\/strong><\/p>\n Zur Auslieferung des Webauftritts werden ebenfalls Features von GitLab verwendet, um den gesamten Prozess zu automatisieren und kein manuelles Eingreifen n\u00f6tig zu machen. Mithilfe von GitLab Webhooks wird automatisch eine Benachrichtigung versendet, sobald die publication branch<\/em> einen neuen merge request<\/em> angenommen hat. Dieser wird vom Webseiten-Server mithilfe des Tools webhook [5] entgegengenommen und verifiziert, und wenn die Verifizierung erfolgreich verl\u00e4uft, wird ein Script angesto\u00dfen, welches sich den aktuellen Stand der publication branch herunterl\u00e4dt. FAZIT<\/strong> LINKS<\/strong> Die GWDG plant, die Bereiche High-Performance Computing (HPC) und Forschungsdatenmangement (FDM) prominenter in ihrem Webauftritt gwdg.de zu pr\u00e4sentieren. Hierfu\u0308r hat die Arbeitsgruppe \u201eComputing\u201c (AG C) in einem Proofof-Concept die Webseiten des HPC-Bereichs in HUGO [1] erstellt. HUGO ist ein Open-Source-Webseitengenerator, entwickelt in der Programmiersprache GO [2], der es erm\u00f6glicht, komplexe und funktionsreiche Webseiten auf Basis … Weiterlesen<\/a><\/p>\n","protected":false},"author":166,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[118],"tags":[119],"class_list":["post-22627","post","type-post","status-publish","format-standard","hentry","category-gwdg-nachrichten-2","tag-hpc"],"_links":{"self":[{"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/posts\/22627","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/users\/166"}],"replies":[{"embeddable":true,"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/comments?post=22627"}],"version-history":[{"count":20,"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/posts\/22627\/revisions"}],"predecessor-version":[{"id":22658,"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/posts\/22627\/revisions\/22658"}],"wp:attachment":[{"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/media?parent=22627"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/categories?post=22627"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/info.gwdg.de\/news\/wp-json\/wp\/v2\/tags?post=22627"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n\u2013 data:<\/em> Der data-Ordner enth\u00e4lt Datendateien (im YAML-, JSON- oder TOML-Format), welche von Shortcodes benutzt werden k\u00f6nnen, um dynamische Inhalte zu erstellen.
\n\u2013 i18n:<\/em> Der i18n-Ordner enth\u00e4lt benutzerdefiniert W\u00f6rterb\u00fccher, mit denen in den Templates und Shortcodes des Webauftritts Mehrsprachigkeit unterst\u00fctzt werden kann. Die Markdown-Dateien der Seiten selber m\u00fcssen allerdings manuell \u00fcbersetzt werden.
\n\u2013 src:<\/em> Der src-Ordner enth\u00e4lt einige Skripte, die das Git-Repository des Webauftritts automatisch aktuell halten.
\n\u2013 static:<\/em> Der static-Ordner enth\u00e4lt Inhalte des Webauftritts, die nicht von HUGO bearbeitet werden m\u00fcssen, bevor sie in den Webauftritt eingebaut werden k\u00f6nnen. In diesem Fall sind das insbesondere Mediendateien wie z. B. Bilder.
\n\u2013 .gitignore:<\/em> Die .gitignore-Datei enth\u00e4lt eine Liste aller tempor\u00e4r erstellten Dateien, damit diese nicht auf GitLab hochgeladen werden.
\n\u2013 .gitlab-ci.yml:<\/em> Die .gitlab-ci.yml-Datei steuert GitLabs CI Funktionalit\u00e4t, um neue \u00c4nderungen am Webauftritt automatisch auf dem Webseitenserver zu ver\u00f6ffentlichen.
\n\u2013 README.md:<\/em> Die README.md-Datei enth\u00e4lt eine kurze Beschreibung des GitLab-Repositories und soll neuen Mitarbeiter*innen helfen, die Struktur des Repository und dessen Handhabung zu verstehen.
\n\u2013 attributions.md:<\/em> Ein internes Notizdokument.<\/p>\n![\"\"](\"https:\/\/info.gwdg.de\/news\/wp-content\/uploads\/2022\/12\/GN_12-2022_S10-14-VE.png\")
<\/a><\/a><\/a>
\nInsbesondere bietet git durch die einfache Vergabe von Berechtigungen und die Erstellung verschiedener Branches auch eine einfache Art, einen redaktionellen Workflow zu erstellen (siehe Abbildung 4).<\/p>\n<\/a>
\nDer Inhalt der Branch durchl\u00e4uft dann noch einen finalen Test und wird anschlie\u00dfend, sowie der Test erfolgreich verl\u00e4uft, von HUGO in einen HTML\/CSS-basierten Webauftritt u\u0308bersetzt. Der neue Webauftritt wird daraufhin in den Auslieferungsordner kopiert, wo es den alten Stand des Webauftritts u\u0308berschreibt und vom Webserver (in unserem Fall nginx) an Besucher*innen des Webauftritts ausgeliefert wird.<\/p>\n
\nHUGO bietet eine einfache und gleichzeitig m\u00e4chtige M\u00f6glichkeit, um statische Webseiten zu erzeugen. Gerade in Verbindung mit den Automatisierungsm\u00f6glichkeiten von GitLab k\u00f6nnen Inhalte von externen Quellen dynamisch eingelesen und ver\u00f6ffentlicht werden. Durch Shortcodes und Partials k\u00f6nnen auch komplexe HTML-Strukturen einfach in Markdown integriert werden, so dass Markdown-Dateien deutlich flexibler werden, ohne dass gleichzeitig die Komplexit\u00e4t von Markdown erh\u00f6ht wird. Die Vorteile u\u0308berwiegen fu\u0308r uns deutlich, so dass eine Umgestaltung verschiedener Webseitenbereiche nun in Angriff genommen wird. Insbesondere die Automationsm\u00f6glichkeiten wie auch die leichte Integration unterschiedlicher Datenquellen machen die Kombination von HUGO und GitLab zu einer echten Arbeitserleichterung.<\/p>\n
\n[1] https:\/\/gohugo.io<\/a>
\n[2] https:\/\/go.dev\/<\/a>
\n[3] https:\/\/de.wikipedia.org\/wiki\/Markdown<\/a>
\n[4] https:\/\/www.nginx.com\/<\/a>
\n[5] https:\/\/github.com\/adnanh\/webhook<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"