CI/CD no Azure Databricks

A CI/CD (integração contínua e entrega contínua) refere-se ao processo de desenvolvimento e entrega de software em ciclos curtos e frequentes por meio do uso de pipelines de automação. CI/CD é comum no desenvolvimento de software e está se tornando cada vez mais necessário na engenharia de dados e na ciência de dados. Ao automatizar a criação, o teste e a implantação do código, as equipes de desenvolvimento fornecem versões de forma mais confiável do que com processos manuais.

O Databricks fornece ferramentas para o desenvolvimento de pipelines de CI/CD que dão suporte a abordagens que podem diferir ligeiramente de organização para organização devido a aspectos exclusivos do ciclo de vida de desenvolvimento de software de cada organização. Esta página fornece informações sobre as ferramentas disponíveis para pipelines de CI/CD no Databricks. Para obter detalhes sobre recomendações de CI/CD e práticas recomendadas, consulte as práticas recomendadas e os fluxos de trabalho de CI/CD recomendados no Databricks.

Para obter uma visão geral de CI/CD para projetos de machine learning no Azure Databricks, veja como o Databricks dá suporte a CI/CD para machine learning?.

Fluxo de alto nível

Um fluxo comum para um pipeline de CI/CD do Azure Databricks é:

1. Versão: armazene seu código e notebooks do Azure Databricks em um sistema de controle de versão como o Git. Isso permite que você acompanhe as alterações ao longo do tempo e colabore com outros membros da equipe.
   • Usuários individuais usam uma pasta Git para criar e testar alterações antes de emiti-las em um repositório Git. Consulte CI/CD com pastas Git do Databricks.
   • Opcionalmente, defina as configurações do Git do pacote.
2. Código: desenvolva código e testes de unidade em um notebook do Azure Databricks no workspace ou localmente usando uma IDE.
   • Utilize o Editor do Lakeflow Pipelines para desenvolver pipelines no workspace.
   • Use a extensão do Visual Studio Code para Databricks para desenvolver e implantar alterações locais nos workspaces do Azure Databricks.
3. Build: use as configurações de Pacotes de Ativos do Databricks para compilar automaticamente determinados artefatos durante as implantações.
   • Configure o mapeamento da configuração do pacote para artefatos.
   • O Pylint estendido com o plugin Pylint do Databricks Labs ajuda a impor padrões de codificação e detectar bugs nos Databricks Notebooks e no código do aplicativo.
4. Implantar: implantar alterações no workspace do Azure Databricks usando pacotes de ativos do Databricks com ferramentas como Azure DevOps, GitHub Actions ou Jenkins.
   • Configure implantações usando modos de implantação do pacote.
   • Para obter detalhes sobre como usar o Azure DevOps e o Databricks, consulte Integração e entrega contínuas no Azure Databricks usando o Azure DevOps.
   • Para obter exemplos do GitHub Actions do Databricks, consulte GitHub Actions.
5. Teste: desenvolva e execute testes automatizados para validar as alterações de código.
   • Use ferramentas como o pytest para testar suas integrações.
6. Executar: Use a CLI do Databricks com bundles de ativos do Databricks para automatizar execuções em seus workspaces do Azure Databricks.
   • Execute recursos de pacote usando databricks bundle run.
7. Monitoramento: Monitore o desempenho de seu código e as cargas de trabalho de produção no Azure Databricks usando ferramentas como o monitoramento de tarefas. Isso ajuda a identificar e resolver todos os problemas que surgem em seu ambiente de produção.

Ferramentas disponíveis

As ferramentas a seguir dão suporte aos princípios fundamentais de CI/CD: versionar todos os arquivos e unificar o gerenciamento de recursos, definir a infraestrutura como código, isolar ambientes, automatizar testes e monitorar e automatizar reversões.

Pacotes de ativos do Databricks

Os Pacotes de Ativos do Databricks são a abordagem recomendada para CI/CD no Databricks. Use pacotes de ativos do Databricks para descrever recursos do Databricks, como trabalhos e pipelines como arquivos de origem, e agrupe-os com outros ativos para fornecer uma definição de ponta a ponta de um projeto implantável. Esses pacotes de arquivos podem ser controlados pela origem e você pode usar a automação de CI/CD externa, como o Github Actions, para disparar implantações.

Os pacotes incluem muitos recursos, como modelos personalizados para impor consistência e práticas recomendadas em sua organização e suporte abrangente para implantar os arquivos de código e a configuração para muitos recursos do Databricks. Criar um pacote requer algum conhecimento da sintaxe de configuração do pacote.

Para obter recomendações sobre como usar pacotes em CI/CD, consulte as práticas recomendadas e os fluxos de trabalho de CI/CD recomendados no Databricks.

Outras ferramentas para controle do código-fonte

Como alternativa à aplicação de CI/CD completo com pacotes de ativos do Databricks, o Databricks oferece opções apenas para controlar o código-fonte e implantar arquivos de código e notebooks.

• Pasta git: as pastas Git podem ser usadas para refletir o estado de um repositório Git remoto. Você pode criar uma pasta git para gerenciar arquivos de origem e notebooks com controle de versão no ambiente de produção. Em seguida, efetue pull manual da pasta Git para o estado mais recente ou use ferramentas de CI/CD externas, como o GitHub Actions, para efetuar pull da pasta Git na mesclagem. Use essa abordagem quando você não tiver acesso a pipelines externos de CI/CD.

  Essa abordagem funciona para orquestradores externos, como o Airflow, mas observe que apenas os arquivos de código, como notebooks e rascunhos de painel, estão no controle do código-fonte. As configurações para trabalhos ou pipelines que executam ativos na pasta Git e configurações para painéis de publicação não estão no controle do código-fonte.

• Git com trabalhos: o Git com trabalhos permite que você configure alguns tipos de trabalho para usar um repositório Git remoto como a fonte para arquivos de código. Quando a execução de um trabalho começa, o Databricks cria um instantâneo do repositório e executa todas as tarefas contra essa versão. Essa abordagem só dá suporte a tarefas de trabalho limitadas e somente arquivos de código (notebooks e outros arquivos) são controlados pela origem. As configurações de trabalho, como sequências de tarefas, configurações de computação e agendamentos, não são controladas pela origem, tornando essa abordagem menos adequada para implantações de vários ambientes e entre workspaces.