Técnicas de CI/CD com pastas Git e Databricks Git (Repos)

Aprenda técnicas para usar Databricks Git pastas em CI/CD fluxo de trabalho. A configuração de Databricks Git pastas no workspace fornece controle de origem para arquivos de projeto em Git repositórios.

A figura a seguir mostra uma visão geral das técnicas e do fluxo de trabalho.

Visão geral das técnicas de CI/CD para pastas Git.

Para obter uma visão geral de CI/CD com Databricks, consulte O que é CI/CD em Databricks?.

fluxo de desenvolvimento

As pastas Git do Databricks têm pastas em nível de usuário. As pastas no nível do usuário são criadas automaticamente quando os usuários clonam um repositório remoto pela primeira vez. O senhor pode pensar nas pastas Git do Databricks nas pastas de usuário como "checkouts locais" que são individuais para cada usuário e onde os usuários fazem alterações em seu código.

Em sua pasta de usuário nas pastas Git da Databricks, clone o repositório remoto. Uma prática recomendada é criar uma nova ramificação de recurso ou selecionar uma ramificação criada anteriormente para o seu trabalho, em vez de fazer o commit diretamente e enviar as alterações para a ramificação principal. O senhor pode fazer alterações, commit, e enviar alterações para essa ramificação. Quando estiver pronto para merge seu código, o senhor pode fazer isso na interface do usuário das pastas do Git.

Requisitos

Este fluxo de trabalho requer que você já tenha configurado sua integração com o Git.

Observação

Databricks recomenda que cada desenvolvedor trabalhe em sua própria ramificação de recurso. Para obter informações sobre como resolver conflitos de mesclagem, consulte Resolver conflitos de mesclagem.

Colaborar em pastas Git

O fluxo de trabalho a seguir usa uma ramificação chamada feature-b que se baseia na ramificação principal.

Clone seu repositório Git existente para seu workspace do Databricks.
Use a UI de pastas do Git para criar uma ramificação de recurso a partir da ramificação principal. Este exemplo usa um único ramo de recurso feature-b para simplificar. O senhor pode criar e usar várias ramificações de recurso para fazer seu trabalho.
Faça suas modificações no Databricks Notebook e em outros arquivos no repositório.
Confirme e envie suas alterações para seu provedor Git.
Os colaboradores agora podem clonar o repositório Git em sua própria pasta de usuário.
1. Trabalhando em uma nova ramificação, um colega de trabalho faz alterações no Notebook e em outros arquivos na pasta Git.
2. O contribuidor confirma e envia suas alterações para o provedor Git.
Para merge alterações de outras ramificações ou fazer o rebase da ramificação recurso-b no Databricks, na UI das pastas do Git, use um dos seguintes fluxos de trabalho:
- Mesclar ramificações. Se não houver conflito, o merge é enviado para os repositórios remotos do Git usando git push.
- Rebase em outro branch.
Quando estiver pronto para fazer o merge do seu trabalho no repositório Git remoto e na ramificação main, use a UI de pastas do Git para fazer o merge das alterações do recurso-b. Se preferir, o senhor pode merge as alterações no seu provedor Git.

Produção Job fluxo de trabalho

As pastas Git da Databricks oferecem duas opções para executar seu trabalho de produção:

Opção 1: Fornecer uma referência remota do Git na definição do site Job. Por exemplo, executar um Notebook específico no ramo main de um repositório Git.
Opção 2: configurar um repositório Git de produção e chamar as APIs Repos para atualizá-lo programaticamente. execução Job contra a pasta Git do Databricks que clona esse repositório remoto. A chamada da API Repos deve ser a primeira tarefa no site Job.

Opção 1: executar o Job usando o Notebook em um repositório remoto

Simplifique o processo de definição Job e mantenha uma única fonte de verdade executando um Job do Databricks usando Notebook localizado em um repositório Git remoto. Essa referência do Git pode ser um commit, tags ou branch do Git e é fornecida por você na definição Job .

Isso ajuda a evitar alterações não intencionais em sua produção Job, como quando um usuário faz edições locais em um repositório de produção ou troca de ramificações. Ele também automatiza o passo a passo, pois o senhor não precisa criar uma pasta Git de produção separada no Databricks, gerenciar as permissões para ela e mantê-la atualizada.

Consulte Usar código-fonte controlado por versão em um Jobdo Databricks.

Opção 2: Configurar uma pasta Git de produção e automação Git

Nessa opção, o senhor configura uma pasta Git de produção e uma automação para atualizar a pasta Git no merge.

passo 1: configurar pastas de nível superior

O administrador cria pastas de nível superior para não usuários. O caso de uso mais comum para essas pastas de nível superior é criar pastas de desenvolvimento, preparação e produção que contenham pastas do Databricks Git para as versões ou ramificações apropriadas para desenvolvimento, preparação e produção. Por exemplo, se a sua empresa usa a ramificação main para produção, a pasta Git "production" deve ter a ramificação main verificada nela.

Normalmente, as permissões nessas pastas de nível superior são somente leitura para todos os usuários não administradores no site workspace. Para essas pastas de nível superior, recomendamos que o senhor forneça apenas entidades de serviço com permissões CAN EDIT e CAN gerenciar para evitar edições acidentais no seu código de produção por usuários do espaço de trabalho.

o passo 2: Configurar atualizações automatizadas para as pastas Git da Databricks com a API de pastas Git

Para manter uma pasta Git no Databricks com a versão mais recente, o senhor pode configurar a automação do Git para chamar a API Repos. Em seu provedor Git, configure a automação que, após cada merge bem-sucedido de um PR na ramificação principal, chama o endpoint da API Repos na pasta Git apropriada para atualizá-la para a versão mais recente.

Por exemplo, no GitHub isso pode ser conseguido com GitHub Actions. Para mais informações, consulte a APIrepo .

Para chamar qualquer API REST do Databricks de dentro de uma célula Notebook do Databricks, primeiro instale o SDK do Databricks com %pip install databricks-sdk --upgrade (para as APIs REST do Databricks mais recentes) e, em seguida, importe ApiClient de databricks.sdk.core.

Observação

Se %pip install databricks-sdk --upgrade retornar um erro dizendo “O pacote não foi encontrado”, então o pacote databricks-sdk não foi instalado anteriormente. Reexecução do comando sem a flag --upgrade : %pip install databricks-sdk.

O senhor também pode executar as APIs do SDK da Databricks a partir de um Notebook para recuperar a entidade de serviço do seu workspace. Aqui está um exemplo usando Python e o Databricks SDK para Python.

Você também pode usar ferramentas como curl, Postman ou Terraform. Você não pode usar a interface do usuário do Databricks.

Para saber mais sobre a entidade de serviço em Databricks, consulte gerenciar entidade de serviço. Para obter informações sobre entidade de serviço e CI/CD, consulte entidade de serviço para CI/CD. Para obter mais detalhes sobre como usar o Databricks SDK de um Notebook, leia Use o Databricks SDK para Python de um Databricks Notebook .

Integração do Terraform

O senhor também pode gerenciar as pastas Git do Databricks em uma configuração totalmente automatizada usando o Terraform e o databricks_repo:

resource "databricks_repo" "this" {
  url = "https://github.com/user/demo.git"
}

Para usar o Terraform para adicionar credenciais do Git a uma entidade de serviço, adicione a seguinte configuração:

  provider "databricks" {
    # Configuration options
  }

  provider "databricks" {
    alias = "sp"
    host = "https://....cloud.databricks.com"
    token = databricks_obo_token.this.token_value
  }

  resource "databricks_service_principal" "sp" {
    display_name = "service_principal_name_here"
  }

  resource "databricks_obo_token" "this" {
    application_id   = databricks_service_principal.sp.application_id
    comment          = "PAT on behalf of ${databricks_service_principal.sp.display_name}"
    lifetime_seconds = 3600
  }

  resource "databricks_git_credential" "sp" {
    provider = databricks.sp
    depends_on = [databricks_obo_token.this]
    git_username          = "myuser"
    git_provider          = "azureDevOpsServices"
    personal_access_token = "sometoken"
  }

Configurar um pipeline automatizado de CI/CD com pastas Git da Databricks

Aqui está uma automação simples que pode ser executada como um GitHub Actions.

Requisitos

O senhor criou uma pasta Git em um Databricks workspace que acompanha a ramificação de base que está sendo mesclada.
O senhor tem um pacote Python que cria os artefatos para serem colocados em um local DBFS. Seu código deve:
- Atualize os repositórios associados à sua ramificação preferida (como development) para que contenham as versões mais recentes do seu Notebook.
- Crie todos os artefatos e copie-os para o caminho da biblioteca.
- Substitua as últimas versões dos artefatos de compilação para evitar a necessidade de atualizar manualmente as versões dos artefatos em seu site Job.

os passos

Observação

o passo 1 deve ser realizado por um administrador dos repositórios Git.

Configure segredos para que seu código possa acessar o Databricks workspace. Adicione os seguintes segredos aos repositórios do Github:
- DEPLOYMENT_TARGET_URL: Defina-o como o URL workspace, mas não inclua a subcadeia /?o.
- DEPLOYMENT_TARGET_TOKEN: forneça um valor do Databricks Personal access token (PAT). O senhor pode gerar um PAT do Databricks seguindo as instruções em Configurar credenciais do Git e conectar um repo remoto ao Databricks.

Navegue até Actions tab de seus repositórios Git e clique no botão New workflow (Novo fluxo de trabalho ). Na parte superior da página, selecione Configurar você mesmo um fluxo de trabalho e cole este script:

O link "configure um fluxo de trabalho você mesmo" na interface do usuário do GitHub Actions

# This is a basic automation workflow to help you get started with GitHub Actions.

name: CI

  # Controls when the workflow will run
  on:
    # Triggers the workflow on push for main and dev branch
    push:
      branches:
        # Set your base branch name here
        - your-base-branch-name

  # A workflow run is made up of one or more jobs that can run sequentially or in parallel
  jobs:
    # This workflow contains a single job called "deploy"
    deploy:
      # The type of runner that the job will run on
      runs-on: ubuntu-latest
      env:
        DBFS_LIB_PATH: dbfs:/path/to/libraries/
        REPO_PATH: /Repos/path/here
        LATEST_WHEEL_NAME: latest_wheel_name.whl

      # Steps represent a sequence of tasks that will be executed as part of the job
      steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      - name: Setup Python
        uses: actions/setup-python@v2
        with:
        # Version range or exact version of a Python version to use, using SemVer's version range syntax.
          python-version: 3.8

      - name: Install mods
        run: |
          pip install databricks-cli
          pip install pytest setuptools wheel

      - name: Configure CLI
        run: |
          echo "${{ secrets.DEPLOYMENT_TARGET_URL }} ${{ secrets.DEPLOYMENT_TARGET_TOKEN }}" | databricks configure --token

      - name: Extract branch name
        shell: bash
        run: echo "##[set-output name=branch;]$(echo ${GITHUB_REF#refs/heads/})"
        id: extract_branch

      - name: Update Databricks Git folder
        run: |
          databricks repos update --path ${{env.REPO_PATH}} --branch "${{ steps.extract_branch.outputs.branch }}"

      - name: Build Wheel and send to Databricks workspace DBFS location
        run: |
          cd $GITHUB_WORKSPACE
          python setup.py bdist_wheel
          dbfs cp --overwrite ./dist/* ${{env.DBFS_LIB_PATH}}
          # there is only one wheel file; this line copies it with the original version number in file name and overwrites if that version of wheel exists; it does not affect the other files in the path
          dbfs cp --overwrite ./dist/* ${{env.DBFS_LIB_PATH}}${{env.LATEST_WHEEL_NAME}} # this line copies the wheel file and overwrites the latest version with it

Atualize os seguintes valores de variável de ambiente com os seus próprios valores:
- DBFS_LIB_PATH: O caminho no DBFS para a biblioteca (rodas) que o senhor usará nessa automação, que começa com dbfs:. Por exemplo,dbfs:/mnt/myproject/libraries.
- REPO_PATH: o caminho em seu Databricks workspace para a pasta Git onde o Notebook será atualizado. Por exemplo, /Repos/Develop.
- LATEST_WHEEL_NAME: O nome do último arquivo Python wheel compilado (.whl). Isso é usado para evitar a atualização manual das versões de roda no trabalho do Databricks. Por exemplo, your_wheel-latest-py3-none-any.whl.
Selecione commit changes... para commit o script como um fluxo de trabalho do GitHub Actions. Depois que o pull request para esse fluxo de trabalho for mesclado, acesse Actions tab dos repositórios do Git e confirme se as ações foram bem-sucedidas.