CI/CD na Databricks

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

Há ferramentas comuns disponíveis para o desenvolvimento do pipeline CI/CD, mas as implementações e abordagens de organização para organização podem ser ligeiramente diferentes devido aos aspectos exclusivos do ciclo de vida de desenvolvimento software de cada organização. Esta página fornece informações sobre as seguintes abordagens para CI/CD em Databricks, e os prós e contras de cada abordagem:

• Use Databricks ativo Bundles (recomendado)
• Configurar uma pasta Git de produção
• Use Git com Job

Para obter uma visão geral da CI/CD para projetos de aprendizado de máquina na Databricks, consulte Como a Databricks oferece suporte à CI/CD para aprendizado de máquina?

Databricks ativo Bundles (Recomendado)

Databricks Os pacotes ativos são a abordagem recomendada para CI/CD em Databricks. Use Databricks ativo Bundles para descrever Databricks recurso, como Job e pipeline, 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 ter o código-fonte controlado e o senhor pode usar a automação externa do CI/CD, como o GitHub Actions, para acionar as implementações.

Prós	Contras
Inclui muitos recursos, como padrão de pacote personalizado, para reforçar a consistência e as práticas recomendadas em toda a organização. Suporte abrangente para implantar os arquivos de código e a configuração de vários Databricks recurso.	É necessário algum conhecimento da sintaxe de configuração do pacote para criar um pacote. Não há garantia de que a pasta de implantação do pacote corresponda a um commit remoto do Git. A pasta do pacote de produção pode ser editada acidentalmente no site workspace. Requer um pipeline externo CI/CD, como GitHub Actions, para acionar uma implantação em merge.

Pasta Git de produção

Se o senhor ainda não estiver pronto para adotar o Databricks ativo Bundles, mas quiser que seu código tenha controle de origem, poderá configurar uma pasta de produção Git. Em seguida, use ferramentas CI/CD externas, como GitHub Actions, para extrair a pasta Git em merge ou, quando o senhor não tiver acesso ao pipeline CI/CD externo, crie um trabalho agendado para extrair para uma pasta Git no workspace.

Prós	Contras
Oferece suporte à implementação leve e simples para equipes que não adotaram o Databricks ativo Bundles. Oferece suporte a CI/CD para espaços de trabalho que usam orquestradores externos, como Airflow.	A pasta Git de produção pode ser editada acidentalmente. Somente os arquivos de código, como o Notebook e os rascunhos do painel, estão no controle de origem. As configurações do Job that exec ativo na pasta Git e as configurações para publicação de painéis não estão no controle de origem. Requer um pipeline externo CI/CD, como GitHub Actions, para acionar implantações em merge.

Git com o trabalho

Se o senhor precisar apenas do CI/CD para o Job, o Git with Job permite configurar alguns tipos de Job para usar um repositório Git remoto como fonte. Quando uma execução de trabalho começa, o site Databricks obtém um instantâneo commit do repositório remoto e garante que toda a execução do trabalho seja feita com a mesma versão do código.

Prós

Contras

Leve e pode ser criado inteiramente na interface do usuário. Não requer um pipeline CI/CD externo, como GitHub Actions, para executar o código mais recente. Garante que o trabalho de produção execute código remoto sem edições locais, evitando alterações não intencionais no trabalho de produção.

Suporta apenas tarefas de trabalho limitadas. Somente os arquivos de código, como o Notebook e outros arquivos, estão no controle de origem. Job configurações como sequências de tarefas, compute e programar não são controladas pela fonte, o que torna essa abordagem menos adequada para implantações em vários ambientes e entreworkspace. Requer uma conexão Git em tempo de execução. Um trabalho falhará se a conexão Git for interrompida.

Outras recomendações de CI/CD

Independentemente da abordagem CI/CD que o senhor escolher, use entidade de serviço para CI/CD. Consulte entidade de serviço para CI/CD.

Databricks também recomenda que o senhor use o provedorDatabricks Terraform para gerenciar seu espaço de trabalho Databricks e a infraestrutura de nuvem associada.

Links relacionados

Para obter mais informações sobre o gerenciamento do ciclo de vida do Databricks ativo e dos dados, consulte a documentação a seguir sobre as ferramentas CI/CD e pipeline de dados.

Área	Use essas ferramentas quando quiser...
Databricks Asset Bundles	Definir, implantar e executar programaticamente Databricks Job, DLT pipeline e MLOps Stacks usando CI/CD práticas recomendadas e fluxo de trabalho.
Provedor Databricks Terraform	provisionamento e gerenciar Databricks espaço de trabalho e infraestrutura usando Terraform.
CI/CD fluxo de trabalho com as pastas Git e Databricks Git	Use as pastas GitHub e Databricks Git para controle de origem e CI/CD fluxo de trabalho.
GitHub Actions	Inclua um GitHub Actions desenvolvido para Databricks em seu CI/CD fluxo de trabalho.
CI/CD com Jenkins na Databricks	Desenvolva um pipeline de CI/CD para a Databricks que use o Jenkins.
Orquestrar o trabalho Databricks com Apache Airflow	gerenciar e programar a pipeline de dados que usa Apache Airflow.
Entidades de serviço para CI/CD	Use entidade de serviço, em vez de usuários, com os sistemas CI/CD.