Vývojový lifecycle v Azure Databricks

Git folders (dříve známé jako Repos) přinášejí do Azure Databricks workspace vizuálního Git klienta a API. Přímo z workspace klonujete repozitáře, vytváříte branche, commitujete a pushujete — bez přepínání do externích nástrojů. Podporovaní provideři: Azure DevOps, GitHub, GitLab a Bitbucket.

Git folder vytvoříte přes Workspace → Create → Git folder: zadáte URL repozitáře, providera a název složky. Po naklonování se obsah repozitáře objeví ve workspace a můžete rovnou pracovat s notebooky, Python soubory i SQL skripty.

Před začátkem práce vždy pull — pravidelné stahování změn minimalizuje integrační konflikty. Počítejte s tím, že pull, který změní zdrojový kód notebooku, resetuje jeho stav: outputy buněk, komentáře a verze notebooku se vyčistí podle nového obsahu.

K pořádku v repozitáři patří: .gitignore pro dočasné výstupy, credentials a environment-specifické konfigurace (na už trackované soubory se aplikuje až po jejich explicitním odebrání z Gitu), logická struktura složek a mazání staré branche u providera po merge — lokální branche přežívají až 30 dní po smazání remote branche.

Feature branch izoluje rozpracovanou práci od hlavní větve. V Git dialogu (tlačítko s názvem branche u notebooku) zvolíte Create branch, pojmenujete ji a založíte typicky z main. Konzistentní pojmenování se vyplatí:

Commit děláte z Git dialogu: UI zvýrazní změněné soubory, ukáže vizuální diff, napíšete popisnou commit message a dáte Commit & Push. Pull request pak vytváříte a reviewujete v rozhraní Git providera — Databricks poskytuje Git operace, code review žije u providera. Do chráněné main se typicky přímo commitovat nedá; jde se přes feature branch a PR.

Merge konflikty vznikají, když víc lidí změní stejné řádky. Git folders UI nabízí seznam konfliktních souborů a tři cesty: Keep all current changes, Take all incoming changes, nebo ruční editaci souboru s konfliktními markery (<<<<<<< HEAD … ======= … >>>>>>>) a Mark As Resolved. Pak Continue Merge/Continue Rebase — nebo Abort, pokud jste sáhli vedle.

Dobrá testovací strategie kopíruje testovací pyramidu: hodně rychlých unit testů dole, méně integračních uprostřed, hrstka end-to-end testů a UAT scénářů nahoře.

Unit testy testují jednotlivé funkce v izolaci. Klíčové doporučení Databricks: transformační logiku držte v .py modulech mimo notebooky a do notebooků ji importujte — testuje se pak snadno standardním pytest. Testovací soubory pojmenujte test_*.py nebo *_test.py:

import pytest
import pandas as pd
from transforms import filter_country_region

@pytest.fixture
def sample_data():
    # synteticka data se strukturou produkce - zadna citliva data
    return pd.DataFrame({
        "iso_code": ["USA", "USA", "CAN", "GBR"],
        "value": [100, 200, 150, 175],
    })

def test_filter_default(sample_data):
    result = filter_country_region(sample_data)
    assert len(result) == 2
    assert all(result.iso_code == "USA")

Fixture @pytest.fixture dodává znovupoužitelná syntetická data — testujete strukturu a logiku, ne produkční obsah. Testy spustíte i přímo v notebooku:

%pip install pytest

import pytest, sys
sys.dont_write_bytecode = True   # zadna cache na readonly filesystem

retcode = pytest.main(["tests/", "-v", "-p", "no:cacheprovider"])
assert retcode == 0, "Testy selhaly - zkontrolujte vystup vyse"

Integrační testy běží proti skutečným Databricks zdrojům — čtou testovací tabulku, spustí transformaci a ověří schéma a typy výstupu. Vytvořte pro ně dedikovaný testovací katalog/schéma s reprezentativním vzorkem dat. End-to-end testy simulují celý denní běh (setup vstupů → spuštění pipeline → asserty nad výstupní tabulkou → cleanup); pouštějte je v deployment pipeline nebo mimo špičku, ne na každý commit. UAT pak znamená: akceptační kritéria dohodnutá se stakeholdery předem, staging prostředí zrcadlící produkci a připravené scénáře (třeba notebook s rekonciliací měsíčních tržeb proti finančnímu systému).

Declarative Automation Bundles — dříve známé jako Databricks Asset Bundles (DAB); starší materiály a slidy používají původní název — jsou infrastructure-as-code přístup k nasazování Databricks zdrojů. Joby, pipeline a další resources popíšete v YAML souborech a stejnou definici pak deklarativně nasazujete do dev, stagingu i produkce. Dokumentace: „Declarative Automation Bundles (formerly known as Databricks Asset Bundles)".

Základem je soubor databricks.yml v kořeni projektu:

bundle:
  name: order-processing

include:
  - resources/*.yml      # rozdeleni konfigurace do vice souboru

variables:
  environment:
    description: Nazev prostredi
    default: development

resources:
  jobs:
    etl_pipeline:
      name: ${var.environment}-order-pipeline
      tasks:
        - task_key: extract
          notebook_task:
            notebook_path: ./notebooks/extract.py
        - task_key: transform
          depends_on:
            - task_key: extract
          notebook_task:
            notebook_path: ./notebooks/transform.py

Mapování bundle definuje identitu projektu, resources nasazované objekty (nejčastěji joby s tasky, závislostmi přes depends_on a parametry přes base_parameters), include přibalí další YAML soubory. Cesty uvádějte relativně ke kořeni bundlu. Variables s substitucí ${var.nazev} nahrazují hardcodované hodnoty — plnit je lze defaultem, per-target overridem, CLI volbou --var="klic=hodnota" nebo proměnnou prostředí s prefixem BUNDLE_VAR_.

Targets reprezentují nasazovací prostředí. Zásadní jsou režimy: mode: development prefixuje názvy resources [dev uživatel], pozastaví všechny scheduly a povolí souběžné běhy — dev nasazení si nešlape po produkci. mode: production naopak validuje shodu Git branche a doporučuje deploy přes service principal:

targets:
  dev:
    default: true
    mode: development
    variables:
      environment: development
  staging:
    presets:                       # jemne ladeni bez plneho rezimu
      name_prefix: staging_
      trigger_pause_status: PAUSED
  prod:
    mode: production
    workspace:
      host: https://adb-prod.azuredatabricks.net
    variables:
      environment: production

Nasazení řídí Databricks CLI čtyřmi kroky: validace, náhled, deploy, ověření. CLI si při deployi ukládá stav do workspace — ví, co vytvořilo, a při dalším nasazení resources aktualizuje, doplní nové a smaže ty, které z konfigurace zmizely.

# autentizace vuci workspace
databricks auth login --host https://adb-1234567890123456.7.azuredatabricks.net

databricks bundle validate            # kontrola syntaxe a konfigurace
databricks bundle plan                # nahled: co se vytvori / zmeni / smaze
databricks bundle deploy -t dev       # nasazeni do dev targetu
databricks bundle summary             # prehled nasazenych resources + URL
databricks bundle open etl_pipeline   # otevre resource v prohlizeci

# produkce v CI/CD: bez interaktivnich potvrzeni
databricks bundle deploy -t prod --auto-approve

Nejčastější zádrhely: chyby autentizace (řeší databricks auth login), lock konflikt po přerušeném nasazení (--force-lock), běžící joby z bundlu v okamžiku deploye (chování řídí --fail-on-active-runs) a varování o neznámých properties — obvykle stará verze CLI proti novějšímu schématu.

Převezmete order-processing pipeline (čištění objednávek, normalizace status kódů, výpočet totálů s daní) a dotáhnete ji k produkční zralosti: napíšete pytest unit a integrační testy k modulu transforms.py, zabalíte job do Declarative Automation Bundle s dev/prod targety a nasadíte ho přes Databricks CLI (validate → plan → deploy).

▶ Otevřít lab na GitHubu (EN) · Learn modul k tématu — s krátkými výukovými videy