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.

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

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

Ciclo de vida de CI/CD

Abaixo há uma visão geral de exemplo do ciclo de vida de CI/CD em um Azure Data Factory configurado com o Git do Azure Repos. Para obter mais informações sobre como configurar um repositório Git, confira Controle do código-fonte no Azure Data Factory.

1. Um data factory de desenvolvimento é criado e configurado com o Git do Azure Repos. 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. 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, confira Desenvolvimento iterativo e depuração com o 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 um alocador de teste ou UAT (teste de aceitação do usuário), ela acessará a versão do Azure Pipelines e implantará a versão desejada do alocador de desenvolvimento em UAT. Essa implantação ocorre como parte de uma tarefa do Azure Pipelines e usa parâmetros do modelo do Resource Manager 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 na CI/CD, você precisa concluir determinadas tarefas, como parar e reiniciar gatilhos e executar 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 você quiser ativar/desativar somente os gatilhos que foram modificados em vez de ativar/desativar todos os gatilhos durante a CI/CD.

  Aviso

  Use o Núcleo PowerShell 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.

• Runtimes 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 fases em sua 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 do 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 ponto de extremidade privado, contanto que ele tenha as mesmas propriedades daquele que já existe no alocador. 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 no 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 que você mantenha os mesmos nomes de segredo em todas as fases. Se você mantiver os mesmos nomes de segredo, não precisará parametrizar cada cadeia de conexão em ambientes de CI/CD porque a única coisa que é alterada é 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 do 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.

• Sinalizadores de recursos e controle da exposição. 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 design, o Data Factory não permite cherry-picking de confirmações nem a publicação seletiva de recursos. As publicações incluirão todas as alterações feitas no data factory.

  • 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 ocasiões em que você precisa de publicação seletiva, considere usar um hotfix. Para obter mais informações, confira Ambiente de produção de hotfix.

• A equipe do Azure Data Factory não recomenda atribuir controles RBAC do Azure a entidades individuais (pipelines, conjuntos de dados e 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 um data factory, considere implantar um segundo data factory.

• Não é possível publicar de branches particulares.

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

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

• Os modelos parciais do ARM no seu branch 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
• Automatizar a integração contínua usando versões do Azure Pipelines
• Promover manualmente um modelo do 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
• Script pré e pós-implantação de exemplo