Bundles en CI/CD door vier omgevingen

Aangeklikt werk is onreviewbaar

Een pipeline die in de workspace-interface is gebouwd, werkt op de dag dat hij gebouwd wordt. Zes maanden later weet niemand wie het schema wijzigde, waarom de clustergrootte verdubbelde of hoe je het geheel in een andere omgeving herbouwt. Bundles lossen dat op door het project als code te beschrijven: jobs, pipelines, dashboards en hun instellingen staan in bestanden, gaan door pull requests en worden via een pipeline uitgerold.

De documentatie noemt de functie nu Declarative Automation Bundles en zegt dat ze eerder Databricks Asset Bundles heette. Veel teams, en onze eigen artikelen, zeggen nog Asset Bundles of DABs. Het is hetzelfde. De opdrachtregel blijft databricks bundle.

In deze les bouwen we een bundle op, definiëren we de vier omgevingen en stellen we de pipelineregels op die een wijziging van een featurebranch naar productie brengen. Terraform voor de omliggende infrastructuur behandelen we niet. Die heeft een eigen plek in de governancecursus.

Wat een bundle is

Een bundle verpakt bronbestanden, definities van Databricks-resources (zoals jobs, pipelines en dashboards), workspaceconfiguratie en tests in één project dat naar een doelomgeving wordt uitgerold. Hij is gedefinieerd in YAML en is een functie van de Databricks CLI, volgens de documentatie versie 0.218.0 of hoger.

De levenscyclus heeft vier commando's die je dagelijks gebruikt:

Het hoofdbestand is databricks.yml in de projectroot. Volgens de documentatie zijn de sleutels op het hoogste niveau:

• bundle: kerninstellingen. name is verplicht.
• include: andere configuratiebestanden of padpatronen om te laden.
• variables: eigen waarden die door de bundle worden hergebruikt.
• resources: de workspace-objecten die worden uitgerold, zoals jobs, pipelines en dashboards.
• targets: uitrolomgevingen zoals dev en prod. Precies één mag default: true hebben.
• workspace: instellingen zoals host en root_path.
• permissions: rechten die op de gedefinieerde resources worden toegepast.
• run_as: de gebruiker of service principal die de bundle draait.

Het minimale voorbeeld uit de documentatie laat zien hoe een target de basisdefinitie overschrijft. Het dev-target is de standaard, dus databricks bundle deploy gaat naar dev en databricks bundle deploy -t prod gaat naar productie.

bundle:
  name: hello-bundle
resources:
  jobs:
    hello-job:
      name: hello-job
      tasks:
        - task_key: hello-task
          existing_cluster_id: 1234-567890-abcde123
          notebook_task:
            notebook_path: ./hello.py
targets:
  dev:
    default: true
  prod:
    workspace:
      host: https://<production-workspace-url>
    resources:
      jobs:
        hello-job:
          name: hello-job
          tasks:
            - task_key: hello-task
              existing_cluster_id: 2345-678901-fabcd456

Een opzet in NexOps-stijl

Voor een domeinpipeline gebruiken we één bundle met een pipelineresource, een jobresource en vier targets. De listing is schematisch: de exacte sleutels van de pipeline- en jobresources hangen af van je CLI-versie, dus draai databricks bundle validate tegen het actuele schema.

# databricks.yml (schematisch). Vervang hosts en identiteiten per omgeving.
bundle:
  name: sales-orders
 
include:
  - resources/*.yml          # pipeline- en jobdefinities staan in eigen bestanden
 
variables:
  catalog:
    description: Unity Catalog-catalog voor deze omgeving
 
targets:
  dev:
    default: true
    variables: { catalog: dev_sales }
    workspace: { host: https://<dev-workspace-url> }
  test:
    variables: { catalog: test_sales }
    workspace: { host: https://<test-workspace-url> }
  acc:
    mode: production
    variables: { catalog: acc_sales }
    workspace: { host: https://<acc-workspace-url> }
    run_as: { service_principal_name: <acc-service-principal-application-id> }
  prd:
    mode: production
    variables: { catalog: prd_sales }
    workspace: { host: https://<prd-workspace-url> }
    run_as: { service_principal_name: <prd-service-principal-application-id> }

Drie details dragen het ontwerp. De catalog is een variabele, zodat dezelfde pipelinecode in dev naar dev_sales schrijft en in productie naar prd_sales. Resourcedefinities staan in resources/*.yml, waardoor databricks.yml kort blijft. En acc en prd draaien als service principal, nooit als persoon.

De vier omgevingen en vier branches

Onze standaard gebruikt vier omgevingen, dev, test, acc en prd, elk met een eigen workspace, catalogs, Key Vault en service principal. Er zijn vier langlevende branches: dev, test, acc en main, waarbij main naar productie uitrolt.

1. Maak een featurebranch vanuit dev.
2. Open een pull request naar dev. De build draait validatie en tests. Een reviewer keurt goed. Squash merge.
3. De pipeline rolt de bundle uit naar het dev-target.
4. Promoveer met een pull request van dev naar test, dan test naar acc, dan acc naar main. Sla nooit een omgeving over. Elke stap rolt uit naar het target van die omgeving.
5. Acceptatie en productie vragen twee reviewers en een goedkeuringspoort vóór de uitrol.

Maak bij hotfixes een branch vanuit main, rol uit via dezelfde pipeline en merge de fix terug naar beneden.

Ons artikel over declaratieve CI/CD met Asset Bundles loopt een volledige stroom door en dat over SAT uitrollen met bundles door dev, test, acceptatie en productie toont hetzelfde patroon op een echt product.

Wat de pipeline moet controleren

Draai dit bij elke pull request:

• Lint- en formatcontroles en unittests met een coverage-poort.
• databricks bundle validate voor elk gewijzigd target.
• Statische analyse, afhankelijkheden- en licentiescan en secret scanning.
• Infrastructuurcontroles als Terraform wijzigde.

Rol alleen uit vanuit de CI/CD-pipeline, met workload identity federation in plaats van opgeslagen geheimen. Draai databricks bundle deploy niet vanaf een laptop naar test, acc of prd. Een uitrol vanaf een laptop slaat elke controle over die je net hebt gebouwd.

Houd logica uit de YAML

Bundles beschrijven waar en wanneer dingen draaien. Zet bedrijfslogica in Python-pakketten of SQL-bestanden en houd notebooks dun: ze roepen de logica aan. Zo kun je de logica unittesten en blijft de bundle leesbaar. Hergebruik gedeelde include-bestanden voor gangbare resources, zoals policies, rechten, meldingen en tags, in plaats van ze tussen bundles te kopiëren.

Veelgemaakte fouten

• "Even" met de hand uitrollen. De omgevingen driften uit elkaar en niemand kan uitleggen waarom.
• Omgevingsnamen in code. Gebruik variabelen en targets.
• Een persoon als run_as. De uitrol breekt als die persoon vertrekt.
• Rechten aan gebruikers. Stel rechten in de bundle in, aan groepen.
• Eén bundle voor alles. Splits per domein, zodat een wijziging een kleine impact heeft.

Samenvatting

Beschrijf jobs en pipelines als bundle, met één target per omgeving en de catalog als variabele. Promoveer via vier branches met pull requests. Rol alleen uit vanuit de pipeline, valideer bij elke pull request en draai als service principal.

Volgende les: datakwaliteit en monitoring zodra de pipelines draaien.