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

APLICA-SE A: Azure Data Factory Azure Synapse Analytics

Gorjeta

Data Factory em Microsoft Fabric é a próxima geração de Azure Data Factory, com uma arquitetura mais simples, IA incorporada e novas funcionalidades. Se és novo na integração de dados, começa pelo Fabric Data Factory. As cargas de trabalho existentes do ADF podem atualizar para o Fabric para aceder a novas capacidades em ciência de dados, análise em tempo real e relatórios.

A integração contínua é a prática de testar cada alteração feita na sua base de código automaticamente e o mais cedo possível. A entrega contínua segue os testes que ocorrem durante a integração contínua e transfere as alterações para um sistema intermédio ou de produção.

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

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

Nota

Recomendamos que utilize o módulo PowerShell do Azure Az para interagir com o Azure. Para começar, consulte Install Azure PowerShell. Para saber como migrar para o módulo Az PowerShell, veja Migrar Azure PowerShell do AzureRM para o Az.

Ciclo de vida do CI/CD

Nota

Para obter mais informações, consulte Melhorias contínuas na implantação.

A seguinte visão geral mostra o ciclo de vida do CI/CD numa fábrica de dados do Azure configurada com o Repositórios do Azure Git. Para mais informações sobre como configurar um repositório Git, consulte Controlo de versões em Azure Data Factory.

  1. Uma fábrica de dados de desenvolvimento é criada e configurada com o Repositórios do Azure Git. Todos os desenvolvedores devem ter permissão para criar recursos do Data Factory, como pipelines e conjuntos de dados.

  2. Um desenvolvedor cria uma ramificação de recurso para fazer uma alteração. Os commits assinados não são suportados na data factory. Eles analisam/debugam as suas corridas de pipeline com as alterações mais recentes. Para mais informações sobre como depurar uma execução de pipeline, veja Iterative development and debugging with Azure Data Factory.

  3. Depois de um desenvolvedor estar satisfeito com as suas alterações, ele cria um pull request a partir da sua branch de funcionalidades para a branch principal ou de colaboração, para que as suas alterações sejam revisadas pelos colegas.

  4. Depois de um pull request ser aprovado e as alterações serem integradas na ramificação principal, as alterações são publicadas na fábrica de desenvolvimento.

  5. Quando a equipa está pronta para implementar as alterações numa fábrica de testes ou UAT (User Acceptance Testing), recorre à sua versão do Azure Pipelines e implementa a versão desejada da fábrica de desenvolvimento no UAT. Esta implementação ocorre como parte de uma tarefa do Azure Pipelines e utiliza parâmetros do template do Resource Manager para aplicar a configuração apropriada.

  6. Depois que as alterações tiverem sido verificadas na fábrica de teste, faça a implantação na fábrica de produção usando a próxima tarefa da versão de pipelines.

Nota

Apenas a fábrica de desenvolvimento está associada a um repositório git. As fábricas de teste e produção não devem ter um repositório git associado a elas e só devem ser atualizadas através de um pipeline Azure DevOps ou através de um template de Gestão de Recursos.

A imagem seguinte destaca as diferentes etapas deste ciclo de vida.

Diagrama da integração contínua com o Azure Pipelines.

Melhores práticas para CI/CD

Se você estiver usando a integração do Git com sua fábrica de dados e tiver um pipeline de CI/CD que mova suas alterações do desenvolvimento para o teste e, em seguida, para a produção, recomendamos estas práticas recomendadas:

  • Integração com Git. Configure apenas a sua fábrica de dados de desenvolvimento com integração ao Git. As alterações no teste e na produção são implantadas via CI/CD e não precisam de integração com o Git.

  • Script de pré e pós-implantação. Antes da etapa de implementação do Resource Manager no CI/CD, precisa de completar certas tarefas, como parar e reiniciar gatilhos e realizar limpezas. Recomendamos que você use scripts do PowerShell antes e depois da tarefa de implantação. Para obter mais informações, consulte Atualizar gatilhos ativos. A equipe da fábrica de dados forneceu um script para usar localizado na parte inferior desta página.

    Nota

    Utilize o PrePostDeploymentScript.Ver2.ps1 no caso de querer desligar ou ligar apenas os gatilhos modificados, em vez de desligar ou ligar todos os gatilhos durante o CI/CD.

    Aviso

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

    Aviso

    Se não usares as versões mais recentes do PowerShell e do módulo Data Factory, podes ter erros de desserialização ao executar os comandos.

  • Tempo de execução e compartilhamento de integração. Os tempos de execução de integração não mudam com frequência e são semelhantes em todos os estágios do seu CI/CD. O Data Factory espera que tenhas o mesmo nome, tipo e subtipo de runtime de integração em todas as fases do CI/CD. Se você quiser compartilhar tempos de execução de integração em todos os estágios, considere usar uma fábrica ternária apenas para conter os tempos de execução de integração compartilhados. Pode utilizar esta fábrica partilhada em todos os seus ambientes como um tipo de runtime de integração associada.

    Nota

    O compartilhamento de tempo de execução de integração só está disponível para tempos de execução de integração auto-hospedados. Os runtimes de integração Azure-SSIS não suportam partilha.

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

  • Key Vault. Quando usar serviços ligados cuja informação de ligação está armazenada no Azure Key Vault, mantenha cofres de chave separados para diferentes ambientes. 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 segredos de produção. Se seguires esta abordagem, mantém os mesmos nomes secretos em todas as fases. Se mantiveres os mesmos nomes secretos, não precisas de parametrizar cada cadeia de ligação em ambientes CI/CD porque a única coisa que muda é o nome do cofre de chaves, que é um parâmetro separado.

  • Nomenclatura de recursos. Devido a restrições de templates ARM, podem surgir problemas na implementação se os seus recursos contiverem espaços no nome. A equipa do Azure Data Factory recomenda usar caracteres '_' ou '-' em vez de espaços para recursos. Por exemplo, 'Pipeline_1' é um nome preferível em relação a 'Pipeline 1'.

  • Alteração do repositório. O Azure Data Factory (ADF) gere automaticamente o conteúdo do repositório Git. Alterar ou adicionar manualmente ficheiros ou pastas não relacionados em qualquer parte da pasta de dados do repositório Git do ADF pode causar erros de carregamento de recursos. Por exemplo, a presença de ficheiros .bak pode causar erro ADF CI/CD, por isso remove-os para o ADF carregar.

  • Controle de exposição e sinalizadores de recursos. Ao trabalhar em equipa, há situações em que podes fundir alterações, mas não queres que corram em ambientes elevados como produção (PROD) e garantia de qualidade (QA). Para lidar com esse cenário, a equipe do ADF recomenda o conceito de DevOps de usar sinalizadores de recursos. No ADF, você pode combinar parâmetros globais e a atividade de condição if para ocultar conjuntos de lógica com base nesses sinalizadores de ambiente.

    Para aprender a configurar uma feature flag, veja o seguinte tutorial em vídeo:

Funcionalidades não suportadas

  • Por design, o Data Factory não suporta a seleção seletiva de commits nem a publicação seletiva de recursos. A publicação inclui 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 ocasiões em que seja necessário fazer uma publicação seletiva, considere usar um hotfix. Para obter mais informações, consulte Ambiente de produção de hotfix.

  • A equipa do Azure Data Factory não recomenda atribuir controlos Azure RBAC a entidades individuais (por exemplo, pipelines e conjuntos de dados) numa data factory. Por exemplo, se um programador tiver acesso a um pipeline ou um conjunto de dados, deverá conseguir aceder a todos os pipelines ou conjuntos de dados na fábrica de dados. Se achar que precisa de implementar muitas funções do Azure numa fábrica de dados, considere implementar uma segunda fábrica de dados.

  • Não pode publicar a partir de ramificações privadas.

  • Atualmente, não é possível hospedar projetos no Bitbucket.

  • Atualmente, não pode exportar e importar alertas e métricas como parâmetros.

  • Os modelos ARM parciais no seu ramo de publicação não são mais suportados a partir de 1 de novembro de 2021. Se o seu projeto utilizou esta funcionalidade, mude para um mecanismo suportado para implementações usando ARMTemplateForFactory.json arquivos de our linkedTemplates .

    Diagrama da pasta 'PartialArmTemplates'.

Conteúdos relacionados

  • Last updated on