Integração e implementação contínuas

  • 8 minutos

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 emite as alterações para um sistema de teste ou de produção.

No Azure Data Factory, a integração contínua e entrega contínua (CI/CD) 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 Azure Data Factory (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 o 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 de integração contínua/entrega contínua

Abaixo está um exemplo de visão geral do ciclo de vida de CI/CD em uma fábrica de dados do Azure configurada com o Azure Repos Git.

  1. Uma fábrica de dados de desenvolvimento é criada e configurada com o 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 uma ramificação de recurso para fazer uma alteração. Eles depuram suas execuções de pipeline com suas alterações mais recentes.

  3. Depois que um desenvolvedor está satisfeito com suas alterações, ele cria uma solicitação pull de sua ramificação de recurso para a ramificação mestre ou de colaboração para que suas alterações sejam revisadas por pares.

  4. Depois que uma solicitação pull é aprovada e as alterações são mescladas na ramificação principal, as alterações são publicadas na fábrica 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 vai para a versão do Azure Pipelines e implanta a versão desejada da fábrica de desenvolvimento no UAT. Essa implantação ocorre como parte de uma tarefa do Azure Pipelines e usa parâmetros de modelo do Gerenciador de Recursos para aplicar a configuração apropriada.

  6. Depois que as alterações tiverem sido verificadas na fábrica de teste, implante na fábrica de produção usando a próxima tarefa da liberaçã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 por meio de um pipeline do Azure DevOps ou por meio de um modelo de Gerenciamento de Recursos.

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

Diagrama de integração contínua com o Azure Pipelines

Automatize a integração contínua usando versões do Azure Pipelines

A seguir está um guia para configurar uma versão do Azure Pipelines que automatiza a implantação de uma fábrica de dados em vários ambientes.

Requisitos

  • Uma assinatura do Azure vinculada ao Visual Studio Team Foundation Server ou Azure Repos que usa o ponto de extremidade do serviço Azure Resource Manager

  • Uma fábrica de dados configurada com a integração do Azure Repos Git.

  • Um cofre de chaves do Azure que contém os segredos para cada ambiente.

Configurar uma versão do Azure Pipelines

  1. No Azure DevOps, abra o projeto configurado com seu data factory.

  2. No lado esquerdo da página, selecione Pipelines e, em seguida, selecione Releases.

    Selecionar pipelines, versões

  3. Selecione Novo pipeline ou, se você tiver pipelines existentes, selecione Novo e, em seguida, Novo pipeline de versão.

  4. Selecione o modelo de trabalho vazio.

    Selecionar Tarefa vazia

  5. Na caixa Nome do palco , digite o nome do seu ambiente.

  6. Selecione Adicionar artefato e, em seguida, selecione o repositório git configurado com seu data factory de desenvolvimento. Selecione a ramificação de publicação do repositório para a ramificação Padrão. Por padrão, essa ramificação de publicação é adf_publish. Para a versão padrão, selecione Mais recente na ramificação padrão.

    Adicionar um artefacto

  7. Adicione uma tarefa de Implantação do Azure Resource Manager:

    a. Na vista de palco, selecione Ver tarefas de palco.

    Vista de palco

    b. Crie uma nova tarefa. Procure por Implantação de modelo ARM e selecione Adicionar.

    c. Na tarefa Implantação, selecione a assinatura, o grupo de recursos e o local do data factory de destino. Forneça credenciais, se necessário.

    d. Na lista Ação, selecione Criar ou atualizar grupo de recursos.

    e. Selecione o botão de reticências (...) ao lado da caixa Modelo . Procure o modelo do Azure Resource Manager que é gerado em sua ramificação de publicação do repositório git configurado. Procure o arquivo ARMTemplateForFactory.json na <FactoryName> pasta da ramificação adf_publish.

    f. Selecione ... ao lado da caixa Parâmetros do modelo para escolher o arquivo de parâmetros. Procure o arquivo ARMTemplateParametersForFactory.json na <FactoryName> pasta da ramificação adf_publish.

    g. Selecione ... ao lado da caixa Substituir parâmetros do modelo e insira os valores de parâmetro desejados para o data factory de destino. Para credenciais provenientes do Cofre da Chave do Azure, insira o nome do segredo entre aspas duplas. Por exemplo, se o nome do segredo for cred1, digite "$(cred1)" para esse valor.

    h. Selecione Incremental para o modo de implantação.

    Aviso

    No modo de implantação Completa, os recursos que existem no grupo de recursos, mas não são especificados no novo modelo do Gerenciador de Recursos, serão excluídos.

    Implantação do Data Factory Prod

  8. Salve o pipeline de liberação.

  9. Para acionar uma versão, selecione Criar versão. No Azure DevOps, isso pode ser automatizado.

    Selecione Criar versão

Importante

Em cenários de CI/CD, o tipo de tempo de execução de integração (IR) em ambientes diferentes deve ser o mesmo. Por exemplo, se você tiver um IR auto-hospedado no ambiente de desenvolvimento, o mesmo IR também deve ser do tipo auto-hospedado em outros ambientes, como teste e produção. Da mesma forma, se você estiver compartilhando tempos de execução de integração em vários estágios, precisará configurá-los como auto-hospedados vinculados em todos os ambientes, como desenvolvimento, teste e produção.

Obter segredos do Azure Key Vault

Se você tiver segredos para passar em um modelo do Azure Resource Manager, recomendamos que use o Azure Key Vault com a versão Azure Pipelines.

Há duas maneiras de lidar com segredos:

  1. Adicione os segredos ao arquivo de parâmetros.

    Crie uma cópia do arquivo de parâmetros que é carregado na ramificação de publicação. Defina os valores dos parâmetros que você deseja obter do Cofre da Chave usando este formato:

    {
    "parameters": {
        "azureSqlReportingDbPassword": {
            "reference": {
                "keyVault": {
                    "id": "/subscriptions/<subId>/resourceGroups/<resourcegroupId> /providers/Microsoft.KeyVault/vaults/<vault-name> "
                },
                "secretName": " < secret - name > "
            }
        }
    }
}

    Quando você usa esse método, o segredo é extraído do cofre de chaves automaticamente.

    O arquivo de parâmetros também precisa estar na ramificação de publicação.

  2. Adicione uma tarefa do Cofre da Chave do Azure antes da tarefa de Implantação do Azure Resource Manager descrita na seção anterior:

    1. Na guia Tarefas, crie uma nova tarefa. Procure o Azure Key Vault e adicione-o.

    2. Na tarefa Cofre da chave, selecione a assinatura na qual você criou o cofre da chave. Forneça credenciais, se necessário, e selecione o cofre de chaves.

    Adicionar uma tarefa do Cofre da Chave

Conceder permissões ao agente do Azure Pipelines

A tarefa Cofre da Chave do Azure pode falhar com um erro de Acesso Negado se as permissões corretas não estiverem definidas. Baixe os logs da versão e localize o arquivo .ps1 que contém o comando para conceder permissões ao agente do Azure Pipelines. Você pode executar o comando diretamente. Ou você pode copiar a ID principal do arquivo e adicionar a política de acesso manualmente no portal do Azure. Get e List são as permissões mínimas necessárias.

Atualizando gatilhos ativos

A implantação pode falhar se você tentar atualizar gatilhos ativos. Para atualizar gatilhos ativos, você precisa pará-los manualmente e reiniciá-los após a implantação. Você pode fazer isso usando uma tarefa do Azure PowerShell:

  1. Na guia Tarefas da versão, adicione uma tarefa do Azure PowerShell. Escolha a versão da tarefa 4.*.

  2. Selecione a assinatura em que sua fábrica está.

  3. Selecione Caminho do arquivo de script como o tipo de script. Isso requer que você salve o script do PowerShell em seu repositório. O seguinte script do PowerShell pode ser usado para interromper gatilhos:

    $triggersADF = Get-AzDataFactoryV2Trigger -DataFactoryName $DataFactoryName -ResourceGroupName $ResourceGroupName

$triggersADF | ForEach-Object { Stop-AzDataFactoryV2Trigger -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName -Name $_.name -Force }

Você pode concluir etapas semelhantes (com a Start-AzDataFactoryV2Trigger função) para reiniciar os gatilhos após a implantação.

Nota

Essas etapas já estão incluídas nos scripts pré e pós-implantação fornecidos pela equipe do Azure Data Factory

Promover manualmente um modelo do Resource Manager para cada ambiente

Se você não conseguir usar o Azure DevOps ou uma ferramenta de gerenciamento de versão diferente, poderá promover manualmente uma fábrica de dados usando um Modelo ARM.

  1. Na lista Modelo ARM, selecione Exportar modelo ARM para exportar o modelo do Resource Manager para sua fábrica de dados no ambiente de desenvolvimento.

    Exportar um modelo do Resource Manager

  2. Em suas fábricas de dados de teste e produção, selecione Importar modelo ARM. Esta ação leva você ao portal do Azure, onde você pode importar o modelo exportado. Selecione Criar seu próprio modelo no editor para abrir o editor de modelos do Gerenciador de Recursos.

    Crie o seu próprio modelo

  3. Selecione Carregar arquivo e, em seguida, selecione o modelo gerado do Gerenciador de Recursos. Este é o arquivo arm_template.json localizado no arquivo .zip exportado na etapa 1.

    Editar modelo

  4. Na seção de configurações, insira os valores de configuração, como credenciais de serviço vinculado. Quando terminar, selecione Comprar para implantar o modelo do Gerenciador de Recursos.

    Secção Definições

Personalizar parâmetros de modelo do Azure Resource Manager

Se sua fábrica de desenvolvimento tiver um repositório git associado, você poderá substituir os parâmetros padrão do modelo do Resource Manager do modelo do Resource Manager gerado pela publicação ou exportação do modelo. Talvez você queira substituir o modelo de parametrização padrão nestes cenários:

  • Você usa CI/CD automatizado e deseja alterar algumas propriedades durante a implantação do Gerenciador de Recursos, mas as propriedades não são parametrizadas por padrão.
  • Sua fábrica é tão grande que o modelo padrão do Gerenciador de Recursos é inválido porque tem mais do que os parâmetros máximos permitidos (256).

Para substituir o modelo de parametrização padrão, vá para o hub de gerenciamento e selecione Modelo de parametrização na seção de controle do código-fonte. Selecione Editar modelo para abrir o editor de código do modelo de parametrização.

Gerenciar parâmetros personalizados

A criação de um modelo de parametrização personalizado cria um arquivo chamado arm-template-parameters-definition.json na pasta raiz da ramificação do git. Você deve usar esse nome de arquivo exato.

Arquivo de parâmetros personalizados

Ao publicar a partir da ramificação de colaboração, o Data Factory lerá esse arquivo e usará sua configuração para gerar quais propriedades serão parametrizadas. Se nenhum arquivo for encontrado, o modelo padrão será usado.

Ao exportar um modelo do Resource Manager, o Data Factory lê esse arquivo de qualquer ramificação em que você esteja trabalhando no momento, não da ramificação de colaboração. Você pode criar ou editar o arquivo de uma ramificação privada, onde pode testar suas alterações selecionando Exportar modelo ARM na interface do usuário. Em seguida, você pode mesclar o arquivo na ramificação de colaboração.

Nota

Um modelo de parametrização personalizado não altera o limite de parâmetros do modelo ARM de 256. Ele permite que você escolha e diminua o número de propriedades parametrizadas.

Sintaxe do parâmetro personalizado

A seguir estão algumas diretrizes a serem seguidas ao criar o arquivo de parâmetros personalizados, arm-template-parameters-definition.json. O arquivo consiste em uma seção para cada tipo de entidade: gatilho, pipeline, serviço vinculado, conjunto de dados, tempo de execução de integração e fluxo de dados.

  • Insira o caminho da propriedade sob o tipo de entidade relevante.
  • Definir um nome de propriedade como * indica que você deseja parametrizar todas as propriedades sob ele (somente até o primeiro nível, não recursivamente). Você também pode fornecer exceções a essa configuração.
  • Definir o valor de uma propriedade como uma cadeia de caracteres indica que você deseja parametrizar a propriedade. Utilize o formato <action>:<name>:<stype>.
    • <action> pode ser um destes personagens:
      • = significa manter o valor atual como o valor padrão para o parâmetro.
      • - significa não manter o valor padrão para o parâmetro.
      • | é um caso especial para segredos do Cofre de Chaves do Azure para cadeias de conexão ou chaves.
    • <name> é o nome do parâmetro. Se estiver em branco, leva o nome da propriedade. Se o valor começar com um - caractere, o nome será encurtado. Por exemplo, AzureStorage1_properties_typeProperties_connectionString seria encurtado para AzureStorage1_connectionString.
    • <stype> é o tipo de parâmetro. Se <stype> estiver em branco, o tipo padrão será string. Valores suportados: string, bool, number, object, e securestring.
  • Especificar uma matriz no arquivo de definição indica que a propriedade correspondente no modelo é uma matriz. O Data Factory itera através de todos os objetos na matriz usando a definição especificada no objeto de tempo de execução de integração da matriz. O segundo objeto, uma cadeia de caracteres, torna-se o nome da propriedade, que é usado como o nome para o parâmetro para cada iteração.
  • Uma definição não pode ser específica para uma instância de recurso. Qualquer definição aplica-se a todos os recursos desse tipo.
  • Por padrão, todas as cadeias de caracteres seguras, como segredos do Cofre da Chave, e cadeias de caracteres seguras, como cadeias de conexão, chaves e tokens, são parametrizadas.

Modelos ligados

Se você configurou CI/CD para suas fábricas de dados, poderá exceder os limites de modelo do Azure Resource Manager à medida que sua fábrica cresce. Por exemplo, um limite é o número máximo de recursos em um modelo do Gerenciador de Recursos. Para acomodar grandes fábricas enquanto gera o modelo completo do Gerenciador de Recursos para uma fábrica, o Data Factory agora gera modelos vinculados do Gerenciador de Recursos. Com esse recurso, toda a carga útil de fábrica é dividida em vários arquivos para que você não seja limitado pelos limites.

Se você configurou o Git, os modelos vinculados são gerados e salvos junto com os modelos completos do Gerenciador de Recursos na ramificação adf_publish em uma nova pasta chamada linkedTemplates. Os modelos vinculados do Gerenciador de Recursos geralmente consistem em um modelo mestre e um conjunto de modelos filho vinculados ao mestre. O modelo pai é chamado de ArmTemplate_master.json e os modelos filho são nomeados com o padrão ArmTemplate_0.json, ArmTemplate_1.json e assim por diante.

Para usar modelos vinculados em vez do modelo completo do Gerenciador de Recursos, atualize sua tarefa CI/CD para apontar para ArmTemplate_master.json em vez de ArmTemplateForFactory.json (o modelo completo do Gerenciador de Recursos). O Gerenciador de Recursos também exige que você carregue os modelos vinculados em uma conta de armazenamento para que o Azure possa acessá-los durante a implantação.

Ambiente de produção de hotfix

Se você implantar uma fábrica na produção e perceber que há um bug que precisa ser corrigido imediatamente, mas não puder implantar a ramificação de colaboração atual, talvez seja necessário implantar um hotfix. Essa abordagem é conhecida como engenharia de correção rápida ou QFE.

  1. No Azure DevOps, vá para a versão que foi implantada na produção. Encontre a última confirmação que foi implantada.

  2. Na mensagem de confirmação, obtenha a ID de confirmação da ramificação de colaboração.

  3. Crie uma nova ramificação de hotfix a partir dessa confirmação.

  4. Vá para a UX do Azure Data Factory e alterne para a ramificação do hotfix.

  5. Usando a UX do Azure Data Factory, corrija o bug. Teste as alterações.

  6. Depois que a correção for verificada, selecione Exportar modelo ARM para obter o modelo do Gerenciador de recursos de hotfix.

  7. Verifique manualmente essa compilação na ramificação de publicação.

  8. Se você configurou seu pipeline de liberação para acionar automaticamente com base em adf_publish check-ins, uma nova versão será iniciada automaticamente. Caso contrário, enfileire manualmente uma versão.

  9. Implante a versão do hotfix nas fábricas de teste e produção. Esta versão contém a carga útil de produção anterior mais a correção que você fez na etapa 5.

  10. Adicione as alterações do hotfix à ramificação de desenvolvimento para que versões posteriores não incluam o mesmo bug.

Melhores práticas para Integração Contínua/Entrega Contínua

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 o seu data factory de desenvolvimento com integração 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 pré e pós-implantação. Antes da etapa de implantação do Gerenciador de Recursos em CI/CD, você precisa concluir determinadas tarefas, como parar e reiniciar gatilhos e executar limpeza. Recomendamos que você use scripts do PowerShell antes e depois da tarefa de implantação. A equipe do data factory forneceu um script para uso localizado na página de documentação do CI/CD do Azure Data Factory.

  • 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 você tenha o mesmo nome e tipo de tempo de execução 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. Você pode usar essa fábrica compartilhada em todos os seus ambientes como um tipo de tempo de execução de integração vinculado.

  • 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.

  • Cofre da chave. Quando você usa serviços vinculados cujas informações de conexão são armazenadas no Cofre de Chaves do Azure, é 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 segredos de produção. Se você seguir essa abordagem, recomendamos que mantenha os mesmos nomes secretos em todos os estágios. Se você mantiver os mesmos nomes secretos, não precisará parametrizar cada cadeia de conexão em 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 a restrições de modelo ARM, problemas na implantação podem surgir se seus recursos contiverem espaços no nome. A equipe do Azure Data Factory recomenda o uso de caracteres '_' ou '-' em vez de espaços para recursos. Por exemplo, «Pipeline_1» seria um nome preferível a «Pipeline 1».