Práticas recomendadas para gerenciamento do ciclo de vida no Fabric
Este artigo fornece orientação para criadores de dados e análises que estão gerenciando seu conteúdo durante todo o seu ciclo de vida no Microsoft Fabric. O artigo se concentra no uso da integração do Git para controle de origem e pipelines de implantação como uma ferramenta de lançamento. Para obter uma orientação geral sobre publicação de conteúdo corporativo, publicação de conteúdo corporativo.
O artigo está dividido em quatro secções:
Preparação de conteúdo - Prepare seu conteúdo para o gerenciamento do ciclo de vida.
Desenvolvimento - Saiba mais sobre as melhores maneiras de criar conteúdo no estágio de desenvolvimento de pipelines de implantação.
Teste - Entenda como usar um estágio de teste de pipelines de implantação para testar seu ambiente.
Produção - Utilize um estágio de produção de pipelines de implantação para disponibilizar seu conteúdo para consumo.
Práticas recomendadas para preparação de conteúdo
Para preparar melhor seu conteúdo para o gerenciamento contínuo durante todo o seu ciclo de vida, revise as informações nesta seção antes de você:
Libere o conteúdo para a produção.
Comece a usar um pipeline de implantação para um espaço de trabalho específico.
Desenvolvimento separado entre equipas
Equipes diferentes na organização geralmente têm conhecimentos, propriedade e métodos de trabalho diferentes, mesmo quando trabalham no mesmo projeto. É importante estabelecer limites, dando a cada equipa a sua independência para trabalhar como quiser. Considere ter espaços de trabalho separados para equipes diferentes. Com espaços de trabalho separados, cada equipe pode ter permissões diferentes, trabalhar com repositórios de controle de origem diferentes e enviar conteúdo para produção em uma cadência diferente. A maioria dos itens pode se conectar e usar dados entre espaços de trabalho, portanto, não bloqueia a colaboração nos mesmos dados e projeto.
Planeje seu modelo de permissão
Tanto a integração quanto os pipelines de implantação do Git exigem permissões diferentes das permissões do espaço de trabalho. Leia sobre os requisitos de permissão para pipelines de integração e implantação do Git.
Para implementar um fluxo de trabalho seguro e fácil, planeje quem obtém acesso a cada parte dos ambientes que estão sendo usados, tanto o repositório Git quanto os estágios de desenvolvimento/teste/prod em um pipeline. Algumas das considerações a ter em conta são:
Quem deve ter acesso ao código-fonte no repositório Git?
Quais operações os usuários com acesso ao pipeline devem ser capazes de realizar em cada estágio?
Quem está revisando o conteúdo na etapa de teste?
Os revisores da fase de teste devem ter acesso ao pipeline?
Quem deve supervisionar a implantação no estágio de produção?
Qual espaço de trabalho você está atribuindo a um pipeline ou conectando-se ao git?
A qual ramificação você está conectando o espaço de trabalho? Qual é a política definida para esse ramo?
O espaço de trabalho é compartilhado por vários membros da equipe? Eles devem fazer alterações diretamente no espaço de trabalho ou apenas por meio de solicitações Pull?
A que fase está a atribuir o seu espaço de trabalho?
Você precisa fazer alterações nas permissões do espaço de trabalho que está atribuindo?
Conecte diferentes estágios a diferentes bancos de dados
Uma base de dados de produção deve estar sempre estável e disponível. É melhor não sobrecarregá-lo com consultas geradas por criadores de BI para seu desenvolvimento ou modelos semânticos de teste. Crie bancos de dados separados para desenvolvimento e teste, a fim de proteger os dados de produção e não sobrecarregar o banco de dados de desenvolvimento com todo o volume de dados de produção.
Use parâmetros para configurações que serão alteradas entre os estágios
Sempre que possível, adicione parâmetros a qualquer definição que possa mudar entre os estágios dev/test/prod. O uso de parâmetros ajuda a alterar as definições facilmente quando você move suas alterações para a produção. Embora ainda não haja uma maneira unificada de gerenciar parâmetros no Fabric, recomendamos usá-lo em itens que ofereçam suporte a qualquer tipo de parametrização.
Os parâmetros têm usos diferentes, como a definição de conexões com fontes de dados ou com itens internos no Fabric. Eles também podem ser usados para fazer alterações em consultas, filtros e no texto exibido aos usuários.
Em pipelines de implantação, você pode configurar regras de parâmetro para definir valores diferentes para cada estágio de implantação.
Práticas recomendadas para o estágio de desenvolvimento de pipelines de implantação
Esta seção fornece orientação para trabalhar com os pipelines de implantação e usá-los para seu estágio de desenvolvimento.
Faça backup de seu trabalho em um repositório Git
Com a integração do Git, qualquer desenvolvedor pode fazer backup de seu trabalho comprometendo-o no Git. Para fazer backup do seu trabalho corretamente no Fabric, aqui estão algumas regras básicas:
Certifique-se de ter um ambiente isolado para trabalhar, para que outros não substituam seu trabalho antes que ele seja comprometido. Isso significa trabalhar em uma ferramenta Desktop (como VS Code, Power BI Desktop ou outros) ou em um espaço de trabalho separado que outros usuários não podem acessar.
Comprometa-se com uma ramificação que você criou e nenhum outro desenvolvedor está usando. Se você estiver usando um espaço de trabalho como um ambiente de criação, leia sobre como trabalhar com ramificações.
Confirme em conjunto as alterações que devem ser implementadas em conjunto. Este conselho aplica-se a um único item ou a vários itens relacionados com a mesma alteração. Confirmar todas as alterações relacionadas juntas pode ajudá-lo mais tarde ao implantar em outros estágios, criar solicitações pull ou reverter alterações.
Grandes confirmações podem atingir um limite máximo de tamanho de confirmação. Esteja atento ao número de itens que você confirma juntos ou ao tamanho geral de um item. Por exemplo, os relatórios podem crescer muito ao adicionar imagens grandes. É uma má prática armazenar itens de tamanho grande em sistemas de controle de origem, mesmo que funcione. Considere maneiras de reduzir o tamanho de seus itens se eles tiverem muitos recursos estáticos, como imagens.
Revertendo alterações
Depois de fazer backup do trabalho, pode haver casos em que você deseja reverter para uma versão anterior e restaurá-la no espaço de trabalho. Há algumas maneiras de reverter para uma versão anterior:
Botão Desfazer: A operação Desfazer é uma maneira fácil e rápida de reverter as alterações imediatas feitas, desde que elas ainda não estejam confirmadas. Você também pode desfazer cada item separadamente. Leia mais sobre a operação de desfazer .
Reverter para confirmações mais antigas: não há uma maneira direta de voltar a uma confirmação anterior na interface do usuário. A melhor opção é promover um commit mais antigo para ser o HEAD usando git revert ou git reset. Fazer isso mostra que há uma atualização no painel de controle do código-fonte e você pode atualizar o espaço de trabalho com essa nova confirmação.
Como os dados não são armazenados no Git, lembre-se de que reverter um item de dados para uma versão mais antiga pode quebrar os dados existentes e pode exigir que você solte os dados ou a operação pode falhar. Verifique isso com antecedência antes de reverter as alterações.
Trabalhar com um espaço de trabalho "privado"
Quando quiser trabalhar isoladamente, use um espaço de trabalho separado como um ambiente isolado. Leia mais sobre como isolar seu ambiente de trabalho no trabalho com filiais. Para um fluxo de trabalho ideal para você e para a equipe, considere os seguintes pontos:
Configuração do espaço de trabalho: antes de começar, certifique-se de que pode criar um novo espaço de trabalho (se ainda não tiver um), que pode atribuí-lo a uma capacidade de malha e que tem acesso aos dados para trabalhar no seu espaço de trabalho.
Criação de uma nova ramificação: crie uma nova ramificação a partir da ramificação principal , para que você tenha a versão mais atualizada do seu conteúdo. Certifique-se também de se conectar à pasta correta na ramificação, para que você possa puxar o conteúdo correto para o espaço de trabalho.
Mudanças pequenas e frequentes: é uma prática recomendada do Git fazer pequenas alterações incrementais que são fáceis de mesclar e menos propensas a entrar em conflitos. Se isso não for possível, certifique-se de atualizar sua ramificação da principal para que você possa resolver conflitos por conta própria primeiro.
Alterações de configuração: se necessário, altere as configurações em seu espaço de trabalho para ajudá-lo a trabalhar de forma mais produtiva. Algumas alterações podem incluir conexão entre itens, ou para diferentes fontes de dados ou alterações em parâmetros em um determinado item. Lembre-se de que qualquer coisa que você cometa se torna parte da confirmação e pode ser acidentalmente mesclada no ramo principal.
Use as ferramentas do cliente para editar seu trabalho
Para itens e ferramentas que oferecem suporte a ele, pode ser mais fácil trabalhar com ferramentas de cliente para criação, como o Power BI Desktop para modelos semânticos e relatórios, VS Code para Notebooks, etc. Essas ferramentas podem ser o seu ambiente de desenvolvimento local. Depois de concluir o trabalho, envie as alterações para o repositório remoto e sincronize o espaço de trabalho para carregar as alterações. Apenas certifique-se de que está a trabalhar com a estrutura suportada do item que está a criar. Se você não tiver certeza, primeiro clone um repositório com conteúdo já sincronizado com um espaço de trabalho e, em seguida, comece a criar a partir daí, onde a estrutura já está instalada.
Gerenciando espaços de trabalho e ramificações
Como um espaço de trabalho só pode ser conectado a uma única ramificação de cada vez, é recomendável tratar isso como um mapeamento 1:1. No entanto, para reduzir a quantidade de espaço de trabalho que isso implica, considere estas opções:
Se um desenvolvedor configurar um espaço de trabalho privado com todas as configurações necessárias, ele poderá continuar a usar esse espaço de trabalho para qualquer ramificação futura que criar. Quando um sprint termina, suas alterações são mescladas e você está iniciando uma nova tarefa, basta alternar a conexão para uma nova ramificação no mesmo espaço de trabalho. Você também pode fazer isso se de repente precisar corrigir um bug no meio de um sprint. Pense nele como um diretório de trabalho na web.
Os desenvolvedores que usam uma ferramenta de cliente (como VS Code, Power BI Desktop ou outros) não precisam necessariamente de um espaço de trabalho. Eles podem criar ramificações e confirmar alterações nessa ramificação localmente, enviá-las para o repositório remoto e criar uma solicitação pull para a ramificação principal, tudo sem um espaço de trabalho. Um espaço de trabalho é necessário apenas como um ambiente de teste para verificar se tudo funciona em um cenário da vida real. Cabe a você decidir quando isso deve acontecer.
Duplicar um item em um repositório Git
Para duplicar um item em um repositório Git:
- Copie todo o diretório do item.
- Altere o logicalId para algo exclusivo para esse espaço de trabalho conectado.
- Altere o nome para exibição para diferenciá-lo do item original e evitar erro de nome de exibição duplicado.
- Se necessário, atualize o logicalId e/ou nomes de exibição em quaisquer dependências.
Práticas recomendadas para o estágio de teste de pipelines de implantação
Esta seção fornece orientação para trabalhar com um estágio de teste de pipelines de implantação.
Simule seu ambiente de produção
É importante ver como a alteração proposta afetará a etapa de produção. Um estágio de teste de pipelines de implantação permite simular um ambiente de produção real para fins de teste. Como alternativa, você pode simular isso conectando o Git a outro espaço de trabalho.
Certifique-se de que estes três fatores são abordados em seu ambiente de teste:
Volume de dados
Volume de utilização
Uma capacidade semelhante à da produção
Ao testar, você pode usar a mesma capacidade do estágio de produção. No entanto, usar a mesma capacidade pode tornar a produção instável durante o teste de carga. Para evitar uma produção instável, teste usando uma capacidade diferente em recursos semelhante à capacidade de produção. Para evitar custos adicionais, utilize uma capacidade em que possa pagar apenas pelo tempo de teste.
Usar regras de implantação com uma fonte de dados real
Se você estiver usando o estágio de teste para simular o uso de dados da vida real, é melhor separar as fontes de dados de desenvolvimento e teste. O banco de dados de desenvolvimento deve ser relativamente pequeno e o banco de dados de teste deve ser o mais semelhante possível ao banco de dados de produção. Use regras de fonte de dados para alternar fontes de dados no estágio de teste ou parametrizar a conexão se não estiver funcionando através de pipelines de implantação.
Verificar itens relacionados
As alterações feitas também podem afetar os itens dependentes. Durante o teste, verifique se as alterações não afetam ou interrompem o desempenho dos itens existentes, que podem depender dos itens atualizados.
Você pode encontrar facilmente os itens relacionados usando a análise de impacto.
Atualizando itens de dados
Itens de dados são itens que armazenam dados. A definição do item no Git define como os dados são armazenados. Ao atualizar um item no espaço de trabalho, estamos importando sua definição para o espaço de trabalho e aplicando-o nos dados existentes. A operação de atualização de itens de dados é a mesma para Git e pipelines de implantação.
Como diferentes itens têm capacidades diferentes quando se trata de reter dados quando as alterações à definição são aplicadas, esteja atento ao aplicar as alterações. Algumas práticas que podem ajudá-lo a aplicar as mudanças da forma mais segura:
Saiba com antecedência quais são as alterações e qual poderá ser o seu impacto nos dados existentes. Use mensagens de confirmação para descrever as alterações feitas.
Para ver como esse item lida com a alteração com dados de teste, carregue as alterações primeiro em um ambiente de desenvolvimento ou teste.
Se tudo correr bem, recomenda-se também verificá-lo em um ambiente de preparação, com dados da vida real (ou o mais próximo possível dele), para minimizar os comportamentos inesperados na produção.
Considere o melhor momento ao atualizar o ambiente Prod para minimizar os danos que quaisquer erros podem causar aos usuários corporativos que consomem os dados.
Após a implantação, os testes pós-implantação no Prod verificam se tudo está funcionando conforme o esperado.
Algumas alterações serão sempre consideradas alterações de rutura. Espero que as etapas anteriores ajudem você a rastreá-los antes da produção. Crie um plano de como aplicar as alterações no Prod e recupere os dados para voltar ao estado normal e minimizar o tempo de inatividade para os usuários corporativos.
Testar a sua aplicação
Se estiver a distribuir conteúdo aos seus clientes através de uma aplicação, reveja a nova versão da aplicação antes de esta entrar em produção. Como cada estágio do pipeline de implantação tem seu próprio espaço de trabalho, você pode facilmente publicar e atualizar aplicativos para estágios de desenvolvimento e teste. Publicar e atualizar aplicativos permite que você teste o aplicativo do ponto de vista de um usuário final.
Importante
O processo de implantação não inclui a atualização do conteúdo ou das configurações do aplicativo. Para aplicar alterações ao conteúdo ou às configurações, atualize manualmente o aplicativo no estágio de pipeline necessário.
Práticas recomendadas para o estágio de produção de pipelines de implantação
Esta seção fornece orientação para o estágio de produção de pipelines de implantação.
Gerenciar quem pode implantar na produção
Como a implantação na produção deve ser tratada com cuidado, é uma boa prática permitir que apenas pessoas específicas gerenciem essa operação sensível. No entanto, você provavelmente deseja que todos os criadores de BI de um espaço de trabalho específico tenham acesso ao pipeline. Use permissões de espaço de trabalho de produção para gerenciar permissões de acesso. Outros usuários podem ter uma função de visualizador do espaço de trabalho de produção para ver o conteúdo no espaço de trabalho, mas não fazer alterações no Git ou nos pipelines de implantação.
Além disso, limite o acesso ao repositório ou pipeline habilitando apenas permissões para usuários que fazem parte do processo de criação de conteúdo.
Definir regras para garantir a disponibilidade do estágio de produção
As regras de implantação são uma maneira poderosa de garantir que os dados em produção estejam sempre conectados e disponíveis para os usuários. Com as regras de implantação aplicadas, as implantações podem ser executadas enquanto você tem a garantia de que os clientes podem ver as informações relevantes sem perturbações.
Certifique-se de definir regras de implantação de produção para fontes de dados e parâmetros definidos no modelo semântico.
Atualizar o aplicativo de produção
A implantação em um pipeline por meio da interface do usuário atualiza o conteúdo do espaço de trabalho. Para atualizar o aplicativo associado, use a API de pipelines de implantação. Não é possível atualizar o aplicativo por meio da interface do usuário. Se você usa um aplicativo para distribuição de conteúdo, não se esqueça de atualizá-lo após a implantação em produção para que os usuários finais possam usar imediatamente a versão mais recente.
Implantando na produção usando ramificações do Git
Como o repositório serve como a "única fonte da verdade", algumas equipes podem querer implantar atualizações em diferentes estágios diretamente do Git. Isso é possível com a integração do Git, com algumas considerações:
Recomendamos o uso de ramificações de versão. Você precisa alterar continuamente a conexão do espaço de trabalho com as ramificações da nova versão antes de cada implantação.
Se o pipeline de compilação ou liberação exigir que você altere o código-fonte ou execute scripts em um ambiente de compilação antes da implantação no espaço de trabalho, conectar o espaço de trabalho ao Git não o ajudará.
Depois de implantar em cada estágio, certifique-se de alterar toda a configuração específica para esse estágio.
Correções rápidas para o conteúdo
Às vezes, há problemas na produção que exigem uma solução rápida. Implantar uma correção sem testá-la primeiro é uma má prática. Portanto, sempre implemente a correção no estágio de desenvolvimento e envie-a para o restante dos estágios do pipeline de implantação. A implantação no estágio de desenvolvimento permite verificar se a correção funciona antes de implantá-la na produção. A implantação em todo o pipeline leva apenas alguns minutos.
Se você estiver usando a implantação do Git, recomendamos seguir as práticas descritas em Adotar uma estratégia de ramificação do Git.