Wer GitLab als Server für die Versionsverwaltung Git einsetzt, sucht oft nach Möglichkeiten den Code auf Testsysteme oder Produktiv Systeme zu deployen (verbreiten / übertragen). Dafür wahren früher externe Continous Integration (CI) Dienste wie Jenkins notwendig.  Seit einigen Versionen bietet auch GitLab mit GitLab CI einen integrierten Dienst an. Somit kann auf externe Dienste verzichtet werden. Zum Verarbeiten der gewünschten Anweisungen kommt der GitLab Runner zum Einsatz. Dieser kann auch zum deployen von Codes auf Server verwendet werden.

Leider ist die Dokumentation nicht ganz ausführlich, wie ein Deploy eingerichtet wird. Eine Installation des GitLab Runner ist zwar enthalten und auch gut Dokumentiert, aber die Syntax der .gitlab-ci.yml ist eher dürftig beschrieben. Diese Datei steuert im Prinzip den GitLab Runner und gibt an, was dieser machen soll. Hier wird auch die Anweisung für das Deployen des Codes gegeben. Mein GitLab Runner habe ich als Shell Executor installiert und konfiguriert. Das reicht für meine Bedürfnisse aus. In der Dokumentation sind auch die anderen Möglichkeiten genau beschrieben.

.gitlab-ci.yml als Steuerzentrale für den Gitlab Runner

Wie oben schon erwähnt, steuert die .gitlab-ci.yml den Runner. Für ein Deploy des Codes kann eine Unterscheidung je nach Branch ausgeführt werden. Dabei können ähnlich wie in der Bash Befehle ausgeführt werden. Hier meine .gitlab-ci.yml als Beispiel:

before_script: 
  - git submodule update --init --recursive

deploy_dev:
  script: 
  - ssh serverpilot@dev-wp.eyet-media.berlin 'rm -rf /srv/users/serverpilot/apps/devwp/public/wp-content/themes/helpingdudes_em'
  - ssh serverpilot@dev-wp.eyet-media.berlin 'mkdir /srv/users/serverpilot/apps/devwp/public/wp-content/themes/helpingdudes_em'
  - scp -r ./* serverpilot@dev-wp.eyet-media.berlin:/srv/users/serverpilot/apps/devwp/public/wp-content/themes/helpingdudes_em
  except:
  - master
  
deploy_prod:
  script: 
  - ssh serverpilot@wp.eyet-media.berlin 'rm -rf /srv/users/serverpilot/apps/emwpnetwork/public/wp-content/themes/helpingdudes_em'
  - ssh serverpilot@wp.eyet-media.berlin 'mkdir /srv/users/serverpilot/apps/emwpnetwork/public/wp-content/themes/helpingdudes_em'
  - scp -r ./* serverpilot@wp.eyet-media.berlin:/srv/users/serverpilot/apps/emwpnetwork/public/wp-content/themes/helpingdudes_em
  only:
  - master

(Links im Code bitte vernachlässigen, dies wird durch ein Plugin verursacht.)

Gut zu erkennen ist hier die Unterscheidung zwischen den Branches und den entsprechenden Servern. Alles was nicht im Master Branch liegt, wird auf den Testserver deployed. Alles was in den Master Branch übertragen wird, schickt der Runner auf den Produktiv Server. Dort wird zuerst per SSH das Zielverzeichnis gelöscht. Anschließend dann neu erstellt und zum Schluss per SCP die Dateien übertragen. Das Löschen des Ordners ist notwendig um 2 Problemen aus den Weg zu gehen. Sollte ein Projekt neu erstellt werden, muss durch das Löschen und anschließenden erstellen des Zielordners dieses nicht manuell auf den Servern erstellt werden. Das zweite Problem was dadurch umgangen wird ist folgendes. Sollet ihr eine Datei erstellen und an den Servern übertragen, diese später aber Löschen, wird diese sonst nicht vom Server gelöscht. So wird sichergestellt das ihr auf dem Server genau 1:1 die Dateien habt, wie auch im Repository.

Über der Unterscheidung der Server wird noch eine Abfrage nach evtl. Submoduls gemacht und diese mit Initialisiert und Übertragen. Ich nutze das um den WordPress Core und die Themes in einem Hauptprojekt zusammen zuführen und an den Test und Prod Server zu übertrage. So kann ich auf beiden Server die gleichen Bedingungen schaffen.

Ausführung eines Commits

Beim Ausführen eines Commits an den Server  wird die .gitlab-ci.yml ausgeführt und an den GitLab Runner übergeben. In der Weboberfläche kann dann das Log und der Status abgerufen werden. Durch entsprechende Hooks können diese natürlich auch an Slack etc. weitergeben werden. Mit [skip ci] kann die Ausführung des Runners ausgelassen werden. Es wird dann zwar das Commit an Gitlab übertragen und ein Kommentar angelegt, aber der Runner nicht ausgeführt.

Hinweis: Ihr müsst natürlich entweder SSH Keys für die Server bereit halten, oder die Passwörter mitgeben (was natürlich sehr unsicher ist) um auf die Server per SSH oder SCP Zugriefen zu können. Wenn ihr Submodule von GitLab mitgibt, brauch ihr natürlich auch hier ein Deploy Key, den ihr vorher erstellen müsst.

Es ist natürlich mit GitLab CI und dem Gitlab Runner noch viel mehr möglich. Ich will hier nur eine Möglichkeit des Deployen per SSH und SCP aufzeigen. Ähnlich funktioniert auch das Deployen per FTP.