Abhängigkeiten ohne Schmerzen auf dem neuesten Stand zu halten

Jedes Projekt beginnt mit neuen Abhängigkeiten. Ein Jahr später sind die Hälfte veraltet. Zwei Jahre später erfordert das Upgrade einer Bibliothek das Upgrade von fünf anderen, dem Framework und der Sprachversion, und plötzlich ist ein "kleines Update" ein dreitägiges Projekt.

Die Lösung sind keine heroischen Upgrade-Sprints. Es sind kleine, konstante, automatisierte Updates. Renovate und Dependabot machen das möglich, wenn man sie so einrichtet, dass sie helfen, anstatt Sie mit Zugwünschen zu überfluten.

Warum sich Updates stapeln

• Niemand besitzt sie. Updates sind wichtig, aber nie dringend, bis eine Schwachstelle sie dringend macht.
• Angst, Dinge zu brechen. Ohne gute Tests fühlt sich jede Aktualisierung riskant an.
• Zu viele auf einmal. Ein Bot in einem alten Repo aktiviert, produziert 50 Pull-Anfragen am ersten Tag, und die Leute ignorieren sie einfach alle.

Dependabot gegen Renovieren

Dependabot ist in GitHub eingebaut. Einfach einzuschalten, verarbeitet Sicherheitswarnungen und Versionaktualisierungen für die gängigsten Ökosysteme. Gut genug für viele Projekte.

Erneuern (von Mend, Open Source) ist leistungsfähiger und flexibler:

• Unterstützt weit mehr Paketmanager und Dateitypen: Dockerfiles, Helm-Charts, Kubernetes-Manifest, Terraform, GitHub-Aktionen und benutzerdefinierte Regex-basierte Abgleichung für fast alles.
• Sehr flexibel Gruppen, Zeitpläne und Automergerungen Regeln.
• A Abhängigkeits-Dashboard Ausgabe zeigt alles, was aussteht.
• Funktioniert auf GitHub, GitLab, Bitbucket, Azure DevOps und mehr.

Für Infrastruktur-schwere Repositories bevorzuge ich Renovate, weil es Bildtags, Diagrammversionen und auch festgegründete Aktions-SHAs aktualisieren kann.

Meine Konfiguration erneuern

Eine ruhige Startkonfiguration:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended", ":dependencyDashboard"],
  "schedule": ["before 7am on monday"],
  "timezone": "Europe/Berlin",
  "prConcurrentLimit": 5,
  "minimumReleaseAge": "3 days",
  "packageRules": [
    {
      "matchUpdateTypes": ["patch", "minor"],
      "matchCurrentVersion": "!/^0/",
      "groupName": "non-major dependencies",
      "automerge": true
    },
    {
      "matchManagers": ["github-actions"],
      "groupName": "github actions",
      "pinDigests": true
    },
    {
      "matchDatasources": ["docker"],
      "pinDigests": true
    }
  ],
  "vulnerabilityAlerts": {
    "schedule": ["at any time"],
    "labels": ["security"]
  }
}

Was das macht:

• Wochenplan Also kommen die Updates in einer Charge, nicht die ganze Woche lang.
• Eine Begrenzung von fünf offenen PR Damit niemand überflutet wird.
• minimumReleaseAge Er wartet einige Tage nach der Veröffentlichung, bevor er ihn vorschlägt. Viele schädliche Paketversionen werden innerhalb weniger Tage entdeckt und entfernt, ebenso wie viele defekte Versionen.
• Gruppen Nicht-große Aktualisierungen in ein PR und Autoschließungen Sie, wenn alle Prüfungen bestehen.
• Pins für GitHub-Aktionen und Docker-Bilder in Digests, und hält diese Daten auf dem neuesten Stand.
• Sicherheitsbehebungen überspringen den Zeitplan und sofort ankommen.

Kleine Updates jede Woche sind langweilig. Ein riesiges Upgrade alle zwei Jahre ist ein Projekt. Wählen Sie langweilig.

Automerge, sicher

Automerging-Dependency-Updates klingen vielleicht riskant, aber sie halten den Prozess überschaubar. Die Regeln sind:

• Gute Tests Das läuft auf jeder PR. Automerge ohne Tests ist Glücksspiel.
• Erforderliche Statusüberprüfungen In der Branch-Schutz, so dass nichts verschmilzt, es sei denn CI ist grün.
• Nur für Risikobereitschaften: Patch und Nebenversionen von stabilen (1.0+) Paketen, Entwicklerabhängigkeiten, Linters.
• Vermische nie die Hauptversionen. Die werden von Menschen bewertet.

Handhabung von Änderungen bei Bruch

Wichtige Neuigkeiten benötigen Aufmerksamkeit:

• Erneuerung umfasst Veröffentlichungsnotizen in der PR. Lesen Sie sie.
• Aktualisierung Einfach ein Hauptfach nach dem anderen.Nicht fünf zusammen.
• Für große Projekte, stellen Sie eine eigene Gruppe auf und planen Sie Zeit dafür, wie für jedes andere Projekt.
• KI-Codierungsagenten sind hier zunehmend nützlich: Wenn ein Upgrade den Build bricht, weil eine API geändert wurde, kann ein Agent die Codeänderungen in derselben PR vorschlagen.

Bilder und Diagramme auch

Die Applikationsabhängigkeit ist nur ein Teil der Geschichte. Infrastruktur hat auch Abhängigkeiten:

• Grundbilder in Dockerfiles
• Steuerkartenversionen in deinen GitOps-Repos
• Bildtags für Behälter in Kubernetes Manifests
• Terraform-Anbieter und -module
• GitHub-Aktionen Versionen

Die Handgriffe sind alle neu. Das Aktualisieren der Basisbilder ist eine der einfachsten Möglichkeiten, Schwachstellen in Ihren Containern zu reduzieren.

Also, wo fange ich an?

Schalten Sie Renovate (oder Dependabot) in einem Repository mit einem wöchentlichen Zeitplan und einem PR-Limit ein. Aktivieren Sie die automatische Verschmelzung für Patch-Updates, sobald Sie Ihren Tests vertrauen. Erweitern Sie auf kleinere Updates, dann auf Infrastrukturdateien. Innerhalb eines Monats wird das Aktualisieren zu Hintergrundgeräuschen statt zu einem Projekt.

Meine Meinung: Abhängigkeiten gehen wie Milch, nicht wie Wein. Ein Roboter soll sie frisch halten, ein bisschen jede Woche.

Desly