add new article draft

content/post/continious-deployment-hugo/index.md

@@ -0,0 +1,116 @@
+---
+title: "Continous Deployment mit Hugo und Drone CI"
+date: 2019-02-04T18:00:00+02:00
+draft: false
+author: robert-kaussow
+description: "Static Site Generatoren sind gerade stark in Mode. Doch was voher das Blogsystem automatisch gemacht hat, muss jetzt vom Benutzer selbst durchgeführt werden. Mit Hilfe von Continous Deployment Strategien lässt sich der Arbeitsaufwand aber auf ein Minimum reduzieren."
+keywords:
+  - open
+  - source
+  - hugo
+  - static site generator
+  - devops
+  - cicd
+  - continious
+  - deployment
+  - integration
+  - automation
+categories:
+  - Open Source
+  - Entwicklung
+resources:
+  - name: theme
+    src: 'images/theme_pipeline.jpg'
+    title: Drone Pipeline bei Änderungen am Theme-Repository
+  - name: content
+    src: 'images/content_pipeline.jpg'
+    title: Drone Pipeline bei Änderungen am Content-Repository
+---
+
+Wie bereits in einem früheren Beitrag erwähnt, nutze ich für meinen Blog mittlerweile Hugo, einen Static Site Generator, anstelle einer Blog-Engine oder eines Content Management Systems. Bisher habe ich die Entscheidung nicht bereut, musste aber feststellen, dass sich mein Workflow im ersten Schritt nicht wirklich verbessert hat. Um das zu beheben, muss man sich als Erstes zwei Dinge anschauen: Wie hat es bisher funktioniert und wo will ich eigentlich hin? Dieser Beitrag soll eine Art Retrospektive sein und meinen Weg zu einer Continuos Deployment Strategie mit Hugo und Drone CI betrachten.
+
+Den notwendigen Neuaufbau meiner Infrastruktur habe ich nicht nur zum Anlass genommen, um alles vollständig auf Ansible umzustellen, sondern auch um meinen Softwarestack kritisch zu hinterfragen und aufzuräumen. Jede Software erfüllt natürlich einen Zweck, entscheidend für mich war aber: Wie wartungsintensiv ist die Lösung, wie leicht lässt sie sich automatisch deployen und rechtfertigt der Aufwand den Zweck. Im Fall von meiner Blog-Engine Serendipity (s9y) bin ich zu dem Schluss gekommen, dass ich darauf eigentlich ganz gut verzichten kann. Nebenbei empfand ich mittlerweile die Weboberfläche zur Verwaltung meiner Beiträge als nicht optimal für mich. Ich wollte lieber in einem Artikel meiner Wahl, am besten auch Oflline arbeiten können als in einem Onlineeditor. Außerdem musste man für etwas komplexere Formatierungen dann doch wieder zu HTML und CSS wechseln, weil der WYSIWYG-Editor das nicht hergab und Markdown im Standard da auch relativ beschränkt ist. Damit war die Entscheidung auch schon getroffen, es soll eine neue Lösung her.
+
+Der zweite Schritt war die "Suche" nach einer alternative. Zugegeben, da habe ich es mir tatsächlich etwas einfach gemacht und keinen großen Softwareauswahlprozess durchgeführt. Dass es ein Static Site Generator werden soll, stand für mich fest und [Hugo](https://gohugo.io/) war mir bereits bekannt. Nach den ersten Experimenten mit Hugo, die ohne große Zwischenfälle verliefen, fing ich an ein paar Punkte zu sammeln, die ich mir für die konkrete Umsetzung gewünscht habe:
+
+- Keine Serverkomponente mehr, die gewartet werden muss, nur noch good old HTML
+- Artikel können in Markdown geschrieben werden
+- Artikel lassen sich bequem über Git verwalten
+- Design und Inhalt sind voneinander getrennt und können separat verwaltet werden
+
+Zur Trennung des Seitendesigns und des Inhaltes habe ich zwei Git Repositories. Das erste Repository beinhaltet tatsächlich nur das reine Theme. Im zweiten Repository befinden sich aber nicht nur die Markdown Dateien für die Artikel, sondern eigentlich die komplette Ordnerstruktur und Seitenkonfiguration für Hugo. Soweit alles nach meinen Vorstellungen. Aber wie bringe ich jetzt beides zusammen, damit Hugo daraus meinen Blog generieren kann? Theoretisch gibt es dafür aus meiner Sicht zwei Ansätze:
+
+**Methode 1: Unabhängige Repositories**
+
+Diese Methode ist auf den ersten Blick die leichtere. Beide Repositories bleiben komplett unabhängig voneinander und werden einzeln verwendet. Führt aber dazu, dass ich vor jeder Generierung beide irgendwie manuell zusammenführen muss.
+
+- Content-Repository klonen und in den Themes Order wechseln
+- Eventuell zum produktiven Branch wechseln
+- In Theme Verzeichnis wechseln
+- Theme-Repository klonen
+- Eventuell zum produktiven Branch wechseln
+- Seite generieren
+
+**Methode 2: Integrierte Repositories**
+
+Alternativ lassen sich die Repositories aber auch bereits im Vorfeld beispielsweise mit Git Submodules miteinander verbinden. Spart vor dem Generieren erstmal nicht viel, außer das separate klonen vom Theme.
+
+- Content-Repository klonen und in den Themes Order wechseln
+- Eventuell zum produktiven Branch wechseln
+- Seite generieren
+
+Ich habe mich für die zweite Methode entschieden und arbeite mit [Git Submodules](https://git-scm.com/book/de/v1/Git-Tools-Submodule). Dafür gibt es im Content-Repository einen separaten Branch der nur das Theme beinhaltet. Bei Bedarf hole ich mir per Git Pull die Änderungen aus dem Theme-Repository und überführe diese anschließend in den master Branch. Ich kann also im Theme-Repository ungestört arbeiten und die Änderungen bei Bedarf kontrolliert überführen. Nach Änderungen reicht es jetzt also das Repoitory zu klonen, anschließend die Seite zu generieren und das Ergebnis auf den Webserver zu übertragen. Soweit so gut. Gehen wir einen Schritt weiter und betrachten die offenen Punkte die noch nicht gelöst sind:
+
+- CSS Minify/Beautify für das Theme sicherstellen
+- Automatisierung des Deployments bei neuen Artikeln oder Änderungen am Theme
+
+Um Bandbreite bei der Übertragung zu sparen kann man CSS oder auch JavaScript Dateien verkleinern. In der Praxis geschieht das im Wesentlichen durch das Entfernen nicht benötigter Zeichen wie Leerzeichen, Leerzeilen und Zeilenumbrüchen. Automatisieren lassen sich solche Tasks beispielsweise mit [gulp.js](https://gulpjs.com/). Mithilfe von Plugins können so beliebige Tasks gruppiert werden. Ein Gulp Task kann beispielsweise so aussehen:
+
+{{< highlight bash "linenos=table" >}}
+const gulp = require('gulp');
+const minifyCSS = require('gulp-csso');
+const concat = require('gulp-concat');
+const rename = require('gulp-rename');
+const cleanCSS = require('gulp-clean-css');
+const autoprefixer = require('gulp-autoprefixer');
+
+var CSSDEST = 'static/'
+
+gulp.task('default', defaultTask);
+
+function defaultTask(done) {
+  return gulp.src('src/css/*.css')
+             .pipe(concat('default.css'))
+             .pipe(cleanCSS({format: 'beautify'}))
+             .pipe(autoprefixer({
+               browsers: ['last 4 versions'],
+               cascade: false
+             }))
+             .pipe(gulp.dest(CSSDEST))
+             .pipe(cleanCSS())
+             .pipe(rename({ extname: '.min.css' }))
+             .pipe(gulp.dest(CSSDEST))
+}
+{{< / highlight >}}
+
+Der hier zusammengestellte _defaultTask_ macht der Reihe nach folgendes:
+
+- alle CSS Dateien aus dem Ordner _src/css/_ in eine einzelne Datei _default.css_ zusammenführen
+- die Formatierungen korrigieren und vereinheitlichen (beautify)
+- fehlende CSS Präfixes ergänzen
+- die Datei in den Ordner _static/_ speichern
+- CSS verkleinern (minify) und als _default.min.css_ ebenfalls in den Ordner _static/_ speichern
+
+Die aufbereitete Datei _default.min.css_ wird dann als CSS Datei für die fertige Seite verwendet. Wie gesagt, die Tasks lassen sich beliebig erweitern und bei Bedarf unterschiedlich gruppieren. Denkbar ist auch das Kompilieren von SASS oder SCSS Dateien.
+
+Bleibt zum Schluss nur noch eines. Bei Änderungen sollen automatisch meine Gulp Tasks ausgeführt, die Seite generiert und auf meinen Webspace deployed werden. Am besten eignet sich dazu ein Continuos Integration System wie beispielsweise Travis CI. Ich habe mich allerdings für [Drone CI](https://drone.io/) entschieden. Drone selbst wird als Docker Image bereitgestellt und kann auf dem eigenen Server betrieben werden. Wem das Zuviel Aufwand ist, für den gibt es mittlerweile aber auch eine [Cloud Version](https://cloud.drone.io/). Wie bei den meisten CI Lösungen wird für jedes Repository eine Pipeline definiert, die beschreibt, welche Schritte bei welcher Aktion (Push, Tag, Pull Request) ausgeführt werden sollen. Drone führt dabei jeden Schritt der Pipeline in einem eigenen Docker Container aus. Meine definierten Pipelines für das [Theme-Repository](https://gitea.rknet.org/xoxys/theme-geeklab/src/branch/master/.drone.yml) und das [Content-Repository](https://gitea.rknet.org/xoxys/theme-geeklab/src/branch/master/.drone.yml) findet ihr auf meiner Gitea Instanz. Ich habe an dieser Stelle nur den Ablauf für beide Repositories skizziert.
+
+{{< imgproc theme resize "950x" />}}
+
+Die Pipeline für das Theme-Repository ist relativ einfach gehalten. Gulp Tasks ausführen, bei Bedarf geänderte und bereinigte CSS Dateien (Assets) mittels eines Bots zurück in das Repo pushen und eine Benachrichtigung mit dem Status der Pipeline in einen privaten Matrix Channel senden. Fertig. Änderungen an dem Theme werden derzeit bewusst nicht automatisch durch die CI in das Content-Repository übernommen. Möglich wäre das durchaus, ich machte diesen Schritt aber vorerst manuell um Änderungen besser steuern zu können.
+
+{{< imgproc content resize "950x" />}}
+
+Auch die Pipeline bei Änderungen am Content-Repository ist nicht wirklich kompliziert, hat aber ein paar mehr Schritte. Zuerst wird die neue Version der Seite generiert, die verwendete Hugo Version kann hierbei über das Drone Plugin gesteuert werden. Als Nächstes wird dann der aktuelle Stand der Seite auf dem Webserver "eingefroren". Dazu wird der aktuelle Ordner kopiert und ein Symlink auf die Kopie erstellt. Anschließend löscht Drone den Ordner der alten Version auf dem Webserver und erstellt ihn wieder mit der neuen Version. Zum Abschluss wird der Symlink wieder umgelenkt und die Kopie gelöscht. Warum das ganze? Ich habe das Drone Plugin so konfiguriert, dass die Dateien beim Deployment nicht einfach über den alten Stand drüber kopiert werden, sondern die alte Version vorher gelöscht wird. Dadurch kann ich sicherstellen, dass Überreste von alten Artikeln oder im Theme tatsächlich auch entfernt werden, wenn sie nicht mehr benötigt werden. Das führt beim Deployment aber zu einer kurzen Downtime meines Blogs, da zwischen dem löschen und dem kopieren nichts von der Seite mehr da ist. Um das zu vermeiden, der der beschrieben Workaround für in Zero-Downtime-Deployment.
+
+Mit diesem Workflow bin ich aktuell ganz zufrieden, ich kann offline in einem Editor meiner Wahl arbeiten, ich kann meine Arbeit mittels Git synchronisieren und am Handy oder einem anderen PC weiter schreiben und das Veröffentlichen geht bequem mit einem einfachen Push von der Kommandozeile aus.