Zum Hauptinhalt springen
connic

Code pushen.
connic baut, testet und betreibt ihn.

Aus jedem Push und jedem connic deploy wird ein getestetes Deployment. Server und Build-Pipeline brauchst du nicht, und ein Rollback kommt ohne neuen Build aus.

Deployments

Production
StatusDeploymentTestsDuration
Active
#3f9a1c2ea41f9c2
120
passed1.8m
Failed
#b70e44d19c2d7e0
120
1 failed1.4m
Deployed
#8d21f6a352be1f7
120
passed1.7m
Deployed
#61ac09e40e4d8b3
120
passed1.6m

Deine Tests entscheiden, was live geht.

connic baut jedes Deployment und führt zuerst deine Tests aus. Schlägt einer fehl, bleibt die aktuelle Version live.

Funktioniert mit GitHub, GitLab und Bitbucket, mit einem Branch pro Environment.

  1. Hochladen

    Ein Push auf den Branch des Environments startet das Deployment. Ohne Git lädt connic deploy das Projekt hoch.

    $ git push origin main # Git connected
    $ connic deploy --env Production # without Git
  2. Build

    connic installiert requirements.txt und löst Verbindungsdateien und Variablen für das Environment auf.

    Building
  3. Test

    Zuerst laufen alle Testfälle aus tests/, ein Fehlschlag markiert das Deployment als Failed.

    Run testsdone3/3 · 100%
  4. Aktivieren

    Das Deployment wird Active, seine Verbindungen greifen, und wartende Runs starten darauf.

    Active

Jeden Run begrenzen. Fehlgeschlagene Modellanfragen wiederholen.

Die Einstellungen stehen im Agenten-YAML, gehen mit jedem Deployment live und kommen beim Rollback mit zurück.

agents/shipment-tracker.yaml
version: "1.0"

name: shipment-tracker
description: Updates shipment status from carrier events
type: llm
model: connic/gpt-5.6-terra
max_concurrent_runs: 10
max_iterations: 50
timeout: 180

retry_options:
  attempts: 4
fallback_model: connic/gpt-5.6-luna

session:
  key: context.shipment_id
  ttl: 604800
  1. max_concurrent_runs

    Wie viele Runs dieses Agenten gleichzeitig laufen dürfen, begrenzt durch deinen Plan.

  2. max_iterations

    Iterationen der LLM-Schleife pro Run, damit Tool-Aufrufe nicht endlos weiterlaufen.

  3. timeout

    Sekunden, die ein Run laufen darf, von 5 bis zum Run-Timeout deines Plans.

  4. retry_options, fallback_model

    Jede Modellanfrage in einem LLM-Run hat 1 bis 10 Versuche. Nach dem ersten Fehlschlag des primären KI-Modells übernimmt fallback_model.

  5. session.ttl

    Sekunden ohne Aktivität, bis eine gespeicherte Session abläuft, mindestens 60. Ohne den Wert laufen Sessions nie ab.

Ein Run pro Sendung, egal wie viele Ereignisse ankommen.

Ein Concurrency Key aus dem Trigger-Payload erlaubt einen aktiven Run pro Sendung. Wartende Runs überstehen Deployments.

queue
Der Standard. Ein neuer Run wartet und startet in der Reihenfolge, in der sein Ereignis ankam.
drop
Ein neuer Run wird sofort abgebrochen, wenn er nur doppelte Arbeit wäre.
coalesce
Pro Schlüssel wartet nur ein Run. Ein neueres Ereignis ersetzt ihn, eine Welle von Updates endet also in einem Run mit dem neuesten Payload.
agents/shipment-tracker.yaml
name: shipment-tracker
type: llm
model: connic/gpt-5.6-terra
fallback_model: connic/gpt-5.6-luna
max_concurrent_runs: 10

concurrency:
  key: data.shipment_id
  on_conflict: coalesce
Runs
shipment-tracker
RunStatusdata.shipment_id
51c0a8f3e6b2 Queued
shp_20931

Waiting for the active run with the same concurrency key to finish.

e2d94a7716cf Cancelled
shp_20931

A newer run for the same concurrency key replaced this one.

0f7b3e5a9c18 Running
shp_20488
9b1e4c07d2aa Running
shp_20931

Ohne neuen Build zurückrollen.

Aktiviere ein früheres erfolgreiches Deployment. Die im Code deklarierten Verbindungen kommen mit den Variablenwerten von damals zurück.

Wartende Runs folgen der Live-Version
Noch wartende Runs starten auf der Version, die du aktiviert hast.
Die aktive Version läuft weiter
Schlagen Build, Testfall oder eine Änderung an Verbindungen fehl, wird nichts aktiviert. Das aktuelle Deployment läuft weiter.
Activate this deployment?

This deployment becomes the live version of Production.

Updated

  • Carrier eventsconnectors/carrier-events.yaml

Retired

  • Delivery webhooksconnectors/delivery-webhooks.yaml
CancelActivate

Häufig gestellte Fragen

Mit verbundenem Git startet ein Push auf den Branch eines Environments ein Deployment. Ohne Git lädt connic deploy das Projekt hoch. connic baut es, führt vorhandene Tests aus tests/ aus und aktiviert es, sobald alle Testfälle bestehen.

Ein Run nutzt das Deployment, das bei seinem Start aktiv ist. Runs, die beim Wechsel noch warten, starten auf dem neuen Deployment. Das gilt auch, wenn du ein früheres aktivierst.

Bei LLM-Agenten nicht. retry_options und fallback_model gelten für jede einzelne Modellanfrage, fertige Tool-Aufrufe und Middleware behalten also ihre Ergebnisse. Tool- und Sequential-Agenten wiederholen die Operation selbst, und rerun_middleware bestimmt, ob die before-Middleware noch einmal läuft.

Beide gelten: Der Concurrency Key erlaubt einen aktiven Run pro Wert, und max_concurrent_runs begrenzt, wie viele Runs des Agenten gleichzeitig laufen. Runs, die auf ihren Schlüssel warten, belegen keinen Platz. Sequential-Agenten unterstützen keine Concurrency-Regeln.

Ja. Aktiviere im Tab Deployments ein früheres erfolgreiches Deployment. connic schickt den Traffic ohne neuen Build dorthin und stellt die im Code deklarierten Verbindungen mit den Variablenwerten dieses Deployments wieder her.

Ein fehlgeschlagener Build oder Testfall markiert das Deployment als Failed, das aktive Deployment bedient den Traffic weiter. Build-Log und Ergebnisse je Testfall findest du auf der Seite des Deployments.