Intégration et livraison continues sur Databricks à l'aide d'Azure DevOps
Cet article couvre Azure DevOps, qui est développé par un tiers. Pour contacter le fournisseur, consultez le support Azure DevOps Services.
Cet article vous guide dans la configuration d'Azure DevOps pour qu'il fonctionne avec Databricks. Plus précisément, vous configurerez un workflow d'intégration et de livraison continues (CI/CD) pour vous connecter à un repository Git, exécuter des Jobs à l'aide d'Azure Pipelines pour créer et tester une Python wheel (*.whl), et la déployer pour une utilisation dans des Notebooks Databricks.
Pour un aperçu de la CI/CD avec Databricks, consultez CI/CD sur Databricks. Pour les meilleures pratiques, consultez les workflows CI/CD sur Databricks et les meilleures pratiques de développement sur Databricks.
À propos de l'exemple
L'exemple de cet article utilise deux pipelines pour collecter, déployer et exécuter des exemples de code Python et des notebooks Python stockés dans un repository Git distant.
Le premier pipeline, connu sous le nom de pipeline de build , prépare les artefacts de build pour le second pipeline, connu sous le nom de pipeline de release . Séparer le pipeline de build du pipeline de release vous permet de créer un artefact de build sans le déployer ou de déployer simultanément des artefacts issus de plusieurs builds. Construction des pipelines de build et de release :
- Créer une machine virtuelle Azure pour le pipeline de build.
- Copiez les fichiers de votre repository Git vers la machine virtuelle.
- Créez un fichier tar compressé avec gzip qui contient le code Python, les notebooks Python et les fichiers de configuration de build, de déploiement et d'exécution associés.
- Copiez le fichier tar compressé gzip sous forme de fichier zip dans un emplacement pour que le pipeline de publication y accède.
- Créez une autre machine virtuelle Azure pour le pipeline de mise en production.
- Obtenez le fichier zip à partir de l'emplacement du pipeline de build, puis décompressez le fichier zip pour obtenir le code Python, les notebooks Python et les fichiers de paramètres de build, de déploiement et d'exécution associés.
- Déployez le code Python, les notebooks Python et les fichiers de configuration de build, de déploiement et d'exécution associés vers votre workspace Databricks distant.
- Créez les fichiers de code des composants de la bibliothèque Python wheel dans un fichier Python wheel.
- Exécutez des tests unitaires sur le code du composant pour vérifier la logique dans le fichier Python wheel.
- Exécutez les Notebooks Python, dont l'un appelle la fonctionnalité du fichier Python wheel.
Avant de commencer
Pour utiliser l'exemple de cet article, vous devez avoir :
- Un projet Azure DevOps existant. Si vous n'avez pas encore de projet, créez un projet dans Azure DevOps.
- Un repository existant avec un fournisseur Git que Azure DevOps prend en charge. Vous ajouterez le code Python d'exemple, le Notebook Python d'exemple et les fichiers de paramètres de publication associés à ce repository. Si vous n'avez pas encore de repository, créez-en un en suivant les instructions de votre fournisseur Git. Ensuite, connectez votre projet Azure DevOps à ce repository si vous ne l'avez pas déjà fait. Pour les instructions, suivez les liens dans référentiels source pris en charge.
- L'exemple de cet article utilise l'authentification OAuth machine-to-machine (M2M) pour authentifier un Service Principal Microsoft Entra ID auprès d'un Workspace Databricks. Vous devez disposer d'un Microsoft Entra ID Service Principal avec un secret OAuth Databricks pour ce Service Principal. Consultez Autoriser l'accès du Service Principal à Databricks avec OAuth.
Étape 1 : Ajoutez les fichiers de l'exemple à votre repository
Dans cette étape, dans le repository de votre fournisseur Git tiers, vous ajoutez tous les fichiers d'exemple de cet article que vos pipelines Azure DevOps construisent, déploient et exécutent sur votre workspace Databricks distant.
Étape 1.1 : Ajouter les fichiers du composant Python Wheel
Dans l'exemple de cet article, vos pipelines Azure DevOps construisent et testent des unités d'un fichier Python wheel. Un Notebook Databricks appelle ensuite la fonctionnalité du fichier Python wheel construit.
Pour définir la logique et les tests unitaires pour le fichier Python wheel que les notebooks exécutent, à la racine de votre repository, créez deux fichiers nommés addcol.py et test_addcol.py, et ajoutez-les à une structure de dossier nommée python/dabdemo/dabdemo dans un dossier Libraries, visualisée comme suit :
└── Libraries
└── python
└── dabdemo
└── dabdemo
├── addcol.py
└── test_addcol.py
Le fichier addcol.py contient une fonction de bibliothèque qui est ensuite intégrée dans un fichier Python wheel, puis installée sur les clusters Databricks. C'est une simple fonction qui ajoute une nouvelle colonne, remplie par un littéral, à un DataFrame Apache Spark :
# Filename: addcol.py
import pyspark.sql.functions as F
def with_status(df):
return df.withColumn("status", F.lit("checked"))
Le fichier test_addcol.py contient des tests pour passer un objet DataFrame fictif à la fonction with_status, définie dans addcol.py. Le résultat est ensuite comparé à un objet DataFrame contenant les valeurs attendues. Si les valeurs correspondent, le test réussit :
# Filename: test_addcol.py
import pytest
from pyspark.sql import SparkSession
from dabdemo.addcol import *
class TestAppendCol(object):
def test_with_status(self):
spark = SparkSession.builder.getOrCreate()
source_data = [
("paula", "white", "paula.white@example.com"),
("john", "baer", "john.baer@example.com")
]
source_df = spark.createDataFrame(
source_data,
["first_name", "last_name", "email"]
)
actual_df = with_status(source_df)
expected_data = [
("paula", "white", "paula.white@example.com", "checked"),
("john", "baer", "john.baer@example.com", "checked")
]
expected_df = spark.createDataFrame(
expected_data,
["first_name", "last_name", "email", "status"]
)
assert(expected_df.collect() == actual_df.collect())
Pour permettre à l'interface CLI Databricks d'empaqueter correctement ce code de bibliothèque dans un fichier Python wheel, créez deux fichiers nommés __init__.py et __main__.py dans le même dossier que les deux fichiers précédents. De plus, créez un fichier nommé setup.py dans le dossier python/dabdemo, visualisé comme suit :
└── Libraries
└── python
└── dabdemo
├── dabdemo
│ ├── __init__.py
│ ├── __main__.py
│ ├── addcol.py
│ └── test_addcol.py
└── setup.py
Le fichier __init__.py contient le numéro de version et l'auteur de la bibliothèque. Remplacez <my-author-name> par votre nom :
# Filename: __init__.py
__version__ = '0.0.1'
__author__ = '<my-author-name>'
import sys, os
sys.path.append(os.path.join(os.path.dirname(__file__), "..", ".."))
Le fichier __main__.py contient le point d'entrée de la bibliothèque :
# Filename: __main__.py
import sys, os
sys.path.append(os.path.join(os.path.dirname(__file__), "..", ".."))
from addcol import *
def main():
pass
if __name__ == "__main__":
main()
Le fichier setup.py contient des paramètres supplémentaires pour la création de la bibliothèque sous forme de fichier Python wheel. Remplacez <my-url>, <my-author-name>@<my-organization> et <my-package-description> par des valeurs valides :
# Filename: setup.py
from setuptools import setup, find_packages
import dabdemo
setup(
name = "dabdemo",
version = dabdemo.__version__,
author = dabdemo.__author__,
url = "https://<my-url>",
author_email = "<my-author-name>@<my-organization>",
description = "<my-package-description>",
packages = find_packages(include = ["dabdemo"]),
entry_points={"group_1": "run=dabdemo.__main__:main"},
install_requires = ["setuptools"]
)
Étape 1.2 : Ajoutez un Notebook de tests unitaires pour le fichier Python wheel.
Plus tard, le Databricks CLI exécute un job de notebook. Ce job exécute un notebook Python dont le nom de fichier est run_unit_tests.py. Ce notebook exécute pytest par rapport à la logique de la bibliothèque Python wheel.
Pour exécuter les tests unitaires de l'exemple de cet article, ajoutez à la racine de votre repository un fichier Notebook nommé run_unit_tests.py contenant le contenu suivant :
# Databricks notebook source
# COMMAND ----------
# MAGIC %sh
# MAGIC
# MAGIC mkdir -p "/Workspace${WORKSPACEBUNDLEPATH}/Validation/reports/junit/test-reports"
# COMMAND ----------
# Prepare to run pytest.
import sys, pytest, os
# Skip writing pyc files on a readonly filesystem.
sys.dont_write_bytecode = True
# Run pytest.
retcode = pytest.main(["--junit-xml", f"/Workspace{os.getenv('WORKSPACEBUNDLEPATH')}/Validation/reports/junit/test-reports/TEST-libout.xml",
f"/Workspace{os.getenv('WORKSPACEBUNDLEPATH')}/files/Libraries/python/dabdemo/dabdemo/"])
# Fail the cell execution if there are any test failures.
assert retcode == 0, "The pytest invocation failed. See the log for details."
Étape 1.3 : Ajouter un Notebook qui appelle le fichier Python wheel
Plus tard, la CLI Databricks exécute un autre job de Notebook. Ce Notebook crée un objet DataFrame, le transmet à la fonction with_status de la bibliothèque Python wheel, affiche le résultat et signale les résultats d'exécution du Job. Créez à la racine de votre repository un fichier Notebook nommé dabdemo_notebook.py avec le contenu suivant :
# Databricks notebook source
# COMMAND ----------
# Restart Python after installing the Python wheel.
dbutils.library.restartPython()
# COMMAND ----------
from dabdemo.addcol import with_status
df = (spark.createDataFrame(
schema = ["first_name", "last_name", "email"],
data = [
("paula", "white", "paula.white@example.com"),
("john", "baer", "john.baer@example.com")
]
))
new_df = with_status(df)
display(new_df)
# Expected output:
#
# +------------+-----------+-------------------------+---------+
# │ first_name │ last_name │ email │ status │
# +============+===========+=========================+=========+
# │ paula │ white │ paula.white@example.com │ checked │
# +------------+-----------+-------------------------+---------+
# │ john │ baer │ john.baer@example.com │ checked │
# +------------+-----------+-------------------------+---------+
Étape 1.4 : Créer la configuration du bundle
L'exemple de cet article utilise les Declarative Automation Bundles pour définir les paramètres et les comportements pour la création, le déploiement et l'exécution du fichier Python wheel, des deux Notebooks et du fichier de code Python. Les Declarative Automation Bundles permettent d'exprimer des projets de données, d'analytique et de ML complets sous forme de collection de fichiers sources. Consultez Que sont les Declarative Automation Bundles ?.
Pour configurer le bundle pour l’exemple de cet article, créez un fichier nommé databricks.yml à la racine de votre repository. Dans cet exemple de fichier databricks.yml, remplacez les espaces réservés suivants :
- Remplacez
<bundle-name>par un nom de programme unique pour le bundle. Par exemple,azure-devops-demo. - Remplacez
<job-prefix-name>par une chaîne pour identifier de manière unique les jobs créés dans votre Databricks Workspace pour cet exemple. Par exemple,azure-devops-demo. - Remplacez
<spark-version-id>par l'ID de version de Databricks Runtime pour vos clusters de Job, par exemple13.3.x-scala2.12. - Remplacez
<cluster-node-type-id>par l'ID du type de nœud de cluster pour vos Job clusters, par exemplei3.xlarge. - Notez que
devdans le mappagetargetsspécifie l'hôte et les comportements de déploiement associés. Dans les implémentations réelles, vous pouvez donner à cette cible un nom différent dans vos propres bundles.
Voici le contenu du fichier databricks.yml de cet exemple.
# Filename: databricks.yml
bundle:
name: <bundle-name>
variables:
job_prefix:
description: A unifying prefix for this bundle's job and task names.
default: <job-prefix-name>
spark_version:
description: The cluster's Spark version ID.
default: <spark-version-id>
node_type_id:
description: The cluster's node type ID.
default: <cluster-node-type-id>
artifacts:
dabdemo-wheel:
type: whl
path: ./Libraries/python/dabdemo
resources:
jobs:
run-unit-tests:
name: ${var.job_prefix}-run-unit-tests
tasks:
- task_key: ${var.job_prefix}-run-unit-tests-task
new_cluster:
spark_version: ${var.spark_version}
node_type_id: ${var.node_type_id}
num_workers: 1
spark_env_vars:
WORKSPACEBUNDLEPATH: ${workspace.root_path}
notebook_task:
notebook_path: ./run_unit_tests.py
source: WORKSPACE
libraries:
- pypi:
package: pytest
run-dabdemo-notebook:
name: ${var.job_prefix}-run-dabdemo-notebook
tasks:
- task_key: ${var.job_prefix}-run-dabdemo-notebook-task
new_cluster:
spark_version: ${var.spark_version}
node_type_id: ${var.node_type_id}
num_workers: 1
spark_env_vars:
WORKSPACEBUNDLEPATH: ${workspace.root_path}
notebook_task:
notebook_path: ./dabdemo_notebook.py
source: WORKSPACE
libraries:
- whl: '/Workspace${workspace.root_path}/files/Libraries/python/dabdemo/dist/dabdemo-0.0.1-py3-none-any.whl'
targets:
dev:
mode: development
Pour plus d’informations sur la syntaxe du fichier databricks.yml, veuillez consulter la configuration des Declarative Automation Bundles.
Étape 2 : Définissez le pipeline de build
Azure DevOps fournit une interface utilisateur hébergée dans le cloud pour définir les étapes de votre pipeline CI/CD à l'aide de YAML. Pour plus d’informations sur Azure DevOps et les pipelines, consultez la documentation Azure DevOps.
Dans cette étape, vous utilisez le balisage YAML pour définir le pipeline de build, qui crée un artefact de déploiement. Pour déployer le code sur un workspace Databricks, vous spécifiez l'artefact de construction de ce pipeline comme entrée dans un pipeline de publication. Vous définissez ce pipeline de publication plus tard.
Pour exécuter des pipelines de build, Azure DevOps fournit des agents d’exécution à la demande et hébergés dans le cloud qui prennent en charge les déploiements vers Kubernetes, les machines virtuelles, Azure Functions, Azure Web Apps et de nombreuses autres cibles. Dans cet exemple, vous utilisez un agent à la demande pour automatiser la création de l'artefact de déploiement.
Définissez le pipeline de construction d'exemple de cet article comme suit :
- Connectez-vous à Azure DevOps puis cliquez sur le Link Se connecter pour ouvrir votre projet Azure DevOps.
Si le portail Azure s'affiche à la place de votre projet Azure DevOps, cliquez sur Plus de services > Organisations Azure DevOps > Mes organisations Azure DevOps , puis ouvrez votre projet Azure DevOps.
-
Cliquez sur Pipelines dans la barre latérale, puis cliquez sur Pipelines dans le menu Pipelines .

-
Cliquez sur le bouton Nouveau pipeline et suivez les instructions à l'écran. (Si vous avez déjà des pipelines, cliquez plutôt sur Créer un pipeline .) À la fin de ces instructions, l'éditeur de pipeline s'ouvre. Ici, vous définissez votre script de pipeline de build dans le fichier
azure-pipelines.ymlqui s'affiche. Si l'éditeur de pipeline n'est pas visible à la fin des instructions, sélectionnez le nom du pipeline de build, puis cliquez sur Modifier .Vous pouvez utiliser le sélecteur de branch Git
pour personnaliser le processus de build pour chaque branch de votre repository Git. Il est recommandé, comme bonne pratique CI/CD, de ne pas effectuer de travail de production directement dans la branch
mainde votre repository. Cet exemple suppose qu’une branch nomméereleaseexiste dans le repository à utiliser à la place demain.
Le script de pipeline de build
azure-pipelines.ymlest stocké par default à la racine du repository Git distant que vous associez au pipeline. -
Remplacez le contenu de démarrage du fichier de votre pipeline par la définition suivante,
azure-pipelines.ymlpuis cliquez sur **Enregistrer**.YAML# Specify the trigger event to start the build pipeline.
# In this case, new code merged into the release branch initiates a new build.
trigger:
- release
# Specify the operating system for the agent that runs on the Azure virtual
# machine for the build pipeline (known as the build agent). The virtual
# machine image in this example uses the Ubuntu 22.04 virtual machine
# image in the Azure Pipeline agent pool. See
# https://learn.microsoft.com/azure/devops/pipelines/agents/hosted#software
pool:
vmImage: ubuntu-22.04
# Download the files from the designated branch in the remote Git repository
# onto the build agent.
steps:
- checkout: self
persistCredentials: true
clean: true
# Generate the deployment artifact. To do this, the build agent gathers
# all the new or updated code to be given to the release pipeline,
# including the sample Python code, the Python notebooks,
# the Python wheel library component files, and the related Databricks asset
# bundle settings.
# Use git diff to flag files that were added in the most recent Git merge.
# Then add the files to be used by the release pipeline.
# The implementation in your pipeline will likely be different.
# The objective here is to add all files intended for the current release.
- script: |
git diff --name-only --diff-filter=AMR HEAD^1 HEAD | xargs -I '{}' cp --parents -r '{}' $(Build.BinariesDirectory)
mkdir -p $(Build.BinariesDirectory)/Libraries/python/dabdemo/dabdemo
cp $(Build.Repository.LocalPath)/Libraries/python/dabdemo/dabdemo/*.* $(Build.BinariesDirectory)/Libraries/python/dabdemo/dabdemo
cp $(Build.Repository.LocalPath)/Libraries/python/dabdemo/setup.py $(Build.BinariesDirectory)/Libraries/python/dabdemo
cp $(Build.Repository.LocalPath)/*.* $(Build.BinariesDirectory)
displayName: 'Get Changes'
# Create the deployment artifact and then publish it to the
# artifact repository.
- task: ArchiveFiles@2
inputs:
rootFolderOrFile: '$(Build.BinariesDirectory)'
includeRootFolder: false
archiveType: 'zip'
archiveFile: '$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip'
replaceExistingArchive: true
- task: PublishBuildArtifacts@1
inputs:
ArtifactName: 'DatabricksBuild'
Étape 3 : définir le pipeline de publication
Le pipeline de publication déploie les artefacts de build du pipeline de build vers un environnement Databricks. Séparer le pipeline de publication à cette étape du pipeline de build aux étapes précédentes vous permet de créer un build sans le déployer ou de déployer des artefacts de plusieurs builds simultanément.
-
Dans votre projet Azure DevOps, dans le menu Pipelines de la barre latérale, cliquez sur Mises en production .

-
Cliquez sur Nouveau > Nouveau pipeline de publication . (Si vous avez déjà des pipelines, cliquez plutôt sur Nouveau pipeline .)
-
Sur le côté de l'écran se trouve une liste de Template en vedette pour les modèles de déploiement courants. Pour ce pipeline de publication d'exemple, cliquez sur
.

-
Dans la boîte Artefacts sur le côté de l'écran, cliquez sur
. Dans le volet Ajouter un artefact , pour Source (pipeline de build) , sélectionnez le pipeline de build que vous avez créé précédemment. Cliquez ensuite sur Ajouter .

-
Vous pouvez configurer la façon dont le pipeline est Trigger en cliquant sur
pour afficher les options de Triggering sur le côté de l'écran. Si vous souhaitez qu'une publication soit lancée automatiquement en fonction de la disponibilité de l'artefact de build ou après un workflow de requête pull, activez le trigger approprié. Pour l'instant, dans cet exemple, à la dernière étape de cet article, vous trigger manuellement le pipeline de construction, puis le pipeline de déploiement.

-
Cliquez sur Enregistrer > OK .
Étape 3.1 : Définir les variables d'environnement pour le pipeline de publication
Le pipeline de version de cet exemple s'appuie sur les variables d'environnement suivantes, que vous pouvez ajouter en cliquant sur Ajouter dans la section Variables de pipeline de l'onglet tab , avec une Portée de Stage 1 :
BUNDLE_TARGET, qui doit correspondre au nomtargetdans votre fichierdatabricks.yml. Dans l'exemple de cet article, il s'agit dedev.DATABRICKS_HOST, qui représente l'URL par workspace de votre workspace Databricks, commençant parhttps://, par exemplehttps://adb-<workspace-id>.<random-number>.azuredatabricks.net. N'incluez pas le/de fin après.net.DATABRICKS_CLIENT_ID, qui représente l'ID d'application du Microsoft Entra ID Service Principal.DATABRICKS_CLIENT_SECRET, qui représente le secret OAuth de Databricks pour le service principal Microsoft Entra ID.
Étape 3.2 : Configurez l'agent de publication pour le pipeline de publication
-
Cliquez sur le link **1 Job, 0 tâche** dans l'objet **Étape 1**.

-
Dans l'onglet **tab**, cliquez sur **Job d'agent**.
-
Dans la section **Sélection d'agent**, pour **Pool d'agents**, sélectionnez **Azure Pipelines**.
-
Pour la spécification de l'agent , sélectionnez le même agent que celui que vous avez spécifié plus tôt pour l'agent de build, dans cet exemple, ubuntu-22.04 .

-
Cliquez sur Enregistrer > OK .
Étape 3,3 : définissez la version de Python pour l'agent de publication.
-
Cliquez sur le signe plus dans la section **Agent Job**, indiquée par la flèche rouge dans la figure suivante. Une liste consultable des tâches disponibles apparaît. Il existe également un marketplace tab pour les plug-ins tiers qui peuvent être utilisés pour compléter les tâches Azure DevOps standard. Vous ajouterez plusieurs tâches à l'agent de publication au cours des prochaines étapes.

-
La première tâche que vous ajoutez est Utiliser la version Python , située dans la tab Outil . Si vous ne trouvez pas cette tâche, utilisez la zone de Recherche pour la rechercher. Lorsque vous le trouvez, sélectionnez-le, puis cliquez sur le bouton Ajouter à côté de la tâche Utiliser la version Python .

-
Comme pour le pipeline de build, vous voulez vous assurer que la version de Python est compatible avec les scripts appelés dans les tâches suivantes. Dans ce cas, cliquez sur la tâche Utiliser Python 3.x à côté de Agent job , puis définissez la spécification de version sur
3.10. Définissez également le nom d'affichage surUse Python 3.10. Ce pipeline suppose que vous utilisez Databricks Runtime 13.3 LTS sur les clusters, qui ont Python 3.10.12 installé.
-
Cliquez sur Enregistrer > OK .
Étape 3.4 : Décompressez l'artefact de build du pipeline de build.
-
Ensuite, demandez à l'agent de publication d'extraire le fichier Python wheel, les fichiers de paramètres de publication associés, les Notebooks et le fichier de code Python du fichier zip à l'aide de la tâche **Extraire les fichiers** : cliquez sur le signe plus dans la section **Job d'agent**, sélectionnez la tâche **Extraire les fichiers** dans l'onglet **tab**, puis cliquez sur **Ajouter**.
-
Cliquez sur la tâche Extraire les fichiers à côté du Job d'agent , définissez les Modèles de fichiers d'archive sur
**/*.zipet définissez le Dossier de destination sur la variable système$(Release.PrimaryArtifactSourceAlias)/Databricks. Définissez également le Nom d'affichage surExtract build pipeline artifact.
$(Release.PrimaryArtifactSourceAlias) représente un alias généré par Azure DevOps pour identifier l’emplacement de la source de l’artefact principal sur l’agent de publication, par exemple _<your-github-alias>.<your-github-repo-name>. Le pipeline de publication définit cette valeur comme variable d’environnement RELEASE_PRIMARYARTIFACTSOURCEALIAS dans la phase Initialiser le job pour l’agent de publication. Voir les variables de version classique et d'artefacts.
-
Définir Nom d'affichage sur
Extract build pipeline artifact.
-
Cliquez sur Enregistrer > OK .
Étape 3,5 : Définir la variable d'environnement BUNDLE_ROOT
Pour que l'exemple de cet article fonctionne comme prévu, vous devez définir une variable d'environnement nommée BUNDLE_ROOT dans le pipeline de publication. Declarative Automation Bundles utilise cette variable d'environnement pour déterminer l'emplacement du fichier databricks.yml. Pour définir cette variable d'environnement :
- Utilisez la tâche Variables d'environnement : cliquez à nouveau sur le signe plus dans la section Agent job , sélectionnez la tâche Variables d'environnement dans l'onglet Utility tab , puis cliquez sur Ajouter .
Si la tâche Variables d'environnement n'est pas visible dans la tab Utilitaire , saisissez Environment Variables dans le champ Recherche et suivez les instructions à l'écran pour ajouter la tâche à la tab Utilitaire . Cela pourrait vous obliger à quitter Azure DevOps, puis à revenir à cet endroit où vous vous étiez arrêté(e).
- Pour les **Variables d'environnement (séparées par des virgules)**, saisissez la définition suivante :.
BUNDLE_ROOT=$(Agent.ReleaseDirectory)/$(Release.PrimaryArtifactSourceAlias)/Databricks
$(Agent.ReleaseDirectory) représente un alias généré par Azure DevOps pour identifier l’emplacement du répertoire de publication sur l’agent de publication, par exemple /home/vsts/work/r1/a. Le pipeline de publication définit cette valeur comme variable d’environnement AGENT_RELEASEDIRECTORY dans la phase Initialiser le job pour l’agent de publication. Voir variables de publication classiques et d’artefacts. Pour des informations sur $(Release.PrimaryArtifactSourceAlias), consultez la note de l’étape précédente.
-
Définir Nom d'affichage sur
Set BUNDLE_ROOT environment variable.
-
Cliquez sur Enregistrer > OK .
Étape 3.6. Installez Databricks CLI et les outils de compilation Python wheel.
-
Ensuite, installez le CLI Databricks et les outils de build Python wheel sur l'agent de publication. L'agent de publication appellera le CLI Databricks et les outils de build Python wheel dans les prochaines tâches. Pour ce faire, utilisez la tâche Bash : cliquez à nouveau sur le signe plus dans la section Agent Job , sélectionnez la tâche Bash dans l'onglet tab , puis cliquez sur Ajouter .
-
Cliquez sur la tâche Bash Script à côté de Agent job .
-
Pour Type , sélectionnez Inline .
-
Remplacez le contenu de **Script** par la commande suivante, qui installe le CLI Databricks et les outils de construction Python wheel :
Bashcurl -fsSL https://raw.githubusercontent.com/databricks/setup-cli/main/install.sh | sh
pip install wheel -
Définir Nom d'affichage sur
Install Databricks CLI and Python wheel build tools.
-
Cliquez sur Enregistrer > OK .
Étape 3.7 : Valider le bundle d’actifs Databricks
À cette étape, vous vous assurez que le fichier databricks.yml est syntaxiquement correct.
-
Utilisez la tâche Bash : cliquez à nouveau sur le signe plus dans la section Job d'agent , sélectionnez la tâche Bash dans l'onglet tab , puis cliquez sur Ajouter .
-
Cliquez sur la tâche Bash Script à côté de Agent job .
-
Pour Type , sélectionnez Inline .
-
Remplacez le contenu de Script par la commande suivante, qui utilise la CLI Databricks pour vérifier si le fichier
databricks.ymlest syntaxiquement correct :Bashdatabricks bundle validate -t $(BUNDLE_TARGET) -
Définir Nom d'affichage sur
Validate bundle. -
Cliquez sur Enregistrer > OK .
Étape 3.8 : Déployer le bundle
Dans cette étape, vous créez le fichier Python wheel et déployez le fichier Python wheel créé, les deux Notebooks Python et le fichier Python du pipeline de mise en production dans votre Workspace Databricks.
-
Utilisez la tâche Bash : cliquez à nouveau sur le signe plus dans la section Job d'agent , sélectionnez la tâche Bash dans l'onglet tab , puis cliquez sur Ajouter .
-
Cliquez sur la tâche Bash Script à côté de Agent job .
-
Pour Type , sélectionnez Inline .
-
Remplacez le contenu de Script par la commande suivante, qui utilise l'interface CLI Databricks pour créer le fichier Python wheel et pour déployer les exemples de fichiers de cet article depuis le pipeline de publication vers votre workspace Databricks :
Bashdatabricks bundle deploy -t $(BUNDLE_TARGET) -
Définir Nom d'affichage sur
Deploy bundle. -
Cliquez sur Enregistrer > OK .
Étape 3,9 : Exécuter le Notebook de test unitaire pour le Python wheel
Dans cette étape, vous exécutez un Job qui exécute le Notebook de test unitaire dans votre Workspace Databricks. Ce Notebook exécute des tests unitaires par rapport à la logique de la bibliothèque Python wheel.
-
Utilisez la tâche Bash : cliquez à nouveau sur le signe plus dans la section Job d'agent , sélectionnez la tâche Bash dans l'onglet tab , puis cliquez sur Ajouter .
-
Cliquez sur la tâche Bash Script à côté de Agent job .
-
Pour Type , sélectionnez Inline .
-
Remplacez le contenu de Script par la commande suivante, qui utilise l'interface CLI Databricks pour exécuter le Job dans votre Workspace Databricks :
Bashdatabricks bundle run -t $(BUNDLE_TARGET) run-unit-tests -
Définir Nom d'affichage sur
Run unit tests. -
Cliquez sur Enregistrer > OK .
Étape 3.10 : Exécuter le Notebook qui appelle le Python wheel
Dans cette étape, vous exécutez un job qui exécute un autre Notebook dans votre Workspace Databricks. Ce Notebook fait appel à la bibliothèque Python wheel.
-
Utilisez la tâche Bash : cliquez à nouveau sur le signe plus dans la section Job d'agent , sélectionnez la tâche Bash dans l'onglet tab , puis cliquez sur Ajouter .
-
Cliquez sur la tâche Bash Script à côté de Agent job .
-
Pour Type , sélectionnez Inline .
-
Remplacez le contenu de Script par la commande suivante, qui utilise l'interface CLI Databricks pour exécuter le Job dans votre Workspace Databricks :
Bashdatabricks bundle run -t $(BUNDLE_TARGET) run-dabdemo-notebook -
Définir Nom d'affichage sur
Run notebook. -
Cliquez sur Enregistrer > OK .
Vous avez maintenant terminé de configurer votre pipeline de publication. Cela devrait se présenter comme suit :

Étape 4 : Exécuter les pipelines de build et de release
Dans cette étape, vous exécutez les pipelines manuellement. Pour savoir comment exécuter les pipelines automatiquement, voir Spécifier les événements qui déclenchent les pipelines et Release Trigger.
Pour exécuter le pipeline de build manuellement :
- Dans le menu **Pipelines** de la barre latérale, cliquez sur **Pipelines**.
- Cliquez sur le nom de votre pipeline de build, puis cliquez sur Exécuter le pipeline .
- Pour Branch/tag , sélectionnez le nom de la Branch dans votre repository Git qui contient tout le code source que vous avez ajouté. Cet exemple suppose que cela se trouve dans la Branch
release. - Cliquez sur **Exécuter**. La page d'exécution du pipeline de build apparaît.
- Pour voir la progression du pipeline de construction et pour afficher les logs associés, cliquez sur l'icône tournante à côté de Job .
- Une fois que l'icône Job devient un coche vert, procédez à l'exécution du pipeline de publication.
Pour exécuter le pipeline de publication manuellement :
- Une fois le pipeline de build exécuté avec succès, dans le menu Pipelines de la barre latérale, cliquez sur Releases .
- Cliquez sur le nom de votre pipeline de déploiement, puis cliquez sur Créer une publication .
- Cliquez sur Créer .
- Pour voir la progression du pipeline de publication, dans la liste des versions, cliquez sur le nom de la dernière version.
- Dans la zone **Étapes**, cliquez sur **Étape 1**, puis cliquez sur **Logs**.