Konfigurera CI/CD för din Databricks Apps-agent

En CI/CD-pipeline låter varje ändring i din agent gå genom kodgranskning och en automatiserad driftsättning, så utrullningar till produktion inte är beroende av någon enskild utvecklares bärbara dator. När pipelinen har konfigurerats distribueras och startas din agent om i Databricks Apps vid varje sammanslagning till huvudgrenen.

Den här sidan beskriver de agentspecifika delarna. CI/CD för Databricks-appar med GitHub Actions dokumenterar den grundläggande arbetsflödeskonfigurationen: arbetsbelastningsidentitetsfederation, GitHub-miljön och deploy-YAML-filen. Slutför sidan först och gå sedan tillbaka hit för de tillägg som gäller för agentappar.

Requirements

Steg 1. Använda startarbetsflödet

Flera agentmallar i databricks/appmallar levererar ett färdigt .github/workflows/deploy.yml, så du behöver inte skriva arbetsflödet från grunden.

  1. Välj en agentmall från databricks/appmallar, till exempel agent-langgraph eller agent-openai-agents-sdk.
  2. I din klonade mallkatalog kontrollerar du om .github/workflows/deploy.yml finns.
  3. Konfigurera arbetsflödet:
    • Om deploy.yml finns: Öppna den, bekräfta att steget databricks bundle run refererar till resursnyckeln för ditt paket från databricks.yml, och följ förutsättningarna i filens rubrikkommentar.
    • Om deploy.yml finns inte: Kopiera den från en mall som gör det eller från steg 4. Lägg till arbetsflödet för distribution. Uppdatera sedan steget så att det databricks bundle run <key> matchar ditt pakets resursnyckel.

Steg 2. Fyll ID:t för MLflow-experimentet i förväg

Agentmallar lämnar MLFLOW_EXPERIMENT_ID tomma i databricks.yml. quickstart-skriptet fyller i det lokalt vid första konfigurationen, men det gör inte en ny CI-runner. Om experiment_id är tom misslyckas databricks bundle deploy med ett Terraform-typfel (For input string: "").

För att åtgärda detta, checka in det ifyllda värdet:

  1. Kör uv run quickstart --profile <your-profile> lokalt på den dator där du skapade agenten.
  2. Kontrollera att experimentresursen i databricks.yml (posten med name: 'experiment' under resources.apps.<key>.resources) nu har ett numeriskt experiment_id.
  3. Genomför ändringen.

Experimentet är begränsat till arbetsytan, så samma ID är giltigt för varje CI-driftsättning som riktas mot den arbetsytan. Om du distribuerar till flera arbetsytor deklarerar du ett experiment per mål i databricks.yml (ett per targets.<env> block) eller använder en paketvariabel.

Bevilja Postgres-behörigheter för Lakebase-minnesmallar

De avancerade agentmallarna (agent-langgraph-advanced, agent-openai-advanced) deklarerar en Lakebase Postgres-resurs för automatisk skalning direkt i databricks.yml. Med Databricks CLI v0.295.0 och senare provisionerar databricks bundle deploy resursen tillsammans med appen.

DAB-resursen postgres ger appens tjänsthuvudnamn åtkomst på arbetsytenivå till Lakebase-projektet, men Lakebase behåller ett separat Postgres-rolllager för databasåtkomst (scheman, tabeller och sekvenser). Tjänstens huvudnamn behöver en Postgres-roll med rätt behörigheter innan agenten kan läsa eller skriva sina minnestabeller. Se Autentiseringsarkitektur för tvåskiktsmodellen.

Att bevilja dessa behörigheter på Postgres-nivå är en engångskonfiguration. Kör den lokalt mellan den första bundle deploy och bundle run. CI driftsätts om därefter via standardsökvägen deploy och sedan run, eftersom tjänsthuvudnamnets Postgres-roll finns kvar under appens hela livslängd.

  1. Distribuera paketet för att etablera Lakebase-resursen:

    databricks bundle deploy --target prod

  2. Ge tjänstens huvudnamn de behörigheter på Postgres-nivå som krävs:

    uv run python scripts/grant_lakebase_permissions.py \
  "$(databricks apps get <app-name> --output json | jq -r '.service_principal_client_id')" \
  --memory-type openai \
  --autoscaling-endpoint <endpoint>

    För LangGraph-mallen skickar du --memory-type langgraph. Skriptet accepterar också --project <project> --branch <branch> för automatisk skalning av Lakebase, eller --instance-name <name> för provisionerad Lakebase.

  3. Starta appen:

    databricks bundle run <bundle-key> --target prod

Steg 3. Gör ett röktest av den distribuerade agenten

databricks bundle run returnerar så snart runnern signalerar åt agenten att starta, men agentprocessen kan fortfarande misslyckas under uppstarten. Efter hälsokontrollen i steg 5. Vänta tills appen fungerar som den ska lägger du till följande steg för smoketest i deploy.yml, som skickar en canary-begäran till /invocations:

- name: Smoke test invocations
  env:
    APP_NAME: my-agent
  run: |
    APP_URL=$(databricks apps get "$APP_NAME" --output json | jq -r '.url')
    TOKEN=$(databricks auth token | jq -r '.access_token')
    STATUS=$(curl -sS -o /tmp/canary.json -w "%{http_code}" \
      -X POST "$APP_URL/invocations" \
      -H "Authorization: Bearer $TOKEN" \
      -H "Content-Type: application/json" \
      -d '{"input": [{"role": "user", "content": "ping"}], "stream": false}')
    if [ "$STATUS" != "200" ]; then
      echo "Smoke test failed with status $STATUS:" >&2
      cat /tmp/canary.json >&2
      exit 1
    fi
    echo "Smoke test passed."

Note

Databricks Apps accepterar endast OAuth-token för anrop. Använd arbetsytans OAuth-token från databricks auth token; Databricks Apps avvisar alla andra tokentyper.

Ytterligare resurser

  • Last updated on