Software lizenzieren, die auf flüchtigen CI- und Build-Agenten läuft, ohne Sitzplätze zu verbrauchen

Lizenzmodelle wurden überwiegend für Maschinen entworfen, die an Ort und Stelle bleiben — ein Desktop, ein Server, eine Workstation. CI- und Cloud-Build-Agenten verletzen diese Annahme bewusst: Sie existieren für die Dauer eines Jobs und verschwinden dann, und der nächste Job bekommt eine brandneue VM oder einen Container. Richten Sie eine knotengebundene Lizenz auf diese Umgebung, tut sie genau das Falsche — jeder Build sieht wie eine neue Maschine aus, aktiviert, verbraucht einen Sitzplatz, und dann wird die Maschine zerstört, ohne ihn je freizugeben. Eine Zehn-Sitzplatz-Lizenz kann vor dem Mittagessen erschöpft sein. Die Lösung ist kein größeres Sitzplatzkontingent; es ist, die Dimension zu lizenzieren, die tatsächlich variiert.

Warum Flüchtiges die Knotenbindung bricht

Die Knotenbindung leitet einen Fingerabdruck aus der Hardware einer Maschine ab und bindet die Lizenz daran, sodass ein Sitzplatz ein eigenständiges Gerät repräsentiert. Das ist für Desktops genau richtig und für flüchtige Rechenleistung genau falsch, wo „eigenständiges Gerät“ eine bedeutungslose Einheit ist — alle paar Minuten gibt es ein neues, keines hält, und was Sie wirklich begrenzen wollen, ist nicht wie viele Maschinen, sondern wie viel gleichzeitige (oder gesamte) Nutzung.

Schlimmer noch, auch die Aufräum-Annahme versagt. Knotengebundene Sitzplätze werden normalerweise durch eine explizite Deaktivierung freigegeben, wenn ein Nutzer die Maschine wechselt. Ein CI-Runner wird nicht deaktiviert; er wird gelöscht. Sein Sitzplatz verweilt also, bis etwas ihn zurückfordert, und in einer belebten Pipeline werden Sitzplätze weit schneller verbraucht, als irgendein manueller Prozess sie freigibt.

Drei Modelle, die zu flüchtiger Rechenleistung passen

Wählen Sie danach, was Sie wirklich begrenzen wollen.

Floating / Nebenläufigkeit. Lizenzieren Sie die Zahl gleichzeitiger Nutzungen, nicht der Maschinen. Ein Pool von N nebenläufigen Leases bedeutet, dass höchstens N Builds gleichzeitig laufen; die Lease eines beendeten (oder zerstörten) Runners wird zurückgewonnen und der nächste Build nimmt sie. Das ist die natürliche Passung, wenn Parallelität das ist, was Sie verkaufen — siehe Floating Concurrent Licenses. Kombinieren Sie es mit Heartbeat-Lease-Reaping, damit ein Runner, der ohne Deaktivierung verschwindet, seine Lease nach einem kurzen Timeout freigegeben bekommt, statt sie verweilen zu lassen.

Build-gescoptes Entitlement. Müssen Sie nur die Funktion in CI freischalten (belegen, dass der Kunde lizenziert ist, ohne Maschinen zu zählen), validieren Sie ein signiertes Entitlement mit einem Token, das überhaupt keinen Sitzplatz verbraucht. Der Build prüft das Entitlement offline und läuft; nichts ist knotengebunden.

Gemessene Builds. Ist die faire Einheit die Gesamtzahl der Läufe, messen Sie sie — zählen Sie Builds als Nutzung gegen ein Kontingent, mit einem Idempotenzschlüssel, damit ein wiederholter Build nicht doppelt zählt.

CI erkennen und den richtigen Pfad nehmen

Der Implementierungs-Dreh- und Angelpunkt ist, Ihre Software wissen zu lassen, dass sie in CI ist, damit sie den flüchtigen Pfad statt des Desktop-Pfads nimmt:

static bool IsCi() =>
    Environment.GetEnvironmentVariable("CI") is "true" or "1"
    || Environment.GetEnvironmentVariable("GITHUB_ACTIONS") == "true"
    || Environment.GetEnvironmentVariable("GITLAB_CI") == "true"
    || Environment.GetEnvironmentVariable("TF_BUILD") == "true"      // Azure Pipelines
    || Environment.GetEnvironmentVariable("JENKINS_URL") is not null;

// In CI, validate against a concurrency/entitlement path — not a node-locked activation.
var result = IsCi()
    ? keyright.ValidateFloating()   // or a build-scoped entitlement check
    : keyright.Activate();          // normal desktop node-lock

Das Desktop-Erlebnis bleibt unverändert; der CI-Pfad validiert einfach die dort sinnvolle Dimension und schreibt nie eine Aktivierung je Maschine, die einen Sitzplatz stranden ließe.

Mit Keyright umsetzen

Keyright unterstützt alle drei Modelle — Floating-Nebenläufigkeit mit Heartbeat-Reaping, build-gescopte Entitlements, die ohne Sitzplatzverbrauch validiert werden, und gemessenes Build-Zählen — sodass Sie flüchtige CI und autoskalierte Agenten nach Nebenläufigkeit oder Nutzung statt nach Maschine lizenzieren und nie zusehen, wie eine Pipeline Ihre Sitzplätze erschöpft. Jeder Pfad validiert offline gegen eine signierte Nutzlast, sodass ein Runner mit eingeschränktem Ausgang trotzdem funktioniert. Keyright ist selbstgehostet, sodass Ihre Entitlements und Nutzungsdaten auf von Ihnen kontrollierter Infrastruktur bleiben.

Sehen Sie sich die Tarife an oder beginnen Sie mit Floating Concurrent Licenses und fügen Sie CI-Erkennung hinzu, um Runner dorthin zu leiten.