Zum Hauptinhalt springen
Connic
Platform

Deployment

Agenten werden per Git-Push oder CLI in der Connic Cloud bereitgestellt. Deployment-Tests und Build Logs ermöglichen die Prüfung, bevor ein erfolgreiches Deployment aktiviert wird.

Zuletzt aktualisiert
Auf dieser Seite

Überblick

Connic unterstützt zwei Deployment-Methoden für unterschiedliche Workflows:

Git-Integration

Verbinde ein Git-Repository mit einem Projekt. Pushes auf konfigurierte Branches lösen Deployments aus.

  • • Automatisch bei jedem Push
  • • Zuordnung von Branches zu Environments
  • • Unterstützt GitHub, GitLab und Bitbucket
CLI Deployments

Starte das Deployment lokal oder aus einer CI/CD-Pipeline, wenn das Connic-Projekt nicht mit einem Git-Repository verbunden ist.

  • • Der Quellcode kann bei jedem Git-Provider liegen
  • • In CI/CD-Pipelines einsetzbar
  • • In das Standard-Environment oder ein bestimmtes Environment deployen

Git-Integration

Verbinde ein Git-Repository, um bei einem Push automatisch zu deployen. Connic unterstützt GitHub, GitLab und Bitbucket.

1

Repository verbinden

  1. Öffne Projekt-Settings → Git & Environments
  2. Klicke auf Connect und wähle einen Provider aus (GitHub, GitLab oder Bitbucket)
  3. Erlaube Connic den Zugriff auf die Repositories. GitLab.com verwendet OAuth. Für Self-Managed GitLab ab Version 15.5 wird die Instanz zuerst unter Account → Git Accounts mit einem Personal Access Token hinzugefügt, das den Scope api hat. Der GitLab-Benutzer muss Administrator sein oder in jedem Repository die Rolle Maintainer oder Owner haben.
  4. Wähle das Repository aus, das das Verzeichnis agents/ und alle unterstützenden Projekt-Verzeichnisse enthält
  5. Bei einem Monorepo wird Repository root directory auf den Pfad gesetzt, in dem das Connic SDK Projekt liegt (z. B. services/agents). Lass das Feld leer, wenn die SDK-Dateien im Root-Verzeichnis des Repositories liegen.
  6. Connic installiert einen Webhook im Repository, um Pushes sowie Pull oder Merge Requests zu erkennen
2

Environment-Branches konfigurieren

  1. Öffne Projekt-Settings → Git & Environments
  2. Lege für jedes Environment den Git Branch fest, der Deployments auslöst
  3. Pushes auf Branches, die keinem Environment zugeordnet sind, werden ignoriert

Zum Beispiel:

  • • Produktivumgebung → main
  • • Staging → develop
  • • Development → feature/customer-import (optional)
3

Per Push deployen

Pushe auf den konfigurierten Branch. Connic erkennt den Push über Webhooks und erstellt ein Deployment.

terminal
# Per Push ein Deployment auslösen
git add .
git commit -m "Agenten aktualisieren"
git push origin main

PR Testing

Für GitHub- und GitLab-Repositories kann Connic die Suite aus einem Pull oder Merge Request ausführen, dessen Source-Branch im verbundenen Repository liegt. Das Ergebnis wird als Commit-Status connic/pr-tests gemeldet. Der Zielbranch bestimmt das zugeordnete Environment. Eine separat konfigurierte Testumgebung trennt den Testlauf von den Daten und Verbindungen der Produktivumgebung.

Unter PR Testing stehen weitere Informationen zur Einrichtung, zu Provider-spezifischen Merge-Checks, Wiederholungen und gemeinsam genutzten Environments.

CLI Deployments

Die CLI eignet sich für Deployments von einem lokalen Rechner oder aus einer CI/CD-Pipeline, wenn:

  • für das Projekt kein Git-Repository mit Connic verbunden ist
  • das Deployment aus einem lokalen Checkout oder einer CI/CD-Pipeline startet
  • das Quell-Repository einen beliebigen Git-Provider oder keinen Provider nutzt
1

SDK installieren

terminal
pip install connic-composer-sdk
2

Authentifizieren

Führe den Login-Befehl aus. Er öffnet das Dashboard, um einen API Key zu erstellen, und fragt anschließend nach dem erzeugten Login-Token:

terminal
connic login

Dadurch wird eine Datei .connic erstellt:

.connic
{
  "api_key": "cnc_xxxxxxxxxxxx",
  "project_id": "your-project-uuid"
}

Für CI/CD werden stattdessen die Umgebungsvariablen CONNIC_API_KEY und CONNIC_PROJECT_ID verwendet.

3

Environment-ID abrufen

Öffne Projekt-Settings → Git & Environments und kopiere die ID des Ziel-Environments.

4

Deploy

terminal
# In das Standard-Environment deployen
connic deploy

# In ein bestimmtes Environment deployen
connic deploy --env <environment-id>

Die CLI lädt unterstützte Dateien aus agents/, tools/, middleware/, schemas/, guardrails/, hooks/ und tests/ sowie requirements.txt hoch. Verschachtelte Dateien werden einbezogen.

CI/CD-Integration

Verwende die CLI in einer CI/CD-Pipeline, wenn das Connic Projekt mit keinem Git-Repository verbunden ist. Das Quell-Repository kann jeden Provider nutzen.

.github/workflows/deploy.yml
name: Deploy to Connic
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install connic-composer-sdk
      - run: connic deploy --env $CONNIC_ENV_ID
        env:
          CONNIC_API_KEY: ${{ secrets.CONNIC_API_KEY }}
          CONNIC_PROJECT_ID: ${{ secrets.CONNIC_PROJECT_ID }}
          CONNIC_ENV_ID: ${{ secrets.CONNIC_ENV_ID }}
.gitlab-ci.yml
deploy:
  stage: deploy
  script:
    - pip install connic-composer-sdk
    - connic deploy --env $CONNIC_ENV_ID
  variables:
    CONNIC_API_KEY: $CONNIC_API_KEY
    CONNIC_PROJECT_ID: $CONNIC_PROJECT_ID

Hinterlege CONNIC_API_KEY, CONNIC_PROJECT_ID und CONNIC_ENV_ID in den Einstellungen des Providers als CI/CD-Secrets.

Was während eines Deployments passiert

Der Code wird zu einem Deployment-Bundle zusammengestellt und zu Connic hochgeladen
Abhängigkeiten werden installiert und das Deployment wird gebaut
Die Testsuite läuft, wenn das Projekt tests/ enthält
Ein erfolgreiches Deployment wird verfügbar und erhält Traffic

Deployments überwachen

Status und Logs der Deployments stehen im Tab Deployments:

  • Sieh alle Deployments mit Status und Dauer
  • Klicke auf ein Deployment, um die Build Logs anzuzeigen
  • Das aktuell ausgelieferte Deployment ist mit „Active“ gekennzeichnet
Der Tab Deployments listet Deployments mit Status, Testergebnis und Build-Dauer auf. Das aktuell ausgelieferte Deployment ist als Active gekennzeichnet.
Der Tab Deployments: jedes Deployment mit Status, Deploy-Gate-Testergebnis und Build-Dauer. Das ausgelieferte Deployment ist als Active gekennzeichnet.
Projekte öffnen

Testphase (Deploy Gate)

Wenn ein Projekt tests/ enthält, bauen sowohl Git- als auch CLI Deployments das Deployment, führen die vollständige Suite aus und aktivieren es erst, wenn jeder Testfall bestanden wurde. Die Deployment-Detailseite zeigt die Pipeline live und die Ergebnisse jedes Testfalls.

Unter Das Deploy Gate stehen Informationen zur Auswahl einer separaten Testumgebung und zur Anzeige der Ergebnisse und dem nur in der CLI verfügbaren Flag --skip-tests. Die Anleitung für den ersten Test zeigt den Aufbau einer Suite.

Deployment zurücksetzen

Aktiviere im Tab Deployments ein anderes erfolgreiches Deployment:

  1. Öffne den Tab Deployments und wähle ein erfolgreiches Deployment aus
  2. Klicke für dieses Deployment auf den Button Activate
  3. Der Traffic wird ohne erneuten Build an das ausgewählte Deployment geleitet
Bei der Aktivierung wird das ausgewählte Deployment wiederverwendet und kein neuer Build ausgeführt.

Wenn ein Deployment fehlschlägt

Schlägt ein Build fehl, wird das Deployment als Failed markiert und das aktive Deployment bedient weiterhin Anfragen.

Einen Fehler untersuchen:

  1. Öffne den Tab Deployments und klicke auf das fehlgeschlagene Deployment
  2. Prüfe die Build Logs, um den Fehler zu finden

Häufige Fehlerursachen:

  • Fehlende Abhängigkeiten in requirements.txt
  • Ungültige Agent-YAML-Syntax (fehlerhafte Konfiguration oder fehlende Pflichtfelder)
  • Python-Importfehler in Dateien für Tools oder Middleware

Plattform entdecken

Environments

Environments und Branch-Zuordnung verwalten

Observability

Runs, Traces und Token-Nutzung überwachen

Testing

Deklarative Tests vor jedem Deployment

Variablen

Secrets und Einstellungen pro Environment konfigurieren