CI/CD no Azure Databricks

Integração contínua e entrega contínua (CI/CD) refere-se ao processo de desenvolvimento e entrega de software em ciclos curtos e frequentes através do uso de pipelines de automação. CI/CD é comum no desenvolvimento de software, e está se tornando cada vez mais necessário em engenharia de dados e ciência de dados. Ao automatizar a construção, testes e implementação do código, as equipas de desenvolvimento entregam versões de forma mais fiável do que com processos manuais.

O Databricks fornece ferramentas para desenvolver pipelines CI/CD que suportam abordagens que podem diferir ligeiramente de organização para organização devido a aspetos únicos 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 Práticas recomendadas e fluxos de trabalho de CI/CD recomendados no Databricks.

Para obter uma visão geral de CI/CD para projetos de aprendizado de máquina no Azure Databricks, consulte Como o Databricks dá suporte a CI/CD para aprendizado de máquina?.

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 blocos de anotações 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.
   • Os usuários individuais usam uma pasta Git para criar e testar alterações antes de confirmá-las em um repositório Git. Veja CI/CD com pastas do Databricks Git.
   • Opcionalmente, configure as configurações do pacote Git.
2. Código: desenvolva código e testes de unidade em um bloco de anotações do Azure Databricks no espaço de trabalho ou localmente usando um IDE.
   • Use o Lakeflow Pipelines Editor para desenvolver pipelines no espaço de trabalho.
   • Use a extensão Databricks Visual Studio Code para desenvolver e implantar alterações locais nos espaços de trabalho do Azure Databricks.
3. Construir: Use as configurações do Databricks Asset Bundles para criar automaticamente determinados artefatos durante as implementações.
   • Configure o mapeamento de artefatos de configuração do pacote.
   • Pylint estendido com o plugin pylint da Databricks Labs ajuda a impor padrões de programação e a detetar bugs nos notebooks e no código da aplicação Databricks.
4. Implantar: implante alterações no espaço de trabalho do Azure Databricks usando o Databricks Asset Bundles com ferramentas como Azure DevOps, GitHub Actions ou Jenkins.
   • Configure implantações usando modos de implantação de pacotes.
   • Para obter detalhes sobre como usar o Azure DevOps e Databricks, consulte Integração e entrega contínuas no Azure Databricks usando o Azure DevOps.
   • Para exemplos de ações do GitHub do Databricks, consulte Ações do GitHub.
5. Teste: desenvolva e execute testes automatizados para validar suas alterações de código.
   • Use ferramentas como pytest para testar suas integrações.
6. Executar: utilize a CLI do Databricks com Databricks Asset Bundles para automatizar execuções nos seus espaços de trabalho do Azure Databricks.
   • Execute recursos de pacote usando databricks bundle run.
7. Monitor: monitore o desempenho de seu código e cargas de trabalho de produção no Azure Databricks usando ferramentas como monitoramento de trabalhos. Isso ajuda a identificar e resolver quaisquer problemas que surjam em seu ambiente de produção.

Ferramentas disponíveis

As seguintes ferramentas suportam os princípios fundamentais de CI/CD: versão de todos os arquivos e unificação do gerenciamento de ativos, definição de infraestrutura como código, isolamento de ambientes, automatização de testes e monitoramento e automação de reversões.

Pacotes de ativos Databricks

Databricks Asset Bundles são a abordagem recomendada para CI/CD em Databricks. Use Databricks Asset Bundles para descrever recursos do Databricks, como trabalhos e pipelines, como arquivos de origem, e agrupe-os junto com outros ativos para fornecer uma definição completa de um projeto implantável. Esses pacotes de arquivos podem ser controlados pelo código-fonte e você pode usar automação de CI/CD externa, como Ações do Github, para disparar implantações.

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

Para obter recomendações sobre como usar pacotes em CI/CD, consulte Práticas recomendadas e 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 Databricks Asset Bundles, o Databricks oferece opções para controlar apenas o código-fonte e implantar arquivos de código e notebooks.

• Pasta git: Pastas Git podem ser usadas para refletir o estado de um repositório Git remoto. Você pode criar uma pasta git para produção para gerenciar arquivos e blocos de anotações de origem controlados pelo código-fonte. Depois puxa manualmente a pasta Git para o estado mais recente, ou usa ferramentas externas de CI/CD como o GitHub Actions para puxar a pasta Git na fusão. Use esta abordagem quando 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 blocos de anotações e rascunhos do painel, estão no controle do código-fonte. As configurações para trabalhos ou pipelines que executam recursos na pasta Git e para a publicação de painéis não estão sob controlo de código-fonte.

• Git com tarefas: Git com tarefas permite configurar alguns tipos de tarefas para usar um repositório Git remoto como fonte de ficheiros de código. Quando uma execução de trabalho começa, o Databricks tira um snapshot do repositório e executa todas as tarefas com essa versão. Esta abordagem suporta apenas tarefas limitadas de trabalho, e apenas ficheiros de código (cadernos e outros ficheiros) são controlados por código-fonte. Configurações de trabalho, como sequências de tarefas, definições de computação e agendamentos, não são controladas pelo código-fonte, tornando esta abordagem menos adequada para implementações multiambiente e entre áreas de trabalho.