Environments

Deployment-Environments verbinden Git-Branches mit getrennten Workflows für Entwicklung, Staging und Produktivbetrieb. Jedes Environment erhält eigene Variablen.

Überblick

Environments trennen Code, Konfiguration und Daten für Entwicklung, Staging und Produktivbetrieb. Sie können unterschiedliche Agenten und Codeversionen enthalten, etwa wenn ihnen verschiedene Git-Branches zugeordnet sind. Ein typisches Setup verwendet getrennte Environments für Produktivbetrieb und Staging. Beide haben eigene Variablen, eine eigene Deployment-Pipeline und separat aufgezeichnete Runs. Jedes Projekt beginnt mit einem Standard-Environment.

Verwalte Environments unter Projekt-Settings → Git & Environments. Wie viele Environments verfügbar sind, hängt vom Abonnement ab.

Environment erstellen

Klicke auf Create Environment und gib einen Namen ein. Wenn das Projekt mit einem Git-Repository verbunden ist, ordne das Environment einem Git-Branch zu. Andernfalls verwendet das Environment CLI Deployments.

Git-Branch-Zuordnung

Wenn ein Git-Repository mit einem Projekt verbunden ist, kann jedes Environment einem bestimmten Branch zugeordnet werden. Ein Push auf diesen Branch löst ein Deployment in das entsprechende Environment aus. So sind beispielsweise folgende Workflows möglich:

Aktualisiere die Liste der verfügbaren Branches in den Projekt-Settings.

CLI Deployments

Projekte ohne verbundenes Git-Repository verwenden CLI Deployments. Kopiere die ID des Ziel-Environments aus den Einstellungen und übergib sie an den Deploy-Befehl:

connic deploy --env <environment-id>

Dieser Ansatz eignet sich auch für CI/CD-Pipelines, die nach eigener Logik in bestimmte Environments deployen. Vollständige CI/CD-Beispiele stehen in der Deployment-Dokumentation.

Standard-Environment

Ein Environment ist immer als default markiert. Das Standard-Environment wird beim Öffnen des Projekt-Dashboards ausgewählt und dient als Ziel für CLI Deployments, wenn kein Flag --env angegeben ist. Im Menü des Environments lässt sich ein anderes zum Standard machen.

Environment-Variablen

Variablen gelten jeweils nur für ein Environment. Damit lassen sich für Staging und Produktivumgebung unterschiedliche API Keys, Datenbank-URLs oder Feature Flags verwenden. Verwalte Variablen unter Projekt-Settings → Variables.

# Raw-Editor-Format (KEY=VALUE; sensible Keys mit ! markieren)
DATABASE_URL=postgresql://user:pass@host:5432/db
!OPENAI_API_KEY=sk-xxxxxxxxxxxx
LOG_LEVEL=info

# Zeilen, die mit # beginnen, sind Kommentare

import os
import httpx

async def call_external_api(query: str) -> dict:
    """Externe API mit Environment-spezifischen Zugangsdaten aufrufen."""
    api_key = os.environ["EXTERNAL_API_KEY"]
    api_url = os.environ.get("EXTERNAL_API_URL", "https://api.example.com")

    async with httpx.AsyncClient() as client:
        response = await client.post(
            api_url,
            headers={"Authorization": f"Bearer {api_key}"},
            json={"query": query},
        )
        response.raise_for_status()
        return response.json()

import os
from connic import StopProcessing

async def before(content: dict, context: dict) -> dict:
    """Anfragen mit einem privaten Authentifizierungsdienst validieren."""
    auth_url = os.environ.get("AUTH_SERVICE_URL")
    auth_secret = os.environ.get("AUTH_SERVICE_SECRET")

    if not auth_url or not auth_secret:
        raise StopProcessing("Authentifizierungsdienst nicht konfiguriert")

    payload = context.get("payload", {})
    # ... Validierungslogik mit payload, auth_url und auth_secret
    return content

Dev Environments

Dev Environments bilden die Grundlage für die Entwicklung mit Hot Reload von connic dev. Sie können kurzlebig sein und am Ende der Session automatisch gelöscht werden oder einen Namen erhalten und über Sessions hinweg bestehen bleiben. Im Environment-Selector werden sie getrennt von Standard-Environments angezeigt.

• In einem eigenen Bereich des Environment-Selectors gruppiert
• Code wird live vom lokalen Rechner synchronisiert; die Deployments-Seite zeigt die laufende Session mit einem Dev session-Badge
• Eigene Environment-Variablen und Verbindungen

Der vollständige Workflow steht in der Dev-Server-Dokumentation.

Separate Testumgebung

Für jedes Standard-Environment gibt es unter Settings → Git & Environments ein optionales Dropdown Test environment. Das Deploy Gate führt die Test Suite vor der Aktivierung des Deployments in diesem Environment aus und verwendet dabei dessen Variablen, Verbindungen und Zugangsdaten.

Ein Environment prod-test mit API Keys für Testsysteme und ohne Produktivverbindungen trennt die produktiven Systeme von der Testsuite für prod.

Wenn das Dropdown leer ist, laufen die Tests im Deploy-Environment selbst.

Zwischen Environments wechseln

Der Environment-Selector im Projekt-Header wechselt zwischen Environments. Das ausgewählte Environment bestimmt die im Dashboard sichtbaren Daten: Agenten, Runs, Verbindungen und Variablen gelten jeweils nur für das aktive Environment.