Aller au contenu principal
Dernière mise à jour le

Configurer le CI/CD pour votre agent Databricks Apps

Un pipeline CI/CD exécute chaque modification apportée à votre agent via une revue de code et un déploiement automatisé, de sorte que les déploiements de production ne dépendent pas de l'ordinateur portable d'un seul développeur. Une fois le pipeline configuré, chaque Merge vers votre Branch principale déploie et redémarre votre agent sur Databricks Apps.

Cette page couvre les éléments spécifiques à l'agent. CI/CD pour Databricks Apps avec GitHub Actions décrit la configuration du workflow de base : la fédération d'identité de charge de travail, l'environnement GitHub et le YAML de déploiement. Complétez d'abord cette page, puis retournez ici pour les ajouts qui s'appliquent aux applications d'agents.

Exigences​

Étape 1. Utilisez le workflow de démarrage​

Plusieurs Template d'agent dans databricks/app-templates fournissent un .github/workflows/deploy.yml prêt à l'emploi, de sorte que vous n'ayez pas à écrire le workflow à partir de zéro.

  1. Choisissez un template d'agent parmi databricks/app-templates, tel que agent-langgraph ou agent-openai-agents-sdk.
  2. Dans votre répertoire de Template cloné, vérifiez si .github/workflows/deploy.yml existe.
  3. Configurez le workflow :
    • **Si deploy.yml existe** : ouvrez-le, confirmez que databricks bundle run l'étape référence la clé de ressource de votre bundle à partir databricks.yml de, et suivez les prérequis dans le commentaire d'en-tête du fichier.
    • Si deploy.yml n'existe pas : Copiez-le depuis un Template qui existe, ou depuis Étape 4. ajoutez le workflow de déploiement. Ensuite, mettez à jour l'étape databricks bundle run <key> pour correspondre à la clé de ressource de votre bundle.

Étape 2. Préremplissez l’ID de l’expérience MLflow​

Les Template d'agent laissent MLFLOW_EXPERIMENT_ID vide dans databricks.yml. Le script quickstart le remplit localement lors de la première configuration, mais un nouveau runner CI ne le fait pas. Si experiment_id est vide, databricks bundle deploy échoue avec une erreur de type Terraform (For input string: "").

Pour corriger cela, commit la valeur renseignée :

  1. Exécutez uv run quickstart --profile <your-profile> localement sur la machine où vous avez créé l'agent.
  2. Vérifiez que la Ressource d'Experimentation dans databricks.yml (l'entrée avec name: 'experiment' sous resources.apps.<key>.resources) a maintenant un experiment_id numérique.
  3. commit la modification.

L'expérimentation est limitée au workspace, donc le même ID est valide pour chaque déploiement CI ciblant ce workspace. Si vous déployez sur plusieurs workspaces, déclarez une expérimentation par cible dans databricks.yml (une par bloc targets.<env>) ou utilisez une variable de bundle.

Accorder les autorisations Postgres pour les Template de mémoire Lakebase​

Les templates d'agent avancés (agent-langgraph-advanced, agent-openai-advanced) déclarent une ressource Lakebase Postgres à autoscaling directement dans databricks.yml. Avec Databricks CLI v0.295.0 et versions ultérieures, databricks bundle deploy provisionne la ressource à côté de l'application.

La ressource DAB postgres accorde au Service Principal Databricks de l'application un accès au niveau du Workspace au projet Lakebase, mais Lakebase conserve une couche distincte de rôles Postgres pour l'accès aux bases de données (schémas, tables et séquences). Le Service Principal Databricks a besoin d'un rôle Postgres avec les bons privilèges avant que l'agent puisse lire ou écrire ses tables de mémoire. Voir l'architecture d'authentification pour le modèle à deux couches.

L'octroi de ces privilèges de niveau Postgres est une configuration unique . Exécutez-le localement entre le bundle deploy er et le bundle rune. Le CI se redéploie après ce flux à travers le chemin standard deploy puis run, car le rôle Postgres du Service Principal Databricks persiste pendant toute la durée de vie de l'application.

  1. Déployez le bundle pour le provisionnement de la ressource Lakebase :

    Bash
    databricks bundle deploy --target prod

  2. Accorder au Service Principal Databricks les privilèges de niveau Postgres dont il a besoin :

    Bash
    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>

    Pour le template LangGraph, transmettez --memory-type langgraph. Le script accepte également --project <project> --branch <branch> pour le dimensionnement automatique de Lakebase, ou --instance-name <name> pour Lakebase provisionnée.

  3. start l’application :

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

Étape 3. Effectuer un test de fumée sur l'agent déployé​

databricks bundle run revient dès que le runner signale à l’agent de start, mais le processus de l’agent peut encore échouer au démarrage. Après la vérification de l’état de santé de Étape 5. Attendez que l’application soit saine, ajoutez l’étape de test de fumée suivante à deploy.yml qui envoie une requête canari à /invocations:

YAML
- 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."
remarque

Databricks Apps n'acceptent que les jetons OAuth pour l'invocation. Utilisez le jeton OAuth de databricks auth token Workspace ; les Databricks Apps rejettent tout autre type de jeton.

Ressources supplémentaires​

Sur cette page