Integração e entrega contínuas no Azure Data Factory

APLICA-SE A: Azure Data Factory Azure Synapse Analytics

Integração contínua é a prática de testar cada alteração feita em sua base de código automaticamente e o mais cedo possível. A entrega contínua segue o teste que acontece durante a integração contínua e envia as alterações para um sistema de preparo ou produção.

Em Azure Data Factory, CI/CD (integração e entrega contínua) significa mover pipelines do Data Factory de um ambiente (desenvolvimento, teste, produção) para outro. Azure Data Factory utiliza modelos Azure Resource Manager para armazenar a configuração de várias entidades do ADF (pipelines, conjuntos de dados, fluxos de dados e assim por diante). Há dois métodos sugeridos para promover uma fábrica de dados para outro ambiente:

• Implantação automatizada usando a integração do Data Factory com Azure Pipelines
• Carregue manualmente um modelo de Resource Manager usando a integração do Data Factory UX com Azure Resource Manager.

Ciclo de vida de CI/CD

Veja abaixo um exemplo de visão geral do ciclo de vida de CI/CD em um Azure Data Factory configurado com Azure Repos Git. Para obter mais informações sobre como configurar um repositório Git, consulte Source control in Azure Data Factory.

1. Um data factory de desenvolvimento é criado e configurado com Azure Repos Git. Todos os desenvolvedores devem ter permissão para criar recursos do Data Factory como pipelines e conjuntos de dados.

2. Um desenvolvedor cria um branch de recurso para fazer uma alteração. Não há suporte para confirmações assinadas no Data Factory. Ele depura as execuções do pipeline com as alterações mais recentes. Para obter mais informações sobre como depurar uma execução de pipeline, consulte Desenvolvimento iterativo e depuração com Azure Data Factory.

3. Depois que um desenvolvedor estiver satisfeito com as alterações, poderá criar uma solicitação de pull do branch de recurso para o branch principal ou de colaboração para que as alterações sejam examinadas por pares.

4. Depois que uma solicitação de pull for aprovada e as alterações forem mescladas no branch principal, as alterações serão publicadas no alocador de desenvolvimento.

5. Quando a equipe estiver pronta para implantar as alterações em uma fábrica de teste ou UAT (Teste de Aceitação do Usuário), a equipe acessará sua versão Azure Pipelines e implantará a versão desejada da fábrica de desenvolvimento no UAT. Essa implantação ocorre como parte de uma tarefa Azure Pipelines e usa Resource Manager parâmetros de modelo para aplicar a configuração apropriada.

6. Depois que as alterações tiverem sido verificadas no alocador de testes, implante no alocador de produção usando a próxima tarefa da versão de pipelines.

A imagem abaixo realça as diferentes etapas desse ciclo de vida.

Práticas recomendadas para CI/CD

Se você está usando a integração do Git ao seu data factory e tem um pipeline de CI/CD que migra suas alterações do desenvolvimento para o teste e para a produção, recomendamos estas melhores práticas:

• Integração do Git. Configure somente seu data factory de desenvolvimento com a integração do Git. Alterações no teste e na produção são implantadas por CI/CD e não precisam da integração do Git.

• Script pré e pós-implantação. Antes da etapa de implantação do Resource Manager em CI/CD, você precisa concluir determinadas tarefas, como parar e reiniciar gatilhos e realizar a limpeza. Recomendamos que você use scripts do PowerShell antes e depois da tarefa de implantação. Para obter mais informações, confira Atualizar gatilhos ativos. A equipe de data factory forneceu um script para uso localizado na parte inferior desta página.

  Observação

  Use o PrePostDeploymentScript.Ver2.ps1 se quiser desativar/ativar apenas os gatilhos que foram modificados em vez de desativar/ativar todos os gatilhos durante a CI/CD.

  Aviso

  Certifique-se de usar o PowerShell Core na tarefa ADO para executar o script.

  Aviso

  Se você não usar as versões mais recentes do PowerShell e o módulo do Data Factory, poderá encontrar erros de desserialização ao executar os comandos.

• Ambientes de execução de integração e compartilhamento. Os runtimes de integração não são alterados com frequência e são semelhantes em todas as etapas do seu CI/CD. Portanto, o Data Factory espera que você tenha o mesmo nome, tipo e subtipo de runtime de integração em todas as fases da CI/CD. Se desejar compartilhar runtimes de integração em todas as fases, considere usar um alocador ternário apenas para conter os runtimes de integração compartilhados. Você pode usar esse alocador compartilhado em todos os seus ambientes como um tipo de runtime de integração vinculado.

  Observação

  O compartilhamento de runtime de integração só está disponível para runtimes de integração auto-hospedadas. Os runtimes de integração do Azure-SSIS não dão suporte ao compartilhamento.

• Implantação de ponto de extremidade privado gerenciado. Se um ponto de extremidade privado já existir em uma fábrica e você tentar implantar um modelo do ARM que contenha um ponto de extremidade privado com o mesmo nome, mas com propriedades modificadas, a implantação falhará. Em outras palavras, você pode implantar com êxito um endpoint privado, desde que ele tenha as mesmas propriedades daquele que já existe na fábrica. Se alguma propriedade for diferente entre os ambientes, você poderá substituí-la parametrizando essa propriedade e fornecendo o respectivo valor durante a implantação.

• Key Vault. Quando você usa serviços vinculados cujas informações de conexão são armazenadas em Azure Key Vault, é recomendável manter cofres de chaves separados para ambientes diferentes. Você também pode configurar níveis de permissão separados para cada cofre de chaves. Por exemplo, talvez você não queira que os membros da sua equipe tenham permissões para os segredos de produção. Se você seguir essa abordagem, recomendamos manter os mesmos nomes secretos em todas as fases. Se você mantiver os mesmos nomes secretos, não precisará parametrizar cada cadeia de conexão entre ambientes de CI/CD porque a única coisa que muda é o nome do cofre de chaves, que é um parâmetro separado.

• Nomenclatura de recursos. Devido às restrições de modelo do ARM, poderão surgir problemas na implantação se os recursos contiverem espaços no nome. A equipe de Azure Data Factory recomenda usar caracteres '_' ou '-' em vez de espaços para recursos. Por exemplo, 'Pipeline_1' seria um nome preferível a 'pipeline 1'.

• Alterando o repositório. O ADF gerencia o conteúdo do repositório GIT automaticamente. Alterar ou adicionar manualmente arquivos ou pastas não relacionados em qualquer lugar na pasta de dados do repositório Git do ADF pode causar erros de carregamento de recursos. Por exemplo, a presença de arquivos .bak pode causar erros de CD/CI do ADF, portanto, eles devem ser removidos para que o ADF seja carregado.

• Controle de exposição e sinalizadores de recursos. Ao trabalhar em uma equipe, há instâncias em que você pode mesclar alterações, mas não querer que elas sejam executadas em ambientes elevados, como PROD e QA. Para lidar com esse cenário, a equipe do ADF recomenda o conceito de DevOps de uso de sinalizadores de recursos. No ADF, você pode combinar parâmetros globais e a atividade If Condition para ocultar conjuntos de lógica com base nesses sinalizadores de ambiente.

  Para saber como configurar um sinalizador de recurso, consulte o tutorial de vídeo abaixo:

Recursos sem suporte

• Por padrão, o Data Factory não permite a seleção específica de envios de código nem a publicação seletiva de recursos. As publicações incluirão todas as alterações feitas na fábrica de dados.

  • As entidades do data factory dependem umas das outras. Por exemplo, os gatilhos dependem de pipelines e os pipelines dependem de conjuntos de dados e de outros pipelines. A publicação seletiva de um subconjunto de recursos pode levar a comportamentos e erros inesperados.
  • Em raras situações onde você precisa de publicação seletiva, considere a possibilidade de usar um hotfix. Para obter mais informações, confira Ambiente de produção de hotfix.

• A equipe de Azure Data Factory não recomenda atribuir controles RBAC Azure a entidades individuais (pipelines, conjuntos de dados etc.) em um data factory. Por exemplo, se um desenvolvedor tiver acesso a um pipeline ou a um conjunto de dados, ele deverá conseguir acessar todos os pipelines ou conjuntos de dados no data factory. Se você achar que precisa implementar muitas funções do Azure em uma fábrica de dados, considere implantar uma segunda fábrica de dados.

• Você não pode publicar a partir de ramificações privadas.

• No momento, você não pode hospedar projetos no Bitbucket.

• Atualmente, não é possível exportar e importar alertas e matrizes como parâmetros.

• Modelos parciais do ARM na sua ramificação de publicação não têm mais suporte desde 1º de novembro de 2021. Se o seu projeto utilizou esse recurso, alterne para um mecanismo com suporte para implantações, usando: arquivos ARMTemplateForFactory.json ou linkedTemplates.

  

Conteúdo relacionado

• Melhorias de implantação contínua
• Automatize a integração contínua usando os lançamentos do Azure Pipelines
• Promova manualmente um modelo Resource Manager para cada ambiente
• Usar parâmetros personalizados com um modelo do Resource Manager
• modelos vinculados do Resource Manager
• Como usar um ambiente de produção de hotfix
• Exemplo de script de pré-implantação e pós-implantação