Partilhar via

Escolha a melhor opção de fluxo de trabalho de CI/CD de malha para você

  • Artigo

O objetivo deste artigo é apresentar aos desenvolvedores do Fabric diferentes opções para criar processos de CI/CD no Fabric, com base em cenários comuns de clientes. Este artigo se concentra mais na implantação contínua (CD) do processo de CI/CD. Para obter uma discussão sobre a parte de integração contínua (CI), consulte Gerenciar ramificações do Git.

Embora este artigo descreva várias opções distintas, muitas organizações adotam uma abordagem híbrida.

Pré-requisitos

Para acessar o recurso de pipelines de implantação, você deve atender às seguintes condições:

Processo de desenvolvimento

O processo de desenvolvimento é o mesmo em todos os cenários de implantação e independe de como lançar novas atualizações em produção. Quando os desenvolvedores trabalham com controle do código-fonte, eles precisam trabalhar em um ambiente isolado. Na Malha, esse ambiente pode ser um IDE em sua máquina local (como o Power BI Desktop ou o VS Code) ou um espaço de trabalho diferente na Malha. Você pode encontrar informações sobre as diferentes considerações para o processo de desenvolvimento em Gerenciar ramificações do Git

Diagrama mostrando como funciona o processo de desenvolvimento.

Processo de liberação

O processo de lançamento começa assim que novas atualizações são concluídas e a solicitação pull (PR) é mesclada na ramificação compartilhada da equipe (como Main, Dev etc.). A partir desse ponto, há diferentes opções para criar um processo de liberação no Fabric.

Opção 1 - Implantações baseadas em Git

Diagrama mostrando como funciona a implantação baseada no Git.

Com essa opção, todas as implantações são originadas do repositório Git. Cada estágio no pipeline de liberação tem uma ramificação primária dedicada (no diagrama, esses estágios são Dev, Test e Prod), que alimenta o espaço de trabalho apropriado no Fabric.

Uma vez que um PR para a ramificação de Dev é aprovado e mesclado:

  1. Um pipeline de versão é acionado para atualizar o conteúdo do espaço de trabalho de desenvolvimento . Esse processo também pode incluir um pipeline de compilação para executar testes de unidade, mas o carregamento real de arquivos é feito diretamente do repositório para o espaço de trabalho, usando APIs do Fabric Git. Talvez seja necessário chamar outras APIs de malha para operações pós-implantação que definam configurações específicas para esse espaço de trabalho ou ingerir dados.
  2. Um PR é então criado para a ramificação Teste . Na maioria dos casos, o PR é criado usando uma ramificação de lançamento que pode escolher o conteúdo para passar para a próxima etapa. O RP deve incluir os mesmos processos de revisão e aprovação que qualquer outro em sua equipe ou organização.
  3. Outro pipeline de compilação e liberação é acionado para atualizar o espaço de trabalho Teste , usando um processo semelhante ao descrito na primeira etapa.
  4. Um PR é criado para a ramificação Prod , usando um processo semelhante ao descrito na etapa #2.
  5. Outro pipeline de compilação e liberação é acionado para atualizar o espaço de trabalho Prod , usando um processo semelhante ao descrito na primeira etapa.

Quando você deve considerar o uso da opção #1?

  • Quando você quiser usar seu repositório Git como a única fonte de verdade e a origem de todas as implantações.
  • Quando sua equipe segue o Gitflow como a estratégia de ramificação, incluindo várias ramificações primárias.
  • O upload do repositório vai diretamente para o espaço de trabalho, pois não precisamos de ambientes de compilação para alterar os arquivos antes das implantações. Você pode alterar isso chamando APIs ou executando itens no espaço de trabalho após a implantação.

Opção 2 - Implantações baseadas em Git usando ambientes de compilação

Diagrama mostrando o fluxo de implantação baseada em Git usando ambientes de compilação.

Com essa opção, todas as implantações são originadas da mesma ramificação do repositório Git (Principal). Cada estágio no pipeline de liberação tem um pipeline de compilação e liberação dedicado. Esses pipelines podem usar um ambiente de compilação para executar testes de unidade e scripts que alteram algumas das definições nos itens antes de serem carregados no espaço de trabalho. Por exemplo, talvez você queira alterar a conexão da fonte de dados, as conexões entre itens no espaço de trabalho ou os valores dos parâmetros para ajustar a configuração para o estágio certo.

Uma vez que um PR para a ramificação de desenvolvimento é aprovado e mesclado:

  1. Um pipeline de compilação é acionado para girar um novo ambiente de compilação e executar testes de unidade para o estágio de desenvolvimento . Em seguida, um pipeline de liberação é acionado para carregar o conteúdo em um ambiente de compilação, executar scripts para alterar parte da configuração, ajustar a configuração para o estágio de desenvolvimento e usar as APIs de definição de item de atualização do Fabric para carregar os arquivos no espaço de trabalho.
  2. Quando esse processo estiver concluído, incluindo a ingestão de dados e a aprovação dos gerentes de versão, os próximos pipelines de compilação e liberação para o estágio de teste poderão ser criados. Essas etapas são criadas em um processo semelhante ao descrito na primeira etapa. Para o estágio de teste , outros testes automatizados ou manuais podem ser necessários após a implantação, para validar que as alterações estão prontas para serem liberadas para o estágio Prod .
  3. Quando todos os testes automatizados e manuais estiverem concluídos, o gerente de liberação poderá aprovar e iniciar os pipelines de compilação e liberação para o estágio Prod. Como o estágio Prod geralmente tem configurações diferentes dos estágios de teste/desenvolvimento , é importante também testar as alterações após a implantação. Além disso, a implantação deve desencadear mais ingestão de dados, com base na mudança, para minimizar a potencial indisponibilidade para os consumidores.

Quando você deve considerar o uso da opção #2?

  • Quando você quiser usar o Git como sua única fonte de verdade e a origem de todas as implantações.
  • Quando sua equipe segue o fluxo de trabalho baseado em tronco como sua estratégia de ramificação.
  • Você precisa de um ambiente de compilação (com um script personalizado) para alterar atributos específicos do espaço de trabalho, como connectionId e lakehouseId, antes da implantação.
  • Você precisa de um pipeline de liberação (script personalizado) para recuperar o conteúdo do item do git e chamar a API de Item de Malha correspondente para criar, atualizar ou excluir Itens de Malha modificados.

Opção 3 - Implantar usando pipelines de implantação de malha

Diagrama mostrando o fluxo de implantação baseada em Git usando pipelines de implantação.

Com essa opção, o Git fica conectado apenas até o estágio de desenvolvimento . A partir do estágio de desenvolvimento, as implantações acontecem diretamente entre os espaços de trabalho de Dev/Test/Prod, usando pipelines de implantação de malha. Embora a ferramenta em si seja interna ao Fabric, os desenvolvedores podem usar as APIs de pipelines de implantação para orquestrar a implantação como parte de seu pipeline de lançamento do Azure ou um fluxo de trabalho do GitHub. Essas APIs permitem que a equipe crie um processo de compilação e liberação semelhante ao de outras opções, usando testes automatizados (que podem ser feitos no próprio espaço de trabalho ou antes do estágio de desenvolvimento), aprovações, etc.

Uma vez aprovado e fundido o PR para o ramo principal :

  1. Um pipeline de compilação é acionado que carrega as alterações para o estágio de desenvolvimento usando APIs do Fabric Git. Se necessário, o pipeline pode acionar outras APIs para iniciar operações/testes pós-implantação no estágio de desenvolvimento .
  2. Após a conclusão da implantação do desenvolvedor, um pipeline de liberação entra em ação para implantar as alterações do estágio de desenvolvimento para o estágio de teste. Testes automatizados e manuais devem ocorrer após a implantação, para garantir que as alterações sejam bem testadas antes de chegar à produção.
  3. Depois que os testes são concluídos e o gerenciador de versão aprova a implantação no estágio Prod , a liberação para Prod entra em ação e conclui a implantação.

Quando você deve considerar usar a opção #3?

  • Quando você estiver usando o controle do código-fonte apenas para fins de desenvolvimento e preferir implantar alterações diretamente entre os estágios do pipeline de versão.
  • Quando as regras de implantação, a vinculação automática e outras APIs disponíveis são suficientes para gerenciar as configurações entre os estágios do pipeline de versão.
  • Quando você quiser usar outras funcionalidades dos pipelines de implantação do Fabric, como exibir alterações no Fabric, histórico de implantação, etc.
  • Considere também que as implantações nos pipelines de implantação do Fabric têm uma estrutura linear e exigem outras permissões para criar e gerenciar o pipeline.

Opção 4 - CI/CD para ISVs na malha (gerenciando vários clientes/soluções)

Diagrama mostrando o fluxo de implantação baseada em Git para ISVs.

Esta opção é diferente das outras. É mais relevante para fornecedores independentes de software (ISV) que criam aplicativos SaaS para seus clientes com base na malha. Os ISVs geralmente têm um espaço de trabalho separado para cada cliente e podem ter até várias centenas ou milhares de espaços de trabalho. Quando a estrutura da análise fornecida a cada cliente é semelhante e pronta para uso, recomendamos ter um processo centralizado de desenvolvimento e teste que se divide para cada cliente apenas no estágio Prod .

Esta opção é baseada na opção #2. Uma vez aprovado e fundido o PR to principal :

  1. Um pipeline de compilação é acionado para criar um novo ambiente de compilação e executar testes de unidade para o estágio de desenvolvimento . Quando os testes são concluídos, um pipeline de liberação é acionado. Esse pipeline pode carregar o conteúdo para um ambiente de compilação, executar scripts para alterar parte da configuração, ajustar a configuração para o estágio de desenvolvimento e, em seguida, usar as APIs de definição de item de atualização do Fabric para carregar os arquivos no espaço de trabalho.
  2. Após a conclusão desse processo, incluindo a ingestão de dados e a aprovação dos gerentes de versão, os próximos pipelines de compilação e liberação para o estágio de teste podem ser iniciados. Este processo é semelhante ao descrito na primeira etapa. Para o estágio de teste , outros testes automatizados ou manuais podem ser necessários após a implantação, para validar que as alterações estão prontas para serem liberadas para o estágio Prod em alta qualidade.
  3. Quando todos os testes passarem e o processo de aprovação estiver concluído, a implantação para os clientes Prod poderá ser iniciada. Cada cliente tem sua própria versão com seus próprios parâmetros, para que sua configuração específica e conexão de dados possam ocorrer no espaço de trabalho do cliente relevante. A alteração de configuração pode ocorrer por meio de scripts em um ambiente de compilação ou usando APIs após a implantação. Todos os lançamentos podem acontecer em paralelo, pois não estão relacionados nem dependem uns dos outros.

Quando você deve considerar o uso da opção #4?

  • Você é um ISV criando aplicativos sobre o Fabric.
  • Você está usando espaços de trabalho diferentes para cada cliente para gerenciar a multilocação do seu aplicativo
  • Para mais separação, ou para testes específicos para clientes diferentes, você pode querer ter multilocação em estágios anteriores de desenvolvimento ou teste. Nesse caso, considere que, com a multilocação, o número de espaços de trabalho necessários cresce significativamente.

Resumo

Este artigo resume as principais opções de CI/CD para uma equipe que deseja criar um processo automatizado de CI/CD no Fabric. Embora delineemos quatro opções, as restrições da vida real e a arquitetura da solução podem se prestar a opções híbridas ou completamente diferentes. Você pode usar este artigo para guiá-lo através de diferentes opções e como criá-las, mas você não é forçado a escolher apenas uma das opções.

Alguns cenários ou itens específicos podem ter limitações em vigor que podem impedi-lo de adotar qualquer um desses cenários.

O mesmo vale para ferramentas. Embora mencionemos diferentes ferramentas aqui, você pode escolher outras ferramentas que podem fornecer o mesmo nível de funcionalidade. Considere que o Fabric tem melhor integração com algumas ferramentas, portanto, escolher outras resulta em mais limitações que precisam de soluções alternativas diferentes.

Conteúdos relacionados