Entwicklungsworkflow für Deine Website(s)

Heute gibt es wieder ein Wunschthema. Es geht um die Art und Weise, wie du den Entwicklungsworkflow für deine Website organisierst.

Wenn du eine Website bei einem Service Provider wie NOVATREND hostest, musst du deine Entwicklungsarbeit an dieser Website organisieren. Im einfachsten Fall gibt es zwei Möglichkeiten.

1. Du arbeitest live auf dem Server/Webhosting:
   Du installiert ein CMS per Installation-Skript, beispielsweise durch unser Installatron und arbeitest dann live weiter auf der Site.
   ACHTUNG: Seit November 2017 benutzen wir anstelle des Installatrons das Tool Softaculous. Im Beitrag Automatisierte Installation mit Softaculous beschreibe ich die grundlegenden Vorgehensweisen.
2. Lokal auf deinem Rechner:
   Du installierst zunächst eine lokale Entwicklungsumgebung wie XAMPP, MAMP oder Vagrant/Virtual Box auf deinem lokalen Rechner. Du erstellt die Website lokal und irgendwann lädst du das Ergebnis „auf den Server“, beispielsweise mit einem FTP-Client.

Beide Varianten haben Vor- und Nachteile.
Der Vorteil (und Nachteil) bei Variante 1 ist, dass es nur eine Version der Website gibt und alle Änderungen sofort live sind. Der grösste Nachteil dabei ist, dass die Website offline ist, wenn du einen Fehler bei deinen Änderungen machst. Ausserdem hast du keine Testversion deiner Website, die du deinen Kunden zeigen kannst.
Bei Variante 2 umgehst du das Problem der Offline Zeiten durch eventuelle Fehler durch die Tatsache, dass du lokal auf deinem Rechner arbeitest. Du kannst deine Änderungen auch testen und dem Kunden auf deinem Rechner zeigen.  Du musst aber die von dir gemachten Änderungen irgendwie mit dem Server synchronisieren. Solange du allein arbeitest, klappt das noch ganz gut, spätestens wenn mehrere Personen an einer Seite entwickeln oder der Kunden nicht persönlich auf deinen Rechner gucken kann, wird es schwierig oder gar unmöglich.

Versionsverwaltung

Eine grundsätzlich gute Idee ist, den Quellcode deiner Website in einem Versionsverwaltungssystem zu lagern. Du kannst bei Fehlern zu einer älteren Version zurückkehren und mehrere Entwickler können am Code arbeiten. Für Kunden kann eine Testumgebung, meist stage genannt auf einem Live Server mit Passwortschutz bereitgestellt werden. Das von den meisten genutzte Versionsverwaltungssystem heisst Git. Es ist eine freie Software zur verteilten Versionsverwaltung von Dateien, die durch Linus Torvalds initiiert wurde. Quellcode wird in sogenannten Repositories gelagert. In einem Repository liegen alle Dateien. Das ist vergleichbar mit einem Fotoalbum, in dem Fotos liegen. Du kannst dir selbst einen Git Server einrichten, normalerweise benutzt man aber Services wie GitHub oder BitBucket, die den Quellcode lagern, auf Git basieren und viel komfortabler sind als eine selbst gehostete Lösung. Beide Services haben natürlich ein Geschäftsmodell. Bei GitHub musst du dafür bezahlen, wenn dein Code nicht öffentlich sichtbar, also privat, sein soll. Bei BitBucket sind private Repositories erlaubt, dein Team darf aber nicht mehr als fünf Entwickler haben. Du musst im Einzelfall entscheiden, was besser für dich passt.

Entwicklung und Deployment

Unter Entwicklung verstehe ich das Arbeiten am Code und unter Deployment die Übertragung der Änderungen auf ein Live System. Das ist auch für Nicht-Entwickler interessant, denn Design Anpassungen oder ganze Webseiten bei dateibasierten CMS stehen natürlich auch in Dateien.

Ein Beispiel mit BitBucket

Ich gehe im Beispiel davon aus, dass du deinen Website Quellcode nicht öffentlich verwalten möchtest. Da BitBucket es erlaubt, private Repositories kostenlos zu verwalten, werde ich es für das Beispiel nutzen. Ich möchte mit einer neuen Website in einer lokalen Entwicklungsumgebung beginnen, den Quellcode bei BitBucket versionieren und bei Bedarf mit dem Live Server synchronisieren.

Konto und Repository bei BitBucket anlegen

Als Erstes musst du dir ein BitBucket Konto anlegen. BitBucket kennt Projekte und Repositories. Du könntest beispielsweise ein Projekt anlegen und darin dann mehrere Repositories. Du kannst aber auch ein Repository ohne übergeordnetes Projekt anlegen.

Lokales Verzeichnis einrichten

Richte dir lokal ein Verzeichnis für deine Projekte ein, beispielsweise /dev, öffne eine Shell, gehe in dieses Verzeichnis und führe die folgenden Befehle aus.

git clone git@bitbucket.org:hagengraf/novatrendtest.git

Der Inhalt des novatrendtest Repositories wird „gecloned“, d.h. in das lokale Verzeichnis geladen. Git erstellt ein Verzeichnis mit dem Namen des Repositories. Wechsele in dieses Verzeichnis.

cd novatrendtest

Nun kannst du mit einem Texteditor oder dem folgenden Befehl eine Datei mit dem Namen README.md erzeugen und den Text „# My project’s README“ hineinschreiben. Du kannst sie auch test.txt oder meinewebsite.html nennen. Eine „read me“ Datei ist aber immer eine gute Idee, weil dort immer die wichtigste Informationen stehen.

echo "# My project's README" >> README.md

Die Datei muss dem Git System hinzugefügt werden, damit das die verschiedenen Versionen verwalten kann.

git add README.md

Dein lokales Git weiss nun, das es eine neue Datei gibt, weiss aber noch nicht, wann du mit deinen Änderungen soweit bis, das du sie abschliessen (commit) kannst. Der Befehl git commit signalisiert dem lokalen Git System, dass du deine Änderungen für abgeschlossen erklärst. Der Parameter -m übermittelt eine Bemerkung zu den Änderung (message), damit Dritte (und auch du selbst nach ein paar Monaten) nachvollziehen können, was du da geändert hast. Im unserem Fall ist es ein Initial commit, also eine erste Änderung

git commit -m "Initial commit"

Das lokale System ist nun up to date, das BitBucket System weiss aber noch nichts von deinen Änderungen. Der Befehl git push überträgt die letzten Änderungen (commits) an dein Bitbucket Repository (origin master).

git push -u origin master

Alles zusammen sieht in der Shell so aus:

Änderungen auf BitBucket angekommen?

Wenn du dein BitBucket Repository im Browser ansiehst, siehst du deinen ersten Commit mit der Nachricht Initial commit.

Wenn du auf die Nummer des Commits klickst, siehst du die Details. Du hast eine Zeile eingefügt!

Live Server

Zuletzt musst du auf deinem Live Server ebenfalls ein Verzeichnis einrichten, das mit dem BitBucket Repository verbunden ist. Um den Live Server zu aktualisieren, kannst du vom Server aus den Befehl git pull [option] eingeben und die Änderungen „pullen“ oder du konfigurierst sogenannte Webhooks, die die Änderungen aus BitBucket heraus auf den Server „pushen“.

Abhängig vom Provider und der Art des Servers gibt es viel Konfigurationsmöglichkeiten. Grundsätzlich benötigst du ein installiertes Git auf dem Server und einen Key, der in BitBucket hinterlegt werden muss. Ohne Key musst du bei jedem git pull ein Passwort eingeben, was auf die Dauer nicht praktikabel ist. Der Befehl für die Schlüsseleinrichtung ist ssh-keygen. Normalerweise wird der Key in ~/.ssh/id_rsa gespeichert. Im Dialog musst du bei der Abfrage, wo du den Key speichern willst, das Wort deploy_key eingeben und KEIN Passwort festlegen.

### SSH Key einrichten
$ ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (~/.ssh/id_rsa): deploy_key
Enter passphrase (empty for no passphrase):

Gibt man wie oben gezeigt „deploy_key“ ein, erzeugt das Tool zwei Dateien im aktuellen Verzeichnis: deploy_key und deploy_key.pub.

Auf dem Server muss das Verzeichnis initialisiert werden (git init). Dann muss das existierende Verzeichnis geklont werden (git clone). Danach wird das remote Repository festgelegt (git remote add …).

Wenn diese Schritte erledigt sind, können Änderungen aus BitBucket mit dem Befehl git pull auf den Live-Server übertragen werden.

git init
git clone bitbucket git@bitbucket.org:hagengraf/novatrendtest.git
git remote add bitbucket git@bitbucket.org:hagengraf/novatrendtest.git
git pull

Hier in meinem Beispiel ist public_html das Live-Verzeichnis auf dem Server. Die Verzeichnisstruktur sieht folgendermassen aus (Befehl ls -al).

drwxr-xr-x 6 root root 4096 Nov 14 17:09 .
drwxr-xr-x 23 root root 4096 Nov 14 14:28 ..
-rw------- 1 novatrend novatrend 1675 Nov 14 16:39 deploy_key
-rw-r--r-- 1 novatrend novatrend 412 Nov 14 16:39 deploy_key.pub
drwxrwxr-x 7 novatrend novatrend 4096 Nov 14 16:37 .git
drwxr-xr-x 2 root root 4096 Jan 19 2016 logs
drwxrwxr-x 12 www-data www-data 4096 Nov 14 17:27 public_html

Wenn du Änderungen „pullen“ möchtest, musst du ins Verzeichnis public_html wechseln und den Befehl git pull eingeben.

Ein User-Interface für Änderungen (Source Tree)

Wenn die Basiseinstellungen eingerichtet sind, ist SourceTree eine hervorragende Software, mit der man die Änderungen in einfachen Projekten per Mausklick verwalten kann.

Ergebnis

Das Beispiel ist extrem einfach, enthält aber das Wesentliche. Es ist jetzt möglich

1. lokale Änderungen an den Dateien vorzunehmen und zu „committen“ (git commit …).
2. die Commits in das BitBucket Repository zu „pushen“ (git push).
3. das BitBucket Repository mit dem Live-Server zu synchronisieren (git pull).

Auch wenn es anfangs aussieht als sei das alles sehr kompliziert, so überwiegen die Vorteile eindeutig. Zugegebenermassen ist es aber auch kompliziert :). Jede berechtigte Person kann sich nun eine lokale Entwicklungsumgebung einrichten, den Code „pullen“, Änderungen vornehmen und „committen“ und schliesslich auf den Live-Server einspielen. Wenn mehrere Entwickler am Code arbeiten, so können sie sogar in der gleichen Datei ändern, ohne sich „ins Gehege“ zu kommen. Genau das ist die wichtigste Voraussetzung für Team- und Remote-Arbeit.

Links

• https://bitbucket.org
• https://github.com
• Das git Buch – Deutsche Version https://git-scm.com/book/de/v1
• https://www.sourcetreeapp.com

---

tl;dr: Versionsverwaltung ist die Basis einer geordneten Software Entwicklung und gar nicht so schwer!