Von Staging zum Produktivbetrieb: So isolieren Connic Environments KI-Agenten

Der Agent funktioniert. Er verarbeitet jede Testrechnung, und die Antworten überzeugen. Vor dem Deployment in den Produktivbetrieb stellen sich andere Fragen: Welchen Stripe Key verwendet der Agent, auf welche Datenbank zeigt seine Verbindung, und was passiert mit echten Kunden, wenn ein unfertiger Branch ausgeliefert wird?

Unsere Antwort darauf sind Environments: Jede Umgebung hat ihre eigene Konfiguration und kann Agenten aus einem anderen Git-Branch bereitstellen. Dieser Beitrag zeigt, wie die Isolation funktioniert, vom Git-Branch-Mapping über Secrets, Verbindungen und Budgets bis zum Test-Gate zwischen Merge und Produktivbetrieb.

Was ist ein Connic Environment?

Ein Environment ist eine isolierte Umgebung für die Ausführung von Agenten. YAML-Konfiguration und Python-Code werden in Git versioniert. Da Environments unterschiedlichen Branches folgen können, können sie verschiedene Codeversionen und Agenten enthalten. Zusätzlich verwaltet jedes Environment seine eigene Betriebskonfiguration:

Die Isolation reicht tiefer als die Konfiguration. Datenbankzeilen, Agentensitzungen, Retrieval-Inhalte, Variablen und Verbindungen sind jeweils an das Environment gebunden. Jedes Environment läuft auf einem eigenen Laufzeitdienst mit eigener Ereigniswarteschlange. Ein Auslöser aus Staging kann nicht in einem Runner der Produktivumgebung landen.

Jedes Projekt startet mit einer Standardumgebung. Eine übliche Einrichtung ergänzt ein zweites Environment: Die Produktivumgebung folgt main, Staging folgt develop. Zum Erstellen eines Environments sind ein Name und bei verbundenem Repository ein Branch erforderlich. Optional lassen sich die Variablen eines anderen Environments kopieren. Das Dashboard öffnet standardmäßig das Standard-Environment; auch connic deploy zielt darauf, wenn kein Environment angegeben ist.

Die Git-Branch-Zuordnung übernimmt das Routing

Jedes Environment kann einem Git-Branch folgen. Bei einem Push auf diesen Branch erstellt Connic aus genau diesem Commit ein neues Deployment für das Environment. Pushes auf Branches ohne Environment-Zuordnung werden ignoriert. Zwei Details dieser Zuordnung werden leicht übersehen:

Bei zwei schnellen Pushes ersetzt das neuere Deployment das ältere, das noch gebaut wird. Auch bei der Aktivierung geht keine Arbeit verloren: Das vorherige Deployment lässt seine laufenden Ausführungen auslaufen, bevor es stoppt; Ausführungen in der Queue werden mit dem neuen Deployment erneut ausgelöst.

Projekte ohne Git-Verbindung und Teams mit Bereitstellungen aus CI verwenden stattdessen die CLI. Jedes Environment hat eine ID, die in den Einstellungen verfügbar ist:

# deploy the current commit to a specific environment
connic deploy --env <environment-id>

Die Deployment-Dokumentation beschreibt den vollständigen Ablauf aus Build, Test und Aktivierung einschließlich CI-Beispielen.

Variablen und sensible Werte

Umgebungsvariablen sind Schlüssel-Wert-Paare pro Environment. Unterstützte Felder in Agenten-YAML, etwa URLs und Header von MCP-Servern, referenzieren sie als ${VAR_NAME}; Python Tools lesen sie aus os.environ. Beim Deployment werden die Werte aus der Konfiguration des aktiven Environments eingesetzt. Die versionierte YAML enthält somit keinerlei Zugangsdaten.

Wird eine Variable als sensibel markiert, bleibt ihr Wert nach dem Erstellen im Dashboard und in Logs maskiert und wird nie wieder von der API zurückgegeben. Die Werte werden verschlüsselt gespeichert und beim Deployment in die Agentencontainer injiziert.

Da die Injektion beim Deployment erfolgt, greifen Änderungen an Variablen einschließlich rotierter Secrets erst mit dem nächsten Deployment. Das laufende Deployment behält bis zur erneuten Bereitstellung die bisherigen Werte. Für gebündelte Änderungen lässt sich eine Variable in einem Schritt über mehrere Environments hinweg erstellen; ein neues Environment kann mit einer Kopie der Variablen eines anderen starten. Unser Leitfaden zur Absicherung von Agenten im Produktivbetrieb beschreibt das umfassendere Sicherheitskonzept.

Verbindungen werden pro Environment konfiguriert

Verbindungen lösen Agenten durch externe Ereignisse wie Stripe-Webhooks, Kafka-Topics, Postgres-Benachrichtigungen oder eingehende E-Mails aus und gehören genau zu einem Environment. Die Stripe-Verbindung in Staging und die Stripe-Verbindung der Produktivumgebung sind zwei getrennte Verbindungen mit eigener Konfiguration, eigenen Zugangsdaten und eigener Run History.

Genau dieser Teil wird von einfachen .env-Dateien nie abgedeckt. Zwei Sätze von Zugangsdaten lassen sich problemlos irgendwo speichern. Bei der Zuordnung von Ereignisquellen ist das anders: Welches Topic, welcher Webhook-Endpoint, welches Postfach? In Connic gehört diese Zuordnung zum Environment und wechselt zusammen mit ihm.

Die lokale Entwicklung wird genauso behandelt. Eine connic dev-Sitzung läuft in einem eigenen temporären oder benannten Entwicklungs-Environment mit eigenen Variablen und Verbindungen und wird in der Environment-Auswahl separat gruppiert. Ein Hot-Reload-Experiment kann einen Webhook nicht versehentlich an die Produktivumgebung senden.

Eigene Budgets pro Environment

KI-Modell-Kosten werden auf dieselbe Weise abgegrenzt. Budgetregeln gibt es in zwei Formen: Warnungen, die benachrichtigen, und Limits, die hart stoppen. Beide können sich täglich oder monatlich auf das gesamte Projekt, bestimmte Environments oder bestimmte Agenten beziehen.

Ein Limit beendet keine laufende Arbeit. Überschreiten die Kosten den Schwellenwert, werden neue Ausführungen in den betroffenen Environments in die Queue gestellt statt gestartet; der Grund wird an der jeweiligen Ausführung gespeichert. Nach Beginn der nächsten Periode oder einer Erhöhung des Limits werden die Ausführungen innerhalb weniger Minuten automatisch fortgesetzt. Eine typische Einrichtung nutzt ein kleines tägliches Limit für Staging und nur einen Warnschwellenwert für die Produktivumgebung. Die Dokumentation zur Nutzung erklärt die Einrichtung von Kostenwarnungen und Limits.

Das Deploy Gate: Tests vor jeder Veröffentlichung

Jedes Deployment durchläuft vor dem ersten Datenverkehr das Deploy Gate, unabhängig davon, ob es durch einen Push oder die CLI ausgelöst wurde:

Projekte ohne Verzeichnis tests/ überspringen das Gate; außerdem kann es pro Environment ein- oder ausgeschaltet werden. Die CLI bietet mit --skip-tests einen Ausweg; durch Git ausgelöste Deployments nutzen ihn jedoch nie: Ein Merge kommt nicht an der Suite vorbei.

Das Gate auf Testzugangsdaten ausrichten

Standardmäßig läuft die Suite in dem Environment, das gerade bereitgestellt wird, und verwendet dessen Variablen und Verbindungen. In der Produktivumgebung wäre genau das riskant: Ein Release Test soll weder eine echte Karte belasten noch in die Live-Datenbank schreiben. Die Lösung ist ein Test-Environment-Override. In der Produktivumgebung wird die Einstellung Test environment auf ein separates Environment wie prod-test gesetzt, das Stub-Zugangsdaten und ausschließlich für Staging gedachte Verbindungen enthält. Das Gate führt die Suite dann mit den Variablen und Zugangsdaten dieses Environments aus; die Testausführungen landen in dessen Run History statt in der Produktivumgebung.

Die Suite vor dem Merge ausführen

Dieselbe Suite kann auch vor statt nach dem Merge laufen. In einem Branch zugeordneten Environment mit aktiviertem PR Testing führt jeder Pull Request auf diesen Branch die Tests in einem Test-Environment aus, falls eines gesetzt ist, und meldet am Commit den Status connic/pr-tests. So können Teams vor dem Merge einen erfolgreichen Check verlangen. PR Testing ist im Pro-Tarif verfügbar. Die Test-Dokumentation erklärt Deploy Gate und PR-Tests. Unser Beitrag zum Testframework beschreibt die Definition von Testfällen.

Eine sichere Veröffentlichung von Anfang bis Ende

Die Veröffentlichung im Produktivbetrieb läuft damit so ab:

• 1.Branches zuordnen. Die Produktivumgebung folgt main und ist das Standard-Environment; Staging folgt develop.
• 2.prod-test erstellen. Ein separates Environment mit Testzugangsdaten und einer Sandbox-Verbindungskonfiguration, das als Test-Environment der Produktivumgebung eingestellt wird.
• 3.Auf develop bauen. Jeder Push stellt die Version in Staging bereit, wo der Agent mit Staging-Schlüsseln auf Sandbox-Dienste zugreift.
• 4.Pull Request auf main öffnen. PR-Tests führen die Suite gegen prod-test aus und posten einen connic/pr-tests-Check am Commit.
• 5.Mergen. Die Produktivumgebung baut aus dem Merge-Commit. Das Deploy Gate führt die Suite erneut in prod-test aus und aktiviert das Deployment nur, wenn alle Tests bestehen. Das vorherige Deployment schließt laufende Aufgaben ab und stoppt anschließend.
• 6.Falls etwas durchrutscht: Rollback. Das vorherige Deployment lässt sich direkt aus der History aktivieren, ohne einen neuen Build zu erstellen.

Testausführungen verwenden dabei keine Zugangsdaten der Produktivumgebung; Aktivierungen und Rollbacks erfolgen bewusst. Jedes Deployment ist ein Build aus einem bekannten Commit und durch dieselbe Suite abgesichert. Der gesamte Ablauf ist im Beitrag darüber beschrieben, wie Teams Agenten vom Prototyp in den Produktivbetrieb bringen.

Run History und Audit-Trail

Auch nach dem Deployment bleibt der Betrieb getrennt. Ausführungen werden ihrem Environment zugeordnet, die Environment-Auswahl begrenzt die Dashboard-Ansicht, und jedes Environment führt eine Deployment History mit Status, Commit-Hash, Testergebnissen und Laufzeiten.

Für die Frage, wer was getan hat, erfasst das Projekt-Audit-Log Änderungen an Environments und Variablen, wobei Werte nie ins Log geschrieben werden. Hinzu kommen Deployments sowie Ereignisse der Git-Verbindung mit Vorher-nachher-Snapshots. Durch einen Push ausgelöste Deployments werden als Systemaktionen protokolliert. Der Audit-Trail unterscheidet somit manuell gestartete Deployments von automatisch durch Git ausgelösten Deployments. Er ist unter Projekt-Settings → Audit Log einsehbar.

Erste Schritte

• 1.Das Repository verbinden und anschließend Projekt-Settings → Git & Environments öffnen. Die Produktivumgebung dem Branch main und ein neues Staging-Environment dem Branch develop zuordnen.
• 2.Variablen pro Environment hinzufügen und Schlüssel sowie Zugangsdaten als sensibel markieren.
• 3.Verbindungen in jedem Environment erstellen: eine Testkonfiguration in Staging und eine Live-Konfiguration in der Produktivumgebung.
• 4.Optional ein Test-Environment und ein Budgetlimit für Staging ergänzen und die Änderungen anschließend pushen.

Die vollständige Referenz steht in der Environments-Dokumentation oder auf der Funktionsseite zu Environments. Bei einem neuen Connic-Projekt beschreibt der Quickstart-Leitfaden die erste Agentenbereitstellung, bevor Staging und Produktivbetrieb getrennt konfiguriert werden.