Continuous Integration bei PartnerGate

Wer sich immer schon gefragt hat, wie Continuous Integration und das Deployment im Entwicklungsprozess bei PartnerGate umgesetzt und gelebt werden, kann sich im folgenden einen kleinen Einblick verschaffen. Der Beitrag unseres Entwicklers Jörg Moldenhauer ist im Entwickler Magazin 6.2020 in einer erweiterten Version erschienen und kann hier als (kostenpflichtige) Online Version eingesehen werden.

Jörg ist Diplom-Medieninformatiker und seit Sommer 2018 als Webentwickler bei uns beschäftigt. Seitdem hat er sich das Thema CI/CD (Continuous Integration/Continuous Deployment) auf die Fahnen geschrieben und verantwortet die damit verbundenen Prozesse.

Bei PartnerGate setzen wir seit nunmehr über zwei Jahren auf eine Microservice-Architektur, die den bewährten Monolithen unterstützt und langfristig ersetzen soll. Im Zentrum dieses Beitrages steht die Frage, wie der von den Entwicklern erstellte Code von den Rechnern der Entwickler in die Produktivumgebung überführt wird. Für den Aufbau einer modernen CI/CD Pipeline stehen eine Vielzahl von Tools, teilweise als Open-Source, zur Verfügung.  Bei PartnerGate haben wir uns für Docker, GitLab und Rancher entschieden, da sie die notwendige Flexibilität im Einklang mit der benötigten Komplexität bieten.

GitLab dient als Git-Repository, Container Registry und Deployment Werkzeug. Als Git-Workflow haben wir uns für GitLab-Flow entschieden, da dieser auf bewährten Standards basiert und mit der bisherigen Vorgehensweise zusammenpasst. Neue Funktionalitäten und Bugfixes werden zunächst in Feature-Branches angelegt und umgesetzt. Ist die Implementierung abgeschlossen, werden sie in den Master Branch gemerged, der auf den Staging Server deployed wird. Sind alle Arbeiten für den nächsten Release erledigt, wird der Master Branch in den Production Branch gemerged und anschließend in die Live Umgebung deployed.

 

Gitlab Flow

In der Datei “gitlab-ci.yml” wird für jedes Projekt die Deployment Pipeline mit folgenden Stufen konfiguriert:

  • Test
  • Install
  • Build
  • Deploy

Die Test-Stufe findet vor dem Merge in den Master Branch statt. Schlägt einer der Unit Tests fehlt, wird der Merge abgebrochen, so dass keine ungetesteten Änderungen in den Master Branch gelangen. Die weiteren Schritte werden nach dem Merge in den Master bzw. Production Branch ausgeführt. In der Install Stufe werden die benötigten Abhängigkeiten installiert und auf Sicherheitslücken untersucht. Im Build wird das Docker Image, in dem unsere Applikation ausgeliefert wird, gebaut und in der GitLab Container Registry abgelegt. In der Deploy Stufe wird Rancher dazu veranlasst, sich das neue Image zu holen und die Container neu auszurollen. Zudem wird die Datenbankstruktur mithilfe von Migrations auf den neuesten Stand gebracht.

 

Rancher ist eine grafische Oberfläche für Kubernetes. Wir benutzen es um unsere Docker Container in Staging und Production Umgebung zu orchestrieren. Über Deploy Tokens kann Rancher auf die Images in der GitLab Container Registry zugreifen. Variable Daten wie zum Beispiel die Datenbankverbindung können über Umgebungsvariablen gesetzt werden.

Rancher Container

Das Zusammenspiel von Gitlab, Docker und Rancher eignet sich besonders für eine Microservice-Architektur, in der lose gekoppelte Services über Nachrichten kommunizieren. Allerdings kann auch unser langjährig bewährter Monolith, der noch einen Großteil der Funktionalität des PartnerGates enthält, mittlerweile über GitLab deployed werden. Hier ist allerdings nicht Docker im Einsatz sondern die Dateien werden auf einen traditionellen Server mit dem Tool “Magallanes”geschoben.

Somit steht dem PartnerGate-Entwicklungsteam ein Toolset zur Verfügung, das sich mit unterschiedlichen Software-Paradigmen bewährt hat und eine solide Grundlage für den zukünftigen Entwicklungsprozess bietet.