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

APLICA-SE A: Azure Data Factory Azure Synapse Analytics

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. Azure Data Factory utiliza modelos Azure Resource Manager para armazenar a configuração das suas várias entidades ADF (pipelines, conjuntos de dados, fluxos de dados, etc.). Há dois métodos sugeridos para promover uma fábrica de dados para outro ambiente:

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

Ciclo de vida do CI/CD

Abaixo está uma visão geral de exemplo do 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. Confirmações assinadas não são suportadas no 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.

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

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 você não usar as versões mais recentes do PowerShell e do módulo Data Factory, poderá encontrar 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. Portanto, o Data Factory espera que se mantenha o mesmo nome, tipo e subtipo de runtime de integração em todos os estágios de 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 utiliza serviços ligados cuja informação de ligação está armazenada no Azure Key Vault, recomenda-se manter cofres de chaves 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 você seguir essa abordagem, recomendamos que mantenha os mesmos nomes secretos em todos os estágios. 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 modelo ARM, problemas na implantação podem surgir se 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» seria um nome preferível a «Pipeline 1».

• Alteração do 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 erro de CI/CD do ADF, devendo ser removidos para que o ADF possa carregar corretamente.

• Controle de exposição e sinalizadores de recursos. Ao trabalhar em equipe, há instâncias em que você pode mesclar alterações, mas não quer 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 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 saber como configurar um sinalizador de recurso, consulte o tutorial em vídeo abaixo:

Funcionalidades não suportadas

• Por design, o Data Factory não permite a seleção seletiva de confirmações ou 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 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 (pipelines, conjuntos de dados, etc.) 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 Azure numa data factory, considere criar uma segunda data factory.

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

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

• Atualmente, não é possível exportar e importar alertas e matrizes 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 esse recurso, alterne para um mecanismo suportado para implantações, usando: ARMTemplateForFactory.json ou linkedTemplates arquivos.

  

Conteúdos relacionados

• Melhorias contínuas na implantação
• Automatizar a integração contínua usando lançamentos do Azure Pipelines
• Promover manualmente um modelo de Resource Manager para cada ambiente
• Usa parâmetros personalizados com um modelo de Resource Manager
• Templates de Gerenciador de Recursos vinculados
• Usando um hotfix em ambiente de produção
• Exemplo de script pré e pós-implantação