Compartilhar via

Escolha a melhor opção de fluxo de trabalho de CI/CD do Fabric 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 concentrará mais na CD (implantação contínua) do processo de CI/CD. Para obter uma discussão sobre a parte de CI (integração contínua), consulte Gerenciar ramificações do Git.

Embora este artigo delineia várias opções distintas, muitas organizações adotarão uma abordagem híbrida.

Pré-requisitos

Para acessar o recurso dos 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 é independente de como lançar novas atualizações em produção. Quando os desenvolvedores trabalham com o controle do código-fonte, eles precisam trabalhar em um ambiente isolado. No Fabric, esse ambiente pode ser um IDE em seu computador local (como o Power BI Desktop ou o VS Code) ou um espaço de trabalho diferente no Fabric. Encontre informações sobre as diferentes considerações para o processo de desenvolvimento em Gerenciar ramificações do Git

Diagrama mostrando como o processo de desenvolvimento funciona.

Processo de liberação

O processo de versão é iniciado quando novas atualizações são concluídas e o PR (pull request) mesclado na ramificação compartilhada da equipe (como Principal, Desenvolvimento etc.). A partir deste ponto, existem diferentes opções para criar um processo de lançamento no Fabric.

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

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

Com essa opção, todas as implantações se originam do repositório do Git. Cada estágio no pipeline de lançamento tem um ramificação primária dedicada (no diagrama, esses estágios são Desenvolvimento, Teste e Produção), que alimenta o espaço de trabalho apropriado no Fabric.

Após um PR para a ramificação de Desenvolvimento ser aprovado e mesclado:

  1. Um pipeline de lançamento é disparado 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 upload real de arquivos é feito diretamente do repositório para o espaço de trabalho, usando APIs do Git do Fabric. Talvez seja necessário chamar outras APIs do Fabric para operações pós-implantação que definem configurações específicas para esse espaço de trabalho ou ingerir dados.
  2. Em seguida, um PR é criado para a ramificação de teste. Na maioria dos casos, o PR é criado usando uma ramificação de versão que pode escolher o conteúdo para passar para o próximo estágio. O PR 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 Lançamento é disparado para atualizar o espaço de trabalho de teste, usando um processo semelhante ao descrito na primeira etapa.
  4. Um PR é criado para a ramificação de Produção, usando um processo semelhante ao descrito na etapa nº 2.
  5. Outro pipeline de Compilação e Lançamento é disparado para atualizar o espaço de trabalho do Produção, usando um processo semelhante ao descrito na primeira etapa.

Quando você deve considerar usar a opção nº 1?

  • Ao querer usar o repositório do 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ê poderá 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 se originam da mesma ramificação do repositório do Git (Principal). Cada estágio no pipeline de lançamento tem um pipeline de Compilação e Lançamento dedicados. 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.

Após um PR para a ramificação de desenvolvimento ser aprovado e mesclado:

  1. Um pipeline de compilação é disparado para criar um novo ambiente de Compilação e executar testes de unidade para o estágio de desenvolvimento. Em seguida, um pipeline de lançamento é disparado 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 for concluído, inclusive a ingestão de dados e a aprovação dos gerentes de lançamento, os próximos pipelines de compilação e lançamento para o estágio de teste poderão ser criados. Esses estágios são criados 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 se as alterações estão prontas para serem lançadas no estágio Produção.
  3. Quando todos os testes automatizados e manuais são concluídos, o gerenciador de lançamento pode aprovar e iniciar os pipelines de compilação e lançamento no estágio de Produção. Como o estágio de Produção 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 disparar mais ingestão de dados, com base na alteração, para minimizar a potencial não disponibilidade para os consumidores.

Quando você deve considerar usar a opção nº 2?

  • Ao querer 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.
  • É necessário 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.
  • É necessário um pipeline de lançamento (script personalizado) para recuperar o conteúdo do item do Git e chamar a API de Item do Fabric correspondente para criar, atualizar ou excluir itens modificados do Fabric.

Opção 3 – Implantar usando pipelines de implantação do Fabric

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

Com essa opção, o Git está conectado somente até o estágio de desenvolvimento. No estágio de desenvolvimento, as implantações ocorrem diretamente entre os espaços de trabalho de Desenvolvimento/Teste/Produção, usando pipelines de implantação do Fabric. 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 de um fluxo de trabalho do GitHub. Essas APIs permitem que a equipe crie um processo de compilação e lançamento semelhante como em 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.

Após o PR para a ramificação principal ser aprovado e mesclado:

  1. Um pipeline de compilação é disparado que carrega as alterações no estágio de desenvolvimento usando APIs do Git do Fabric. Se necessário, o pipeline pode disparar 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 desenvolvimento, um pipeline de lançamento inicia para implantar as alterações do estágio de desenvolvimento para o estágio de teste. Os testes automatizados e manuais devem ocorrer após a implantação, para garantir que as alterações sejam bem testadas antes de atingir a produção.
  3. Depois que os testes são concluídos e o gerenciador de lançamento aprova a implantação no estágio de Produção, a versão da Produção inicia e conclui a implantação.

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

  • Ao estar 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 lançamento.
  • 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 lançamento.
  • Ao querer usar outras funcionalidades de 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 em 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 no Fabric (gerenciando vários clientes/soluções)

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

Essa opção é diferente das outras. É mais relevante para ISV (Fornecedores Independentes de Software) que criam aplicativos SaaS para seus clientes sobre o Fabric. 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, é recomendável ter um processo centralizado de desenvolvimento e teste que se divide para cada cliente apenas no estágio de Produção.

Essa opção é baseada na opção nº 2. Após o PR para o principal ser aprovado e mesclado:

  1. Um pipeline de compilação é disparado 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 lançamento é disparado. Esse pipeline pode 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, 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 concluir esse processo, inclusive a ingestão de dados e a aprovação dos gerentes de lançamento, os próximos pipelines de compilação e lançamento para o estágio de teste poderão começar. Esse 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 se as alterações estão prontas para serem lançadas no estágio de Produção em alta qualidade.
  3. Depois que todos os testes forem aprovados e o processo de aprovação for concluído, a implantação para clientes da Produção 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. Todas as versões podem ocorrer em paralelo, pois não estão relacionadas nem dependem umas das outras.

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

  • Você é um ISV criando aplicativos na parte superior do Fabric.
  • Você está usando espaços de trabalho diferentes para cada cliente gerenciar a multilocação do seu aplicativo
  • Para obter mais separação ou para testes específicos para clientes diferentes, talvez você queira ter vários locatários em estágios anteriores de desenvolvimento ou teste. Nesse caso, considere que, com várias locações, o número de espaços de trabalho necessários aumenta 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. Enquanto descrevemos 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. Use este artigo para guiar você por diferentes opções e como compilá-las, mas não é forçado a escolher apenas uma das opções.

Alguns cenários ou itens específicos podem ter limitações em vigor podem impedir a adoção de qualquer um desses cenários.

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

Conteúdo relacionado