CI/CD Pipeline & Deployment (GitLab & Ansible)

Die Auslieferung von SMARTKRIS ist vollständig über GitLab CI/CD automatisiert. Sowohl das Frontend- als auch das Backend-Repository verfügen über mehrstufige Pipelines, die den Code testen, bauen, versionieren und via Ansible auf die Zielserver ausrollen.

1. Umgebungen & Trigger-Logik

Das Deployment erfolgt umgebungsspezifisch basierend auf dem Git-Workflow:

Umgebung

Trigger (GitLab Rule)

Ansible Environment Name

Pre-Staging

Manueller Trigger bei Merge Requests auf development

pre-staging

Staging

Manueller Trigger bei Merge Requests von development auf master

staging

Produktion

Manueller Trigger bei der Erstellung eines Git-Tags

solingen

Jede Umgebung erhält ihren eigenen Variablen-Scope (CI_ENVIRONMENT_SLUG), sodass Netzwerke, Container-Namen und Datenbanken sauber voneinander getrennt auf demselben physischen Host laufen können.

2. Pipeline Stages

Beide Repositories durchlaufen eine ähnliche Pipeline-Architektur, unterscheiden sich jedoch im Build-Prozess.

Stage 1: Changelog & Pages

In der Stage changelog wird das Tool git-cliff genutzt. Es analysiert die Git-Historie (Conventional Commits) und generiert automatisch eine CHANGELOG.md. Ein nachgelagerter pages-Job konvertiert diese Markdown-Datei via pandoc in eine statische HTML-Seite und veröffentlicht sie über GitLab Pages. So haben Stakeholder jederzeit eine übersichtliche Release-Historie.

Stage 2: Build & Docker Image

Die Erstellung der Docker-Images variiert je nach Technologie:

  • Backend (Spring Boot): Nutzt Cloud Native Buildpacks via Gradle (./gradlew bootBuildImage). Es wird kein manuelles Dockerfile benötigt. Das Image wird direkt gebaut und mit dem $CI_JOB_TOKEN in die GitLab Container Registry gepusht.

  • Frontend (Next.js & Node.js): 1. Zunächst werden die Abhängigkeiten geholt (fetch-deps).

    1. Im Job next-build wird das Next.js-Projekt gebaut. Es entsteht ein optimierter .next/standalone Ordner, der als Artefakt an den nächsten Job weitergereicht wird.

    2. Der Job docker-build nutzt docker buildx, um schlanke Produktions-Images (Alpine-basiert) für das smartkris Dashboard und den smartkris-ws-service zu bauen und in die Registry zu pushen.

Stage 3: Deploy (Ansible)

Der eigentliche Rollout auf den Zielservern passiert nicht durch manuelle SSH-Befehle im GitLab-Runner, sondern orchestriert über Ansible.

Der Job nutzt das Image cytopia/ansible:2.13-tools. Er lädt den im Repository liegenden Private Key ($SSH_DEPLOY_KEY) in den SSH-Agenten und führt das Playbook (z. B. deploy_prod.yml) gegen den definierten $DEPLOY_HOST aus.

Ansible verbindet sich mit dem Zielserver, generiert aus Jinja2-Templates (.j2) die fertigen docker-compose.yml und .env Dateien, führt einen docker login an der GitLab Registry durch, pullt die neuesten Images und startet die Container mit docker compose up -d --force-recreate neu. Abschließend wird die .env Datei aus Sicherheitsgründen wieder vom Server gelöscht.