Vorteile für den Entwicklungsprozess

1. Zeitersparnis

Statt manuell nach Updates zu suchen und diese einzupflegen, übernimmt Renovate diese Aufgabe. So bleibt mehr Zeit für Feature-Entwicklung.

2. Schnellere Sicherheitsupdates

Renovate kann so konfiguriert werden, dass kritische Sicherheitsupdates sofort erstellt und zur Überprüfung vorgelegt werden. Das verringert das Risiko erheblich.

3. Kleine, häufige Updates statt grosser Sprünge

Renovate zerlegt Updates in kleinere Pakete und erstellt separate Pull Requests für verschiedene Abhängigkeiten. Das macht Tests und Reviews einfacher und sicherer.

4. Konfigurierbare Update-Strategien

Regeln lassen sich individuell definieren, zum Beispiel:

• Automatische Zusammenfassung von Patch-Updates (1.2.3 → 1.2.4)
• Manuelles Review von Minor-Updates (1.2.3 → 1.3.0)
• Blockierung von Major-Versionen (1.2.3 → 2.0.0)
• Ignorieren bestimmter Abhängigkeiten bei Bedarf

5. Integration mit CI/CD-Pipelines

Renovate-Merge Requests durchlaufen automatisierte Tests. So wird sofort sichtbar, ob ein Update Probleme verursacht.

6. Reduzierte technische Schulden

Durch regelmässige Updates bleiben Abhängigkeiten aktuell. Das verhindert aufwändige Nachholaktionen später.

Praxisbeispiel: Renovate im Fünfstern-Projekt

Das Fünfstern-Projekt hat Renovate nach einem konservativen Ansatz integriert. Die Konfiguration wurde bewusst restriktiv gestaltet, um Stabilität zu gewährleisten.

Schritt 1: Die Renovate-Konfiguration (renovate.json)

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended"
  ],
  "gitAuthor": "Renovate Bot ",
  "baseBranchPatterns": [
    "develop"
  ],
  "branchPrefix": "renovate/",
  "semanticCommits": "enabled",
  "commitMessagePrefix": "chore(deps):",
  "prConcurrentLimit": 3,
  "prCreation": "immediate",
  "labels": [
    "dependencies",
    "renovate"
  ],
  "automerge": false,
  "packageRules": [
    {
      "description": "Angular and Node.js Patch Updates (client/package.json only)",
      "groupName": "Angular and Node.js dependencies",
      "matchManagers": ["npm"],
      "matchFileNames": ["client/package.json"],
      "matchUpdateTypes": ["patch"]
    },
    {
      "description": ".NET Dependencies - Patch and Minor Updates",
      "groupName": ".NET dependencies",
      "matchManagers": ["nuget"],
      "matchFileNames": ["Directory.Build.targets"],
      "matchUpdateTypes": ["patch", "minor"]
    },
    {
      "description": "Disable Major Updates globally",
      "matchUpdateTypes": ["major"],
      "enabled": false
    },
    {
      "description": "Disable Minor/Major npm updates (only patch allowed)",
      "matchManagers": ["npm"],
      "matchFileNames": ["client/package.json"],
      "matchUpdateTypes": ["minor", "major"],
      "enabled": false
    }
  ]
}

Besonderheiten dieser Konfiguration:

• baseBranchPatterns: ["develop"] – Renovate arbeitet nur auf dem develop-Branch
• prConcurrentLimit: 3 – Maximal 3 gleichzeitige Merge Requests, um nicht zu viele auf einmal zu haben
• automerge: false – Manuelle Überprüfung ist erforderlich, keine automatischen Merges
• semanticCommits: enabled – Commits folgen dem Semantic Versioning Standard (chore(deps))
• Separate Regeln für Frontend und Backend – npm und NuGet haben unterschiedliche Update-Strategien
• Major-Updates sind deaktiviert – Verhindert grosse Breaking Changes ohne explizite Planung
• Nur npm-Patch-Updates – Minimale Risiken im Frontend
• .NET Minor-Updates erlaubt – Im Backend sind grössere Schritte erlaubt

Schritt 2: GitLab CI/CD Integration

Im .gitlab-ci.yml ist ein Renovate-Job definiert:

renovate:
    stage: .pre
    image: renovate/renovate:latest
    script:
      - renovate
    only:
      - schedules
    variables:
      RENOVATE_CONFIG_FILE: renovate.json
      RENOVATE_GITLAB_AUTOMERGE: "false"
      RENOVATE_PLATFORM: gitlab
      RENOVATE_ENDPOINT: https://gitlab.edorex.ch/api/v4
      RENOVATE_TOKEN: $RENOVATE_GITLAB_TOKEN
      RENOVATE_GIT_AUTHOR: "Renovate Bot "
      RENOVATE_AUTHOR_EMAIL: "renovate@edorex.ch"
      RENOVATE_AUTODISCOVER: "false"
      RENOVATE_REPOSITORIES: $CI_PROJECT_PATH
      GITHUB_TOKEN: $GITHUB_TOKEN
    tags:
      - docker
      - linux

Was passiert hier:

• stage: .pre – Der Job läuft vor allen anderen Stages
• only: schedules – Nur wenn ein GitLab-Schedule den Job auslöst
• RENOVATE_PLATFORM: gitlab – Renovate arbeitet mit GitLab, nicht GitHub
• RENOVATE_TOKEN – Authentifizierung mit GitLab-API
• RENOVATE_AUTODISCOVER: "false" – Nutzt die explizite Konfiguration

Schritt 3: Merge Request in der Praxis

Wenn Renovate ein Update findet, erstellt es einen MR wie diesen im Fünfstern-Projekt:

Titel: chore(deps): update Node.js to v22.21.0
Branch: renovate/node-22.x
Labels: dependencies, renovate
Beschreibung:
This MR updates the following dependencies in client/package.json:
- Node.js: 22.20.0 → 22.21.0 (patch)
---
**Release Notes:**
v22.21.0 includes bug fixes and performance improvements.
No breaking changes.
**Pipelines:**
✅ All tests passed
✅ Build successful
✅ No security vulnerabilities detected

Schritt 4: Code Review und Merge-Prozess

Der typische Workflow:

1. MR wird erstellt – Renovate hat eine neue Version gefunden
2. Pipeline läuft – Tests und Builds werden automatisch durchgeführt
3. Code Review – Ein Entwickler überprüft den MR
4. Tests überprüfen – Sicherstellen, dass alles noch funktioniert
5. Merge – MR wird in den develop-Branch gemergt

Da automerge: false aktiviert ist, bleibt die Kontrolle stets beim Team.
✅ No security vulnerabilities detected

Warum ein konservativer Ansatz?

Das Fünfstern-Projekt setzt bewusst auf Stabilität.

• Patch-Updates sind sicherer – sie beheben Fehler ohne neue Features.
• Minor-Updates werden manuell überprüft, um Risiken zu vermeiden.
• Major-Updates werden nur geplant durchgeführt.

Frontend und Backend werden getrennt behandelt:

• npm (Frontend): nur Patch-Updates
• NuGet (.NET): Patch und Minor erlaubt

Ausserdem werden maximal drei Merge Requests gleichzeitig erstellt, um Übersicht und Stabilität zu wahren.