Was als Entwickler-Sitz zählt

Die Self-Service-Pläne sind über die Anzahl Entwickler-Sitze gestaffelt (Starter bis 5, Team bis 10, Business bis 25). Für Teams mit mehr als 25 Entwicklern gibt es den Enterprise-Plan ohne Sitz-Obergrenze, schreiben Sie uns. Damit Sie beim Buchen wissen, welche Klasse zu Ihrem Team passt, ist hier präzise, was ein Sitz ist und was nicht.

Was ein Sitz ist

Eine Sitz-Lizenz pro Person, die CodeCharter aktiv nutzt. Aktiv heißt mindestens eines der folgenden:

• Die CLI läuft auf der Workstation dieser Person.
• Die VS Code Extension ist auf der Workstation dieser Person installiert.
• Diese Person committet regelmäßig Code in ein Repository, dessen Pull Requests durch Ihre CodeCharter-Integration in der CI geprüft werden.

"Regelmäßig" ist als Faustregel mindestens ein Commit pro Monat gemeint. Einmalige Beiträge externer Contributor zählen nicht.

Was kein Sitz ist

• CI-Service-Accounts. Der API-Key, mit dem Ihre GitHub Action, GitLab Pipeline, Azure Pipeline o.ä. CodeCharter ausführt, ist kein eigener Sitz. Auch nicht, wenn Sie aus rein technischen Gründen mehrere Service-Accounts pro Stage verwenden.
• Read-only Reviewer, die Pull Requests inhaltlich prüfen, aber selbst keinen Code beitragen. Wer nur Annotations liest, braucht keinen Sitz.
• Engineering Manager und Product Owner, die keinen Code committen.
• QA-Tester, die keinen Code committen.
• Externe Auftragnehmer, die einmalig einen Pull Request beitragen.

Faustregel: nur wer schreibt oder dessen Maschine CodeCharter direkt aufruft, ist ein Sitz.

Was passiert, wenn Sie die Schwelle überschreiten?

Wir prüfen das nicht technisch. Sie verpflichten sich über die AGB, beim Erreichen der nächsthöheren Klasse zeitnah auf den passenden Plan zu wechseln. Den Wechsel machen Sie im Portal unter /account/billing selbst, Stripe rechnet die Differenz für den Rest der Periode anteilig ab. Schrumpft Ihr Team unter eine Schwelle, können Sie auf demselben Weg herunterstufen; das Downgrade wird zum Ende der laufenden Abrechnungsperiode wirksam und wird nicht anteilig verrechnet. Mehr unter Plan-Übersicht und Kündigung und Plan-Wechsel.

Wenn Sie unsicher sind, ob Sie knapp unter oder knapp über der Schwelle stehen, schreiben Sie uns gern an [email protected]. Wir prüfen das mit Ihnen und schlagen den passenden Plan vor.

CodeCharter im Team ausrollen

CodeCharter verwendet ein Ein-Konto-Modell: Eine Person aus Ihrem Team kauft den Plan über ihren eigenen Portal-Account, und dieser Account hält das Abonnement, die Lizenz und die API-Keys für das gesamte Team. Es gibt im Portal keine Organisations-Accounts, keine Mitglieder-Einladungen und keine Sitz-Zuweisungen.

Nach dem Kauf läuft der Rollout so ab:

1. Der Käufer lädt auf der Downloads-Seite das CLI-Archiv mit eingebetteter codecharter.license herunter, oder nur die Lizenzdatei selbst.
2. Kopieren Sie das Archiv oder die Lizenzdatei auf jede Entwickler-Maschine, die CodeCharter nutzen soll, bis zur Sitz-Anzahl Ihres Plans. Die Lizenzdatei ist nicht an eine Maschine gebunden, dieselbe Datei funktioniert also überall, siehe Lizenzdatei.
3. Für die CI erstellen Sie im Käufer-Account einen API-Key und hinterlegen ihn als Pipeline-Secret (CODECHARTER_API_KEY), siehe API-Keys in Secrets.

Ihre Kollegen brauchen keine eigenen Portal-Accounts. Registriert sich dennoch jemand, trägt dieser Account immer nur seinen eigenen 7-Tage-Trial; er kann nicht an Ihr bezahltes Abonnement angehängt werden. Belassen Sie Lizenz-Downloads, Plan-Wechsel und API-Keys beim Käufer-Account.

Sitz-Zählung auf Vertrauensbasis

CodeCharter erfasst Ihre Nutzung standardmäßig nicht, anonyme Telemetrie ist strikt Opt-in (siehe Telemetrie). Standardmäßig sendet die CLI nichts zurück, Ihr Quellcode und Ihre Findings verlassen Ihre Maschine nie; in der CI kontaktiert die CLI das Portal nur, um ihre kurzlebige Lizenz abzurufen. Die VS Code Extension sendet ebenfalls keine Nutzungsdaten. Die Sitz-Zählung basiert auf Vertrauen: Wählen Sie die Klasse, die zu Ihrem Team passt, und wechseln Sie, wenn Sie darüber hinauswachsen.