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.
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.
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 GitBuild
connic installiert requirements.txt und löst Verbindungsdateien und Variablen für das Environment auf.
BuildingTest
Zuerst laufen alle Testfälle aus tests/, ein Fehlschlag markiert das Deployment als Failed.
Run testsdone3/3 · 100%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.
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: 604800max_concurrent_runs
Wie viele Runs dieses Agenten gleichzeitig laufen dürfen, begrenzt durch deinen Plan.
max_iterations
Iterationen der LLM-Schleife pro Run, damit Tool-Aufrufe nicht endlos weiterlaufen.
timeout
Sekunden, die ein Run laufen darf, von 5 bis zum Run-Timeout deines Plans.
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.
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.
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: coalesceOhne 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.