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

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 implantação contínua (CD) 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 criar um processo de CI/CD usando as opções neste artigo, você precisa:

• Uma assinatura da Fabric

• Um workspace do Fabric (você deve ser um administrador do workspace para configurar a implantação)

• Para opções baseadas em Git (1, 2 e 4), um provedor Git com suporte (Azure DevOps ou GitHub) conectado por meio da integração do Git

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

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.

A tabela a seguir resume as opções para ajudá-lo a escolher. Muitas equipes combinam mais de uma.

¹ Na Opção 2, os workspaces de estágio (incluindo Teste e Prod) não estão conectados ao Git. As definições de item são enviadas a elas por meio das APIs de itens do Fabric a partir do branch Main.

Opção 1 – Implantações baseadas em definição usando a integração do Git

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 atualiza o conteúdo do espaço de trabalho Dev. Esse processo também pode incluir um pipeline de Build para rodar testes unitários, mas o upload real dos arquivos vem diretamente do repositório para o workspace usando APIs do Fabric Git. Você pode precisar chamar outras APIs do Fabric para operações pós-implantação que definam configurações específicas para esse workspace ou para ingestão de dados. Algumas dependências de itens se vinculam automaticamente por IDs lógicos quando sincronizadas com um novo workspace, enquanto outras exigem essas atualizações pós-implantação. Para detalhes, consulte Entenda a vinculação de dependências na implantação em vários espaços de trabalho.
2. Em seguida, um PR é criado para o branch 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 o branch Prod, usando um processo semelhante ao descrito na etapa 2.
5. Outro pipeline de Build e release é disparado para atualizar o espaço de trabalho do Prod, usando um processo semelhante ao descrito na primeira etapa.

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

• Quando você deseja usar seu repositório Git como a única fonte de verdade e a origem de todas as implementaçõ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 definição usando APIs de itens de Fabric

Com essa opção, todas as implantações vêm do mesmo ramo do repositório Git (Main). Cada estágio no pipeline de lançamento tem seus próprios pipeline de compilação e pipeline de lançamento. Esses pipelines podem usar um ambiente de build para executar testes unitários e scripts que alteram algumas definições dos itens antes de serem enviados para o workspace. 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. Nem todas as dependências de itens exigem essas mudanças – algumas se vinculam automaticamente por IDs lógicos quando implantadas em um novo workspace. Para entender quais dependências se vinculam automaticamente e quais precisam de parametrização manual, veja Compreender a vinculação de dependências na implantação entre espaços de trabalho.

Após um PR para o branch dev 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 acionar uma nova ingestão de dados, baseada na alteração, para minimizar a potencial indisponibilidade para os consumidores.

Quais componentes podem ser usados para implementar a opção nº 2?

• Fabric-cicd - uma biblioteca Python projetada para uso com espaços de trabalho Fabric. Esta biblioteca oferece suporte a automações de CI/CD com abordagem code-first para integrar perfeitamente os espaços de trabalho em uma estrutura de implantação. Para obter um exemplo completo de ponta a ponta, siga nosso tutorial fabric-cicd e Azure DevOps.
• Bulk-Import-Item-Definitions-API – A API dá suporte à criação de novos itens e à atualização dos existentes em vigor, ao mesmo tempo em que depende do tratamento de dependência interno do Fabric para garantir que os itens sejam implantados na ordem correta. Isso permite implantações consistentes e repetíveis em ambientes de teste e produção sem intervenção manual. Para obter um tutorial de exemplo, siga nossa CI/CD do Fabric com a API de Definições de Itens de Importação em Massa.

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 workflow Trunk-based 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 pipelinas de implantação do Fabric

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 no dev, um pipeline de lançamento é acionado para implantar as alterações do estágio dev para o estágio test. 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 gerente de liberação aprova a implantação no estágio de Produção, a liberação para Produção é iniciada 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.
• 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 deployment pipelines do Fabric têm uma estrutura linear e exigem permissões adicionais para criar e gerenciar o pipeline.

Opção 4 – CI/CD para ISVs no Fabric (gerenciando vários clientes/soluções)

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 build é disparado para criar um novo ambiente de build e executar testes de unidade para o estágio de desenvolvimento. Quando os testes são concluídos, um release pipeline é 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 liberação, os próximos pipelines de compilação e liberação para o estágio de teste podem ser iniciados. 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 para a plataforma 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 multilocação nas etapas 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 orientá-lo sobre as diferentes opções e como construí-las, mas não é necessário escolher apenas uma delas.

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

• Gerenciar os GIT branches
• Automatizar a integração do Git com as APIs e o Azure DevOps
• Automatizar o pipeline de implantação com as APIs do Fabric
• Entenda a vinculação de dependências na implantação entre espaços de trabalho
• Melhores práticas para o gerenciamento do ciclo de vida no Fabric