Controle do código-fonte no Azure Data Factory

APLICA-SE A: Azure Data Factory Azure Synapse Analytics

Dica

Experimente o Data Factory no Microsoft Fabric, uma solução de análise tudo-em-um para empresas. O Microsoft Fabric abrange desde movimentação de dados até ciência de dados, análise em tempo real, business intelligence e relatórios. Saiba como iniciar uma avaliação gratuita!

Por padrão, a UX (experiência de interface do usuário) do Azure Data Factory faz a autenticação diretamente no serviço de Data Factory. Essa experiência tem as seguintes limitações:

• O serviço de Data Factory não inclui um repositório para armazenar as entidades JSON para as alterações. A única maneira de salvar as alterações é por meio do botão Publicar Tudo, e todas as alterações são publicadas diretamente no serviço de Data Factory.
• O serviço de Data Factory não está otimizado para colaboração e controle de versão.
• O modelo do Azure Resource Manager necessário para implantar o próprio Data Factory não está incluído.

Para fornecer uma experiência de criação melhor, o Azure Data Factory permite que você configure um repositório Git com o Azure Repos ou o GitHub. O Git é um sistema de controle de versão que facilita o controle de alterações e a colaboração. Esse artigo descreve como configurar e trabalhar em um repositório git, além de destacar as práticas recomendadas e um guia de solução de problemas.

Também é possível conferir CI/CD (integração e entrega contínuas) no Azure Data Factory para saber mais sobre o padrão de CI/CD maior, que tem o controle do código-fonte como aspecto crítico.

Observação

Adicionamos suporte público do GitHub ao Azure Gov e ao Microsoft Azure operado pela 21Vianet. Consulte o blog do comunicado.

Para saber mais sobre como o Azure Data Factory se integra ao Git, veja o vídeo do tutorial de 15 minutos abaixo:

Vantagens da integração do Git

Abaixo está uma lista de algumas das vantagens que a integração com o Git fornece à experiência de criação:

• Controle do código-fonte: à medida que as cargas de trabalho do seu data factory se tornam cruciais, você gostaria de integrar sua fábrica ao Git para aplicar vários benefícios de controle do código-fonte, como os seguintes:
  • Capacidade de controlar/auditar as alterações.
  • Capacidade de reverter as alterações que introduziram bugs.
• Guardas parciais: A criação no serviço de fábrica de dados, não é possível guardar alterações como rascunho e todas as publicações devem passar pela validação da fábrica de dados. Quer os seus pipelines não estejam concluídos ou simplesmente não queira perder alterações se o seu computador falhar, a integração do git permite alterações incrementais dos recursos da fábrica de dados, independentemente do estado em que se encontrem. Configurar um repositório git permite que você salve as alterações, permitindo que você publique apenas depois de testar suas alterações de forma satisfatória.
• Colaboração e controle: se você tiver vários membros da equipe contribuindo para o mesmo alocador, talvez queira permitir qu e seus colegas de equipe colaborem entre si por meio de um processo de revisão de código. Você também pode configurar seu alocador de forma que nem todos os colaboradores tenham permissões iguais. Alguns membros da equipe podem fazer alterações apenas por meio do Git, e somente determinadas pessoas da equipe têm permissão para publicar as alterações no seu alocador.
• Melhor CI/CD: se você estiver implantando em vários ambientes com um processo de entrega contínua, a integração do git facilita determinadas ações. Algumas dessas ações incluem:
  • Configurar seu pipeline de liberação para disparar automaticamente assim que houver uma alteração feita no alocador de "desenvolvimento".
  • Personalize as propriedades no alocador que estejam disponíveis como parâmetros no modelo do Resource Manager. Pode ser útil manter apenas o conjunto necessário de propriedades como parâmetros e ter todo o resto codificado.
• Melhor desempenho: Um alocador médio integrado ao Git é carregado 10 vezes mais rápido do que uma criação no serviço de Data Factory. Essa melhoria de desempenho ocorre porque os recursos são baixados por meio do Git.

Observação

A criação direta com o serviço de Data Factory é desabilitada na UX do Azure Data Factory quando um repositório Git é configurado. As alterações feitas por meio do PowerShell ou de um SDK são publicadas diretamente no serviço Data Factory e não são inseridas no Git.

Conectar-se a um repositório Git

Há quatro maneiras diferentes de conectar um repositório Git ao seu data factory para o Azure Repos e o GitHub. Depois de se conectar a um repositório Git, você poderá visualizar e gerenciar sua configuração no hub de gerenciamento em Configuração do Git na seção Controle de origem.

Método de configuração 1: home page

Na página inicial do Azure Data Factory, selecione Configurar o repositório de códigona parte superior.

Método de configuração 2: tela de criação

Na tela de criação de UX do Azure Data Factory, selecione o menu suspenso Data Factory e clique em Configurar o repositório de código.

Método de configuração 3: hub de gerenciamento

Acesse o hub de gerenciamento no Azure Data Factory Studio. Selecione Configuração do Git na seção Controle do código-fonte. Se você não tiver nenhum repositório conectado, selecione Configurar.

Método de configuração 4: durante a criação de fábrica

Ao criar um data factory no portal do Azure, você pode configurar as informações do repositório do Git na guia Configuração do Git.

Observação

Ao configurar o git no Portal do Azure, configurações como nome do projeto e nome do repositório devem ser inseridas manualmente em vez de fazerem parte de um menu suspenso.

Criar com a integração do Git ao Azure Repos

A criação visual com a integração do Git ao Azure Repos dá suporte ao controle do código-fonte e à colaboração para trabalhar nos pipelines de data factory. Você pode associar um data factory a um repositório da organização do Git do Azure Repos para obter controle do código-fonte, colaboração, controle de versão e assim por diante. Uma única organização do Git do Azure Repos pode ter vários repositórios, mas um repositório Git do Azure Repos pode ser associado a apenas um data factory. Se você não tiver uma organização ou um repositório do Azure Repos, siga estas instruções para criar seus recursos.

Observação

Você pode armazenar arquivos de script e de dados em um repositório Git do Azure Repos. No entanto, você precisa carregar os arquivos manualmente para o Armazenamento do Azure. Um pipeline do data factory não faz upload automático dos arquivos de dados ou de script armazenados em um repositório Git do Azure Repos para o Armazenamento do Azure. Arquivos adicionais, como modelos do ARM, scripts ou arquivos de configuração, podem ser armazenados no repositório fora da pasta mapeada. Se você fizer isso, tenha em mente que uma tarefa adicional é necessária para compilar/implantar e interagir com os arquivos armazenados fora da pasta mapeada do Azure DevOps.

Configurações do Azure Repos

O painel de configuração orienta você passo a passo na definição de cada uma das seguintes configurações do repositório de código:

Configuração	Descrição	Valor
Tipo de repositório	O tipo do repositório de código do Azure Repos.	Git ou GitHub do Azure DevOps
Microsoft Entra ID	Seu nome de locatário do Microsoft Entra.	<your tenant name>
Organização do Azure Repos	O nome da organização do Azure Repos. Localize o nome de organização do Azure Repos em https://{organization name}.visualstudio.com. Você pode entrar na sua organização do Azure Repos para acessar seu perfil do Visual Studio e ver seus repositórios e projetos.	<your organization name>
ProjectName	O nome do projeto do Azure Repos. Localize o nome do projeto do Azure Repos em https://{organization name}.visualstudio.com/{project name}.	<your Azure Repos project name>
RepositoryName	O nome do seu repositório de código do Azure Repos. Os projetos do Azure Repos contêm repositórios Git para gerenciar seu código-fonte à medida que o projeto aumenta. Você pode criar um novo repositório ou usar um existente que já esteja no projeto.	<your Azure Repos code repository name>
Ramificação de colaboração	Seu branch de colaboração do Azure Repos que é usado para publicação. Por padrão, ele é main. Altere essa configuração se você desejar publicar recursos de outra ramificação.	<your collaboration branch name>
Branch de publicação	O branch de publicação é o branch em seu repositório onde os modelos do ARM relacionados à publicação são armazenados e atualizados. Por padrão, ele é adf_publish.	<your publish branch name>
Pasta raiz	A pasta raiz em seu branch de colaboração do Azure Repos.	<your root folder name>
Importar recursos existentes do Data Factory para o repositório	Especifica se é necessário importar recursos existentes do data factory da Tela de criação da UX em um repositório Git do Azure Repos. Selecione a caixa para importar os recursos do data factory para o repositório do Git associado no formato JSON. Esta ação exporta cada recurso individualmente (ou seja, os serviços vinculados e conjuntos de dados são exportados para JSONs separados). Quando essa caixa não está selecionada, os recursos existentes não são importados.	Selecionada (padrão)
Branch para importar o recurso	Especifica em qual branch os recursos do data factory (pipelines, conjuntos de dados, serviços vinculados etc.) serão importados. Você pode importar recursos para um dos seguintes branches: a. Colaboração b. Criar novo c. Usar Existente

Observação

Se você estiver usando o Microsoft Edge e não vir nenhum valor em seu menu suspenso da conta do Azure DevOps, adicione https://*.visualstudio.com à lista de sites confiáveis.

Editar as configurações do repositório

Se algum ajuste for necessário nas configurações do repositório Git do Azure Repos configurado, selecione Editar.

É possível atualizar o branch de publicação e decidir se você deseja ou não desabilitar o botão de publicação do estúdio do ADF. Se você optar por desativar o botão de publicação no estúdio, o botão de publicação ficará esmaecido no estúdio. Isso ajuda a evitar sua substituição da última implantação de publicação automatizada.

Usar um locatário diferente do Microsoft Entra

O repositório Git do Azure Repos pode estar em um locatário diferente do Microsoft Entra. Para especificar outro locatário do Microsoft Entra, você precisa ter permissões de administrador para a assinatura do Azure que está usando. Para obter mais informações, veja alterar administrador de assinatura.

Importante

Para se conectar a outro Microsoft Entra ID, o usuário conectado deve fazer parte do Active Directory.

Usar sua conta Microsoft pessoal

Para usar uma conta Microsoft pessoal para integração com o Git, você poderá vincular seu Repositório do Azure pessoal ao Active Directory da sua organização.

1. Adicione sua conta Microsoft pessoal ao Active Directory da sua organização como convidado. Para saber mais, confira Adicionar usuários de colaboração B2B do Microsoft Entra no portal do Azure.

2. Entre no portal do Azure com sua conta pessoal da Microsoft. Em seguida, alterne para o Active Directory da sua organização.

3. Vá para a seção Azure DevOps, onde você agora vê seu repositório pessoal. Selecione o repositório e conecte-se com o Active Directory.

Após essas etapas de configuração, seu repositório pessoal estará disponível quando você configurar a integração de Git na IU do Data Factory.

Para saber mais sobre como se conectar ao Azure Repos para o Active Directory da sua organização, consulte Conectar sua organização do Azure DevOps ao Microsoft Entra ID.

Criar com a integração do GitHub

A criação visual com a integração do GitHub oferece suporte ao controle do código-fonte e à colaboração para trabalhar em seus pipelines de data factory. Você pode associar um data factory com um repositório de conta do GitHub para controle do código-fonte, colaboração e controle de versão. Uma única conta do GitHub pode hospedar vários repositórios e cada repositório pode ser associado a vários data factories. Ao configurar cada data factory para usar um branch diferente no mesmo repositório, você poderá manter ambientes separados (como desenvolvimento, preparo e produção) ao mesmo tempo em que gerencia suas configurações de forma independente. Se não tiver uma conta ou repositório do GitHub, siga estas instruções para criar seus recursos.

A integração do GitHub com o Data Factory dá suporte ao GitHub público (ou seja, https://github.com), ao GitHub Enterprise Cloud e ao GitHub Enterprise Server. Você pode usar os repositórios GitHub públicos e privados com o Data Factory, desde que você tenha permissão de leitura e de escrita para o repositório no GitHub. Para se conectar a um repositório público, selecione a opção Usar Link Repository, pois eles não são visíveis no menu suspenso de Nome do repositório. A integração do GitHub Enterprise Server do ADF funciona apenas com versões com suporte oficial do GitHub Enterprise Server.

Para repositórios pertencentes à conta da organização GitHub, o administrador deve autorizar o aplicativo ADF. Para repositórios pertencentes a uma conta de usuário do GitHub, um usuário com permissão de colaborador ou superior pode autorizar o aplicativo ADF. Essa permissão não dá ao aplicativo ADF acesso direto a todos os repositórios de propriedade da conta/organização, ela apenas permite que o aplicativo ADF atue em nome do usuário para acessar repositórios com base nas permissões de acesso do usuário.

Observação

Se você estiver usando o Microsoft Edge, uma versão do GitHub Enterprise inferior a 2.1.4 não funcionará com ele. Oficialmente, o GitHub dá suporte a >=3.0, e todas elas funcionarão no ADF. À medida que o GitHub altera sua versão mínima, as versões suportadas pelo ADF também são alteradas.

Configurações do GitHub

Observação

Se você encontrar o erro Falha ao listar os repositórios do GitHub. Certifique-se de que o nome da conta está correto e que você tem permissão para realizar a ação., verifique se está usando o nome correto do proprietário e não a URL do repositório do GitHub. Por exemplo, se a URL do repositório for https://github.com/contoso/contoso-ads, o proprietário será contoso, e não a URL completa.

O painel de configuração mostra as seguintes configurações do repositório do GitHub:

Configuração	Descrição	Valor
Tipo de repositório	O tipo do repositório de código do Azure Repos.	GitHub
Usar o GitHub Enterprise Server	Caixa de seleção para marcar o GitHub Enterprise Server.	não selecionado (padrão)
URL do GitHub Enterprise Server	A URL raiz do GitHub Enterprise (precisa ser HTTPS para o servidor do GitHub Enterprise local). Por exemplo: https://github.mydomain.com. Obrigatório somente se a opção Usar o GitHub Enterprise Server for selecionada	<your GitHub Enterprise Server URL>
Proprietário do repositório GitHub	Organização ou conta do GitHub que possui o repositório. Esse nome pode ser encontrado em https://github.com/{owner}/{repository nome}. Navegar até essa página solicita que você insira as credenciais do GitHub OAuth para sua conta ou organização do GitHub. Se você selecionar Usar GitHub Enterprise Server, uma caixa de diálogo será exibida permitindo que você insira seu token de acesso.	<your GitHub repository owner name>
Nome do repositório	O nome do repositório de código do GitHub. As contas do GitHub contêm repositórios Git para gerenciar seu código-fonte. Você pode criar um novo repositório ou usar um existente que já esteja na conta. Especifique o nome do repositório de código do GitHub ao escolher Selecionar repositório.	<your repository name>
Link do repositório Git	O link do repositório de código do GitHub. Especifique o link do repositório de código do GitHub ao escolher Usar link do repositório.	<your repository link>
Ramificação de colaboração	Sua ramificação de colaboração do GitHub usada para publicação. Por padrão, é a principal. Altere essa configuração se você desejar publicar recursos de outra ramificação. Você também pode criar um novo branch de colaboração aqui.	<your collaboration branch>
Branch de publicação	A ramificação no seu repositório onde os modelos ARM relacionados à publicação são armazenados e atualizados.	<your publish branch name>
Pasta raiz	Sua pasta raiz em sua ramificação de colaboração GitHub.	<your root folder name>
Importar recursos existentes para o repositório	Especifica se deve-se importar recursos do data factory existentes da UX Tela de criação em um repositório do GitHub. Selecione a caixa para importar os recursos do data factory para o repositório do Git associado no formato JSON. Esta ação exporta cada recurso individualmente (ou seja, os serviços vinculados e conjuntos de dados são exportados para JSONs separados). Quando essa caixa não está selecionada, os recursos existentes não são importados.	Selecionada (padrão)
Importar recurso para este branch	Especifica em qual branch os recursos do data factory (pipelines, conjuntos de dados, serviços vinculados etc.) serão importados.

Editar as configurações do repositório

Se algum ajuste for necessário nas configurações do repositório do GitHub configurado, selecione Editar.

É possível atualizar o branch de publicação e decidir se você deseja ou não desabilitar o botão de publicação do estúdio do ADF. Se você optar por desativar o botão de publicação no estúdio, o botão de publicação ficará esmaecido no estúdio. Isso ajuda a evitar a substituição da última implantação de publicação automatizada.

Organizações do GitHub

Conectar-se a uma organização do GitHub requer que a organização conceda permissão para o Azure Data Factory. Um usuário com permissões de ADMINISTRADOR na organização deve realizar as etapas a seguir para permitir que o data factory se conecte.

Conectar ao GitHub público ou GitHub Enterprise Cloud pela primeira vez no Azure Data Factory

Se você estiver se conectando ao GitHub público ou GitHub Enterprise Cloud no Azure Data Factory pela primeira vez, siga estas etapas para se conectar a uma organização do GitHub.

1. No painel configuração do Git, insira o nome da organização no campo Conta do GitHub. Uma solicitação para fazer login no GitHub é exibida.
2. Faça login usando suas credenciais de usuário.
3. Você será solicitado a autorizar o Azure Data Factory como um aplicativo chamado AzureDataFactory. Nessa tela, você vê uma opção para conceder permissão ao ADF para acessar a organização. Se essa opção não aparecer, peça a um administrador que conceda manualmente a permissão por meio do GitHub.

Depois de seguir essas etapas, sua fábrica poderá se conectar a repositórios públicos e privados em sua organização. Se você não conseguir se conectar, tente limpar o cache do navegador e tente novamente.

Já conectou ao GitHub público ou ao GitHub Enterprise Cloud usando uma conta pessoal

Se você já se conectou ao GitHub público ou ao GitHub Enterprise Cloud e concedeu permissão apenas para acessar uma conta pessoal, siga as etapas abaixo para conceder permissões a uma organização.

1. Acesse o GitHub e abra Configurações.

   

2. Selecione Aplicativos. Na guia Aplicativos OAuth autorizados, você verá AzureDataFactory.

   

3. Selecione o aplicativo e conceda acesso à sua organização.

   

Depois de seguir essas etapas, sua fábrica poderá se conectar a repositórios públicos e privados em sua organização.

Conectar ao GitHub Enterprise Server

Se você se conectar ao GitHub Enterprise Server, precisará usar um token de acesso pessoal para autenticação. Saiba como criar um token de acesso pessoal em Criar um token de acesso pessoal.

Observação

GitHub Enterprise Server está em seu ambiente privado auto-hospedado, portanto, você precisa de controle total do firewall, das políticas de rede e da VPN ao usar essa autenticação. Para obter mais informações, confira Sobre o GitHub Enterprise Server.

Limitações conhecidas do GitHub

• Você pode armazenar arquivos de dados e scripts em um repositório GitHub. No entanto, você precisa carregar os arquivos manualmente para o Armazenamento do Azure. Um pipeline do Data Factory não carrega automaticamente scripts ou arquivos de dados armazenados em um repositório GitHub para o Armazenamento do Microsoft Azure.

• O GitHub Enterprise com uma versão mais antiga que 2.14.0 não funciona no navegador Microsoft Edge.

• A integração do GitHub com as ferramentas de criação visual do Data Factory funciona apenas na versão geralmente disponível do Data Factory.

Conectando ao Azure DevOps Server 2022

Se você se conectar ao Azure DevOps Server 2022, precisará usar um token de acesso pessoal para autenticação. Saiba como criar um token de acesso pessoal aqui.

Conectar-se ao Azure DevOps local fornecendo o Azure DevOps Server URL e Azure DevOps Project Collection

Forneça o token com escopo de acesso como leitura/gravação para código.

Controle de versão

Os sistemas de controle de versão (também conhecidos como controle do código-fonte) permitem aos desenvolvedores colaborar em código e acompanhar as alterações feitas no código base. O controle do código-fonte é uma ferramenta essencial para projetos de vários desenvolvedores.

Criando branches de recurso

Cada repositório Git do Azure Repos que está associado a um data factory tem um branch de colaboração. (main é a ramificação de colaboração padrão). Os usuários também podem criar branches de recurso clicando em + Novo Branch na lista suspensa do branch.

Depois que o novo painel do branch for exibido, insira o nome do branch de recurso e selecione um branch para servir de base do trabalho.

Quando você estiver pronto para mesclar as alterações do branch de recurso com o branch de colaboração, clique na lista suspensa do branch e selecione Criar solicitação de pull. Essa ação o levará para o Git do Azure Repos, em que será possível gerar solicitações de pull, realizar revisões de código e mesclar alterações com o branch de colaboração. (main é o padrão). Você só tem permissão para publicar no serviço do Data Factory de sua ramificação de colaboração.

Definir configurações de publicação

Por padrão, o data factory gera os modelos do Resource Manager do alocador publicado e os salva em um branch chamado adf_publish. Para configurar um branch de publicação personalizada, adicione um arquivo publish_config.json à pasta raiz no branch de colaboração. Na publicação, o ADF lê esse arquivo, procura o campo publishBranch e salva todos os modelos do Resource Manager no local especificado. Se a ramificação não existir, o data factory a criará automaticamente. Um exemplo da aparência desse arquivo está abaixo:

{
    "publishBranch": "factory/adf_publish"
}

O Azure Data Factory pode ter apenas um branch de publicação por vez. Quando você especifica um novo branch de publicação, o Data Factory não exclui o branch de publicação anterior. Se você quiser remover o branch de publicação anterior, exclua-o manualmente.

Observação

O Data Factory apenas lê o arquivo publish_config.json quando ele carrega o factory. Se o factory já estiver carregado no portal, atualize o navegador para que as alterações entrem em vigor.

Publicar alterações de código

Depois de mesclar alterações para o branch de colaboração (main é o padrão), clique em Publicar para publicar manualmente as alterações de código no branch principal para o serviço do Data Factory.

Um painel lateral será aberto para você confirmar que o branch de publicação e as alterações pendentes estão corretas. Depois de verificar as alterações, clique em OK para confirmar a publicação.

Importante

O branch principal não representa o que é implantado no serviço de Data Factory. O branch principal deve ser publicado manualmente no serviço de Data Factory.

Melhores práticas para a integração do Git

Permissões

Normalmente, você não deseja que todos os membros da equipe tenham permissão para atualizar o Data Factory. As seguintes configurações de permissões são recomendadas:

• Todos os membros da equipe devem ter permissões de leitura para o Data Factory.
• Somente um conjunto selecionado de pessoas deve ter permissão para publicar no Data Factory. Para fazer isso, é necessária a função de Colaborador do Data Factory no Grupo de recursos que contém o Data Factory. Para obter mais informações sobre permissões, confira Funções e permissões para o Azure Data Factory.

É recomendável não permitir check-ins diretos no branch de colaboração. Essa restrição pode ajudar a evitar bugs, uma vez que cada check-in passará por um processo de revisão de solicitação de pull descrito em Criando branches de recurso.

Usando senhas do Azure Key Vault

É recomendável usar o Azure Key Vault para armazenar cadeias de conexão, senhas ou a autenticação de identidade gerenciada de Serviços Vinculados do Data Factory. Por motivos de segurança, o Data Factory não armazena segredos no Git. As alterações nos Serviços Vinculados que contenham segredos, como senhas, são publicadas imediatamente no serviço do Azure Data Factory.

Usar a autenticação do Key Vault ou MSI também facilita a integração e a implantação contínuas, pois você não precisará fornecer esses segredos durante a implantação do modelo do Resource Manager.

Solução de problemas na integração com o Git

Branch de publicação obsoleto

Abaixo estão alguns exemplos de situações que podem tornar um branch de publicação obsoleto:

• Um usuário tem vários branches. Em um branch de recurso, eles excluíram um serviço vinculado que não está associado ao AKV (os serviços vinculados que não são do AKV são publicados imediatamente, independentemente de estarem no Git ou não) e nunca mesclaram o branch de recursos com o branch de colaboração.
• Um usuário modificou o data factory usando o SDK ou o PowerShell
• Um usuário moveu todos os recursos para um novo branch e tentou publicar pela primeira vez. Os serviços vinculados devem ser criados manualmente na importação de recursos.
• Um usuário carrega um serviço vinculado que não é o AKV ou um Integration Runtime JSON manualmente. Eles fazem referência a esse recurso de outro recurso, como um conjunto de dados, um serviço vinculado ou um pipeline. Um serviço vinculado não AKV criado por meio da interface do usuário é publicado imediatamente porque as credenciais precisam ser criptografadas. Se você fizer o upload de um conjunto de dados referenciando esse serviço vinculado e tentar publicar, a interface do usuário permitirá, pois ele existe no ambiente git. Ele será rejeitado no momento da publicação, pois não existe no serviço de Data Factory.

Se a ramificação de publicação não estiver sincronizada com a ramificação principal e contiver recursos desatualizados, apesar de uma publicação recente, você pode usar uma das soluções abaixo:

Opção 1: usar a funcionalidade Substituir modo dinâmico

Ela publica ou substitui o código da ramificação de colaboração no modo dinâmico. Ele considera o código do seu repositório como a fonte da verdade.

Fluxo de código: Branch de colaboração -> Modo dinâmico

Opção 2: desconectar e reconectar o repositório Git

Ela importa o código do modo dinâmico para a ramificação de colaboração. Ela considera o código no modo dinâmico como a fonte da verdade.

Fluxo de código: Modo dinâmico -> Branch de colaboração

1. Remover seu repositório Git atual
2. Reconfigure o Git com as mesmas configurações, mas verifique se a opção Importar recursos do Data Factory existentes para o repositório está selecionada e escolha Branch de colaboração (o mesmo branch)
3. Crie uma solicitação de pull para mesclar as alterações com o branch de colaboração.

Observação

Só será necessário criar e mesclar uma solicitação de pull se você estiver trabalhando em um repositório que não permita confirmações diretas. Na maioria das organizações, os envios para o repositório exigem revisão antes da fusão, portanto, a prática recomendada geralmente é usar essa abordagem. Mas, em alguns casos, não é exigida nenhuma revisão e, nesse caso, não é necessário criar e mesclar uma solicitação de pull, mas as alterações podem ser confirmadas diretamente no branch de colaboração.

Escolha um dos métodos adequadamente, conforme necessário.

Todos os recursos exibidos como novos na publicação

Durante a publicação, todos os recursos podem aparecer como novos, mesmo se eles tiverem sido publicados anteriormente. Isso pode ocorrer se a propriedade lastCommitId for redefinida na propriedade repoConfiguration do alocador, seja reimplantando um modelo do ARM do alocador ou atualizando a propriedade repoConfiguration do alocador por meio do PowerShell na API REST. Continuar a publicar os recursos pode resolver o problema, mas para evitar que ele ocorra novamente, evite atualizar a propriedade repoConfiguration de fábrica.

Alternar para um repositório Git diferente

Para alternar para um repositório do Git diferente, vá para a página de configuração do git no hub de gerenciamento sob Controle do código-fonte. Selecione Desconectar.

Insira seu nome do Data Factory e clique em Confirmar para remover o repositório Git associado ao data factory.

Depois de remover a associação com o repositório atual, você poderá definir as configurações do Git para usar um repositório diferente e importar recursos existentes do Data Factory para o novo repositório.

Importante

A remoção da configuração do Git de um data factory não exclui nada do repositório. A fábrica contém todos os recursos publicados. Você pode continuar a editar o alocador diretamente no serviço.

Conteúdo relacionado

• Para saber mais sobre o monitoramento e o gerenciamento de pipelines, c Monitorar e gerenciar os pipelines programaticamente.
• Para implementar a integração e a implantação contínuas, confira CI/CD (integração e entrega contínuas) no Azure Data Factory.