Práticas recomendadas do gerenciamento do ciclo de vida
Este artigo fornece diretrizes para os criadores de dados e análises que vão gerenciar o 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 do código-fonte e pipelines de implantação como uma ferramenta de lançamento. Para obter uma orientação geral sobre a publicação de conteúdo empresarial, Publicação de conteúdo Enterprise.
Importante
Esse recurso está em versão prévia.
Este artigo é dividido em quatro partes:
Preparação de conteúdo – Prepare seu conteúdo para o gerenciamento do ciclo de vida.
Desenvolvimento – Saiba quais as melhores formas de criar conteúdo no estágio de desenvolvimento de pipelines de implantação.
Teste – entenda como usar um estágio de teste da implantação de pipelines 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.
Preparação de conteúdo
Para preparar melhor seu conteúdo para o gerenciamento em andamento em todo o ciclo de vida, examine as informações nesta seção antes de:
Libere o conteúdo para produção.
Comece usando um pipeline de implantação para um workspace específico.
Separar o desenvolvimento entre as equipes
Equipes diferentes na organização geralmente têm experiência, propriedade e métodos de trabalho diferentes, mesmo quando trabalham no mesmo projeto. É importante estabelecer limites, dando ao mesmo tempo a cada equipe sua independência para trabalhar como quiser. Considere ter workspaces separados para equipes diferentes. Com workspaces separados, cada equipe pode ter permissões diferentes, trabalhar com repositórios de controle do código-fonte diferentes e enviar conteúdo para produção em uma cadência diferente. A maioria dos itens pode se conectar e usar dados entre workspaces, de modo que isso não bloqueia a colaboração nos mesmos dados e projeto.
Criar seu modelo de permissão
Tanto a integração do Git quanto os pipelines de implantação exigem permissões diferentes apenas das permissões do espaço de trabalho. Leia sobre os requisitos de permissão para integração do Git e pipelines de implantação.
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 do Git quanto os estágios de desenvolvimento/teste/produção em um pipeline. Algumas considerações:
Quem deve ter acesso ao código-fonte no repositório do Git?
Quais operações os usuários com acesso ao pipeline podem executar em cada estágio?
Quem está revisando o conteúdo no estágio de teste?
Os revisores do estágio de teste devem ter acesso ao pipeline?
Quem deve supervisionar a implantação no estágio de produção?
Qual workspace você está atribuindo a um pipeline ou se conectando ao Git?
A qual branch você está conectando o workspace? Qual é a política definida para esse branch?
O workspace é compartilhado por vários membros da equipe? Eles devem fazer alterações diretamente no workspace ou apenas por meio de solicitações de pull?
A qual estágio você está atribuindo seu workspace?
Você precisa alterar as permissões do workspace que está atribuindo?
Conectar diferentes estágios a diferentes bancos de dados
Um banco de dados de produção deve estar sempre estável e disponível. É melhor não sobrecarregá-lo com consultas feitas por criadores de BI para seus modelos semânticos de teste ou desenvolvimento. Crie bancos de dados separados para desenvolvimento e testes para 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.
Usar parâmetros para configurações que serão alteradas entre estágios
Sempre que possível, adicione parâmetros a qualquer definição que possa ser alterada entre estágios de desenvolvimento/teste/produção. 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 dão suporte a qualquer tipo de parametrização.
Os parâmetros têm usos diferentes, como definir conexões com fontes de dados ou itens internos no Fabric. Eles também podem ser usados para fazer alterações em consultas, filtros e o 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.
Desenvolvimento
Esta seção fornece orientação para trabalhar com os pipelines de implantação e para uso adequado ao seu estágio de desenvolvimento.
Faça backup do seu trabalho em um repositório do Git
Com a integração do Git, qualquer desenvolvedor pode fazer backup de seu trabalho confirmando-o no Git. Para fazer backup do seu trabalho corretamente no Fabric, há algumas regras básicas:
Verifique se você tem um ambiente isolado no qual trabalhar, para que outras pessoas não substituam seu trabalho antes que ele seja confirmado. Isso representa trabalhar em uma ferramenta de área de trabalho (como VS Code, Power BI Desktop ou outras) ou em um espaço de trabalho separado que outros usuários não podem acessar.
Confirme com um branch que você criou e nenhum outro desenvolvedor está usando. Se você estiver usando um workspace como um ambiente de criação, leia sobre como trabalhar com branches.
Confirme as alterações que devem ser implantadas juntas. Essa orientação se aplica a um único item ou a vários itens relacionados à mesma alteração. Confirmar todas as alterações relacionadas em conjunto pode ajudá-lo mais tarde ao implantar em outros estágios, criar solicitações de pull ou reverter as alterações.
Grandes commits podem atingir um limite máximo de tamanho de confirmação. Lembre-se do número de itens que você confirma juntos ou do tamanho geral de um item. Por exemplo, os relatórios podem ficar grandes ao adicionar imagens grandes. É uma prática ruim armazenar itens de grande tamanho em sistemas de controle do código-fonte, 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 seu trabalho, pode haver casos em que você deseja reverter para uma versão anterior e restaurá-lo no workspace. 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 sejam confirmadas. Você também pode desfazer cada item separadamente. Leia mais sobre a operação desfazer.
Reversão para commits mais antigos: não há nenhuma maneira direta de voltar para um commit anterior na interface do usuário. A melhor opção é promover um commit mais antigo para ser o HEAD usando git reverter ou git reset. Isso mostra que há uma atualização no painel de controle do código-fonte e você pode atualizar o workspace com essa nova confirmação.
Como os dados não são armazenados no Git, considere que reverter um item de dados para uma versão mais antiga pode interromper os dados existentes e pode exigir que você descarte os dados ou a operação pode falhar. Verifique isso com antecedência antes de reverter as alterações.
Como trabalhar com um workspace "privado"
Quando você quiser trabalhar isoladamente, use um workspace separado como um ambiente isolado. Leia mais sobre como isolar seu ambiente de trabalho em como trabalhar com branches. Para obter um fluxo de trabalho ideal para você e a equipe, considere os seguintes pontos:
Configurando o workspace: antes de começar, verifique se você pode criar um novo workspace (se ainda não tiver um), que você pode atribuí-lo a uma capacidade do Fabric e se você tem acesso aos dados para trabalhar em seu workspace.
Criar um branch: crie um branch com base no branch principal, para que você tenha a versão mais atualizada do conteúdo. Conecte também a pasta correta no branch, para que você possa efetuar pull do conteúdo certo para o workspace.
Alterações 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, atualize seu branch de 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 workspace para que isso o ajude a trabalhar de forma mais produtiva. Algumas alterações podem incluir conexão entre itens ou a diferentes fontes de dados ou alterações em parâmetros em um determinado item. Lembre-se de que tudo o que você confirmar fará parte do commit e pode ser mesclado acidentalmente no branch principal.
Usar ferramentas de cliente para editar seu trabalho
Para itens e ferramentas que dão 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, o VSCode para Notebooks, etc. Essas ferramentas podem ser o seu ambiente de desenvolvimento local. Depois de concluir o trabalho, envie as alterações por push para o repositório remoto e sincronize o workspace para carregar as alterações. Apenas verifique se você está trabalhando com a estrutura com suporte do item que está criando. Se você não tiver certeza, primeiro clone um repositório com conteúdo já sincronizado com um workspace e comece a criar a partir daí, onde a estrutura já está em vigor.
Gerenciando workspaces e branches
Como um workspace só pode ser conectado a um branch por vez, é recomendável tratar isso como um mapeamento 1:1. No entanto, para reduzir a quantidade de workspace que ele envolve, considere estas opções:
Se um desenvolvedor configurar um workspace privado com todas as configurações necessárias, ele poderá continuar a usar esse workspace para qualquer branch futuro criado. Quando um sprint terminar, as alterações serão mescladas e você iniciará uma nova tarefa, basta alternar a conexão para um novo branch no mesmo workspace. Você também pode fazer isso se, de repente, precisar corrigir um bug no meio de um sprint. Pense nisso como um diretório de trabalho na Web.
Os desenvolvedores que usam uma ferramenta de cliente (como VS Code, Power BI Desktop ou outras), não precisam necessariamente de um workspace. Eles podem criar branches e confirmar alterações a esses branches localmente, efetuar push deles para o repositório remoto e criar uma solicitação de pull para o branch principal, tudo sem um workspace. Um workspace é 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 a logicalId para algo exclusivo para esse espaço de trabalho conectado.
- Altere o nome de exibição para diferenciá-lo do item original e evitar um erro de nome de exibição duplicado.
- Se necessário, atualize a logicalId e/ou exiba nomes em qualquer dependência.
Teste
Esta seção fornece orientações para trabalhar com um estágio de teste dos pipelines de implantação.
Simular seu ambiente de produção
É importante ver como sua mudança afetará a fase de produção. Um estágio de teste dos 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 workspace.
Garanta que estes três fatores sejam abordados em seu ambiente de teste:
Volume de dados
Volume de uso
Uma capacidade semelhante à de produção
Durante o teste, 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, experimente usar outra capacidade com recursos semelhantes à capacidade de produção. Para evitar custos extras, use uma capacidade que permita pagar apenas pelo tempo de teste.
Usar regras de implantação com uma fonte de dados real
Se você estiver usando a fase 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. Já o banco de dados de teste deve ser o mais semelhante possível ao 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 por meio 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 daqueles que foram atualizados.
Você pode localizar 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 workspace, estamos importando a definição dele para o workspace e aplicando-a aos dados existentes. A operação de atualização de itens de dados é a mesma para pipelines de implantação e Git.
Como diferentes itens têm recursos diferentes quando se trata de reter dados quando as alterações na definição são aplicadas, esteja atento ao aplicar as alterações. Algumas práticas que podem ajudá-lo a aplicar as alterações da maneira mais segura:
Saiba com antecedência quais são as alterações e qual pode ser o impacto delas 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 os dados de teste, carregue as alterações primeiro em um ambiente de desenvolvimento ou teste.
Se tudo correr bem, é recomendável também verificá-lo em um ambiente de preparo, com dados da vida real (ou o mais próximo possível), para minimizar comportamentos inesperados na produção.
Considere o melhor momento ao atualizar o ambiente de produção para minimizar os danos que quaisquer erros podem causar aos usuários comerciais que consomem os dados.
Após a implantação, testes pós-implantação na produção para verificar se tudo está funcionando conforme o esperado.
Algumas alterações sempre serão consideradas alterações interruptivas. Esperamos que as etapas anteriores o ajudem a rastreá-los antes da produção. Crie um plano de como aplicar as alterações à produção e recuperar os dados para voltar ao estado normal e minimizar o tempo de inatividade para os usuários comerciais.
Testar seu aplicativo
Se você estiver distribuindo conteúdo para os clientes por meio de um aplicativo, examine a nova versão do aplicativo antes que esteja em produção. Como cada estágio do pipeline de implantação tem um workspace próprio, você pode publicar e atualizar aplicativos facilmente para os estágios de desenvolvimento e de teste. Publicar e atualizar aplicativos permite testar 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 alterar o conteúdo ou as configurações, atualize manualmente o aplicativo no estágio do pipeline necessário.
Produção
Esta seção fornece orientações para o estágio de produção dos pipelines de implantação.
Gerenciar quem pode fazer implantações na produção
Como a implantação na produção deve ser tratada com cuidado, é recomendável que apenas pessoas específicas gerenciem essa operação delicada. Porém, provavelmente você deseja que todos os criadores do BI de um workspace específico tenham acesso ao pipeline. Use permissões de workspace de produção para gerenciar permissões de acesso. Outros usuários podem ter uma função de visualizador de espaço de trabalho de produção para ver o conteúdo no espaço de trabalho, mas não fazer alterações de pipelines de implantação ou do Git.
Além disso, limite o acesso ao repositório ou pipeline habilitando permissões apenas 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 forma poderosa de garantir que os dados na produção estejam sempre conectados e disponíveis para os usuários. Após a aplicação das regras de implantação, as implantações poderão ser feitas. Você terá a garantia de que os clientes poderão ver as informações relevantes sem problemas.
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 na produção, de modo que os usuários finais possam usar imediatamente a versão mais recente.
Implantando em produção usando GIT branches
Como o repositório serve como "fonte única de 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:
É recomendável usar branches de versão. Você precisa alterar continuamente a conexão do workspace com os novos branches de lançamento antes de cada implantação.
Se o pipeline de build ou lançamento exigir que você altere o código-fonte ou execute scripts em um ambiente de build antes da implantação no espaço de trabalho, conectar o espaço de trabalho ao Git não ajudará você.
Depois de implantar em cada estágio, altere toda a configuração específica para o respectivo estágio.
Correções rápidas no conteúdo
Às vezes, há problemas na produção que exigem uma correção rápida. A implantação de uma correção sem testá-la primeiro é uma prática inadequada. Portanto, sempre implemente a correção no estágio de desenvolvimento e envie-a por push 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. Implantá-la no pipeline leva só alguns minutos.
Se você está usando a implantação do Git, recomendamos seguir as práticas descritas em Adotar uma estratégia de branch do Git.
Conteúdo relacionado
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de