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 uma visão geral do CI/CD em projetos de aprendizagem automática em Azure Databricks, veja Como é que o Databricks suporta CI/CD para aprendizagem automática?.

Fluxo de alto nível

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

1. Version: Guarda o teu código Azure Databricks e cadernos num sistema de controlo de versões 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. Code: Desenvolver código e testes unitários num Azure Databricks notebook no espaço de trabalho ou localmente usando um IDE.
   • Use o Lakeflow Pipelines Editor para desenvolver pipelines no espaço de trabalho.
   • Utiliza a extensão Databricks Visual Studio Code para desenvolver e implementar alterações locais em espaços de trabalho do Azure Databricks.
3. Build: Use as definições do Declarative Automation Bundles para construir automaticamente certos artefactos 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. Deploy: Implementar alterações no espaço de trabalho Azure Databricks usando Pacotes de Automação Declarativa com ferramentas como Azure DevOps, GitHub Actions ou Jenkins.
   • Configure implantações usando modos de implantação de pacotes.
   • Para obter detalhes sobre a utilização do Azure DevOps e do Databricks, consulte Continuous integration and delivery on Azure Databricks using Azure DevOps.
   • Para exemplos de Databricks GitHub Actions, veja GitHub Actions.
   • Para usar o Jenkins Pipeline com Databricks, veja CI/CD com Jenkins em Azure Databricks.
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. Run: Use o CLI do Databricks com os Declarative Automation Bundles para automatizar execuções nos espaços de trabalho do Azure Databricks.
   • Execute recursos de pacote usando databricks bundle run.
7. Monitor: Monitorize o desempenho do seu código e cargas de trabalho de produção em Azure Databricks usando ferramentas como jobs monitoring. 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 Automação Declarativa

Os Pacotes de Automação Declarativa são a abordagem recomendada para CI/CD em Databricks. Use Pacotes de Automação Declarativa para descrever recursos Databricks, como trabalhos e pipelines, como ficheiros fonte, 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 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 completa de CI/CD com Pacotes de Automação Declarativa, o Databricks oferece opções apenas para controlo de versões e implementação de ficheiros de código e cadernos.

• 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 junçã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.