Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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 construir um processo CI/CD usando as opções deste artigo, precisa de:
Um espaço de trabalho Fabric (tens de ser administrador de espaço de trabalho para configurar a implementação)
Para opções baseadas em Git (1, 2 e 4), um fornecedor Git suportado (Azure DevOps ou GitHub) ligava-se através da integração com Git
Note
A opção 3 utiliza os pipelines de implementação do Fabric. Para usar essa opção, também precisa de acesso à funcionalidade pipelines de implementação e permissão para criar e gerir um pipeline.
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
Processo de liberação
O processo de lançamento começa assim que as novas atualizações são concluídas e o pull request (PR) é mesclado na ramificação compartilhada da equipa (como Main, Dev, etc.). A partir desse ponto, há diferentes opções para criar um processo de liberação no Fabric.
A tabela seguinte resume as opções para o ajudar a escolher. Muitas equipas combinam mais do que uma.
| Option | Fonte da verdade | Estratégia de ramificação | Mecanismo de implantação | Configuração por fase | Melhor para |
|---|---|---|---|---|---|
| 1 - Integração com Git | Git | Gitflow (um ramo primário por etapa) |
APIs do Fabric Git (update-from-git) |
Ramificações separadas por etapa | Equipas que querem o Git como a única fonte de verdade e seguem o Gitflow |
| 2 - APIs de Fabric Items | Git (ramo principal único)¹ | Baseado em tronco | APIs de Itens do Fabric (fabric-cicd ou API de Definições de Itens para Importação em Massa) | Scripts de ambiente de construção | Equipas baseadas em trunks que precisam de transformar definições de itens antes da implementação |
| 3 - Pipelines de implementação | Área de trabalho do Fabric (Git apenas através de dev) | Baseado em tronco | APIs de pipelines de implementação | Regras de implementação e associação automática | Equipas que preferem uma implementação nativa do Fabric e de baixo código entre espaços de trabalho |
| 4 - CI/CD para ISVs | Git (ramo principal único) | Baseado em tronco | APIs de Fabric Items (por espaço de trabalho do cliente) | Parâmetros de lançamento por cliente | ISVs que gerem muitos espaços de trabalho por cliente |
¹ Na Opção 2, os espaços de trabalho da fase de preparação (incluindo Test e Prod) não estão associados ao Git. As definições de itens são enviadas para eles através das APIs Fabric Items a partir do ramo principal.
Opção 1 - Implementações baseadas em definição usando integração com 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 integrado:
- Uma canalização de lançamento atualiza o conteúdo do espaço de trabalho Dev. Este processo pode também incluir um pipeline de compilação para executar testes unitários, mas o carregamento real dos ficheiros vem diretamente do repositório para o espaço de trabalho, usando APIs Fabric Git. Pode precisar de chamar outras APIs do Fabric para operações pós-implementação que definam configurações específicas para este workspace ou para ingerir dados. Algumas dependências de itens vinculam-se automaticamente através de IDs lógicos quando sincronizadas com um novo espaço de trabalho, enquanto outras requerem estas atualizações pós-implantação. Para mais detalhes, consulte Compreender a associação de dependências na implementação entre áreas de trabalho.
- Um PR é então criado para a branch 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.
- 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.
- Um PR é criado para a ramificação Prod , usando um processo semelhante ao descrito na etapa #2.
- Outro pipeline de compilação e lançamento é acionado para atualizar o espaço de trabalho de produção, 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 a sua equipa segue Gitflow como estratégia de ramificação, incluindo várias ramificações principais.
- 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 - Implementações baseadas em definições usando APIs Fabric Items
Com esta opção, todas as implementações vêm do mesmo ramo do repositório Git (Main). Cada fase do pipeline de lançamento tem o seu próprio pipeline de compilação e de lançamento. Estes pipelines podem usar um ambiente de compilação para executar testes unitários e scripts que alteram algumas das definições dos itens antes de serem carregados para o 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. Nem todas as dependências de itens requerem estas alterações – algumas vinculam-se automaticamente através de IDs lógicos quando implementadas num novo espaço de trabalho. Para perceber quais as dependências que se vinculam automaticamente e quais necessitam de parametrização manual, consulte Compreender a ligação de dependências na implementação cross-workspace.
Assim que um PR para a ramificação de desenvolvimento é aprovado e integrado:
- Um pipeline de compilação é acionado para criar um novo Build environment 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.
- 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 .
- 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 qualquer nova ingestão de dados, baseada na alteração, para minimizar a potencial indisponibilidade para os consumidores.
Que componentes podem ser usados para implementar a opção #2?
- Fabric-cicd - uma biblioteca Python concebida para utilização com espaços de trabalho Fabric. Esta biblioteca suporta automações de Integração Contínua / Implantação Contínua (CI/CD) baseadas no código para integrar de forma fluida os espaços de trabalho num framework de implementação. Para um exemplo completo de ponta a ponta, siga o nosso tutorial de fabric-cicd e Azure DevOps.
- API de Importação em Massa de Definições de Itens - A API suporta tanto a criação de novos itens como a atualização dos existentes, baseando-se no tratamento de dependências incorporado do Fabric para garantir que os itens sejam implantados na ordem correta. Isto permite implementações consistentes e repetíveis em ambientes de teste e produção sem intervenção manual. Para um tutorial de exemplo, siga o nosso CI/CD Fabric com API de Importação em Massa de Definições de Itens.
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 do Fabric
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 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 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 :
- 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 .
- Após a conclusão da implantação do dev, um pipeline de lançamento entra em ação para implantar as alterações do estágio dev para o estágio 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.
- Depois de concluídos os testes e o gestor de lançamento aprovar a implementação no estágio Prod, o lançamento para Prod é iniciado e conclui a implementaçã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 no Fabric (gerindo vários clientes/soluções)
Esta opção é diferente das outras. É mais relevante para fornecedores independentes de software (ISV) que criam aplicações SaaS para os seus clientes com base no 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 as estruturas de análise fornecidas a cada cliente são semelhantes e out-of-the-box, recomendamos ter um processo centralizado de desenvolvimento e teste que é distribuído a cada cliente apenas no estágio de Produção Prod.
Esta opção é baseada na opção #2. Uma vez aprovado e mesclado o PR para principal :
- 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 Build, 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 Atualização da Definição de Item do Fabric para carregar os arquivos no Workspace.
- 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.
- 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 o equipamento. 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.