Organizar seus metadados
Objetivos de aprendizagem
- Apresentar as principais estratégias para organizar em pacotes os metadados sem pacote.
- Identificar como os pacotes desbloqueados podem ser interdependentes.
- Descrever os três modelos de desenvolvimento com pacotes e quando usá-los.
Colocar em prática os princípios do desenvolvimento com pacotes
Parabéns! Na unidade anterior, você criou um pacote e instalou o aplicativo DreamHouse no Trailhead Playground. Agora, vamos mostrar como colocar em prática alguns dos princípios fundamentais do desenvolvimento com pacotes. Lembre-se: tudo bem começar aos poucos e ir ampliando conforme o que der certo.
Organizar os metadados em pacotes:
- É muitas vezes um processo iterativo.
- Não é algo irremediável.
Organizar metadados para um aplicativo personalizado novo ou existente
O DreamHouse LWC é um ótimo exemplo de como criar um novo aplicativo do zero e empacotá-lo em um pacote desbloqueado para poder introduzi-lo em sua organização e gerenciar as próximas personalizações. Mas também é possível seguir esse mesmo processo ao atualizar os recursos ou as funcionalidades de um aplicativo personalizado existente.
Para resumir, criamos o DreamHouse para mostrar como:
- Integrar os projetos e os pacotes desbloqueados da Salesforce CLI em seu ciclo de vida de aplicativo.
- Adotar as melhores práticas para organizar os metadados e criar fronteiras entre os pacotes.
- Implantar pacotes desbloqueados ao criar um novo aplicativo.
Agora que você já criou um pacote desbloqueado para o DreamHouse LWC, o que pode fazer?
- Testar e implantar a origem do aplicativo de modo independente.
- Isolar o esquema do aplicativo (objetos personalizados) de outros metadados.
- Continuar a melhorar o aplicativo ao repetir o processo e adicionar novos recursos.
- Fazer versões do aplicativo.
- Instalar uma segunda versão como atualização da versão existente.
Metadados do DreamHouse
Metadados | Descrição |
---|---|
Esquema | Inclui objetos personalizados para Broker (Corretor), Property (Propriedade) e Favorite (Favorito). Exemplos: Broker__c, Property__c, Favorite__c |
Aplicativos e componentes do Lightning | Explora as propriedades e mostra seus detalhes. Exemplos: Property_Explorer.flexipage-meta.xml, Property_Record_Page.flexipage-meta.xml |
Processos (fluxos) | Envia notificações quando propriedades novas são adicionadas ou quando o preço muda. Exemplos: Advertise_New_Property-2.flow-meta.xml, Price_Change_Push_Notification-1.flow-meta.xml |
Serviços do Einstein | Aplica o processamento de imagem para diferenciar os detalhes das casas das imagens que são carregadas. Exemplo: EinsteinVisionController.cls |
Bots | Permite que os clientes interajam por Facebook Messenger, Slack ou Alexa para buscar propriedades. Exemplo: HandlerFindProperties.cls |
Decompor os metadados existentes da sua organização
Como você pode ver, faz muito sentido usar o ciclo de vida do desenvolvimento com pacotes para os novos projetos. No entanto, sabemos que os clientes antigos, que usam o desenvolvimento com conjuntos de alterações há muitas versões ou até mesmo anos, querem saber por onde começar. Como desemaranhar os conteúdos da organização e separá-los em projetos diferentes e, por fim, em diretórios de pacotes?
Queríamos muito contar o segredo do sucesso, mas não existe um plano de ação obrigatório. A abordagem aos metadados sem pacote é metade ciência, metade arte. Você é a melhor pessoa para determinar quais trechos de metadados cabem em cada projeto do Salesforce DX.
Para começar, responda:
- Você gostaria que as equipes de desenvolvimento tivessem autonomia para liberar aplicativos, recursos novos e personalizações?
- Você pode identificar os metadados que representam um aplicativo?
- Você consegue organizar seus metadados em módulos conforme os diferentes recursos?
- Ao criar um pacote não gerenciado para esse recurso ou aplicativo, quais dependências você vê?
Se a sua organização tiver vários aplicativos e personalizações, você verá mais dependências entre os projetos do Salesforce DX.
Três modelos para desemaranhar metadados
Na vida real, provavelmente você vai adotar uma combinação dessas estratégias e adaptá-las conforme as necessidades da sua empresa.
Modelo | Descrição |
---|---|
Baseado em aplicativo | Identifica os metadados que representam um aplicativo. É uma abordagem semelhante à criação de um pacote para o aplicativo DreamHouse, exceto pelo fato de que os metadados já existem na sua organização. |
Baseado em personalizações | Organiza os metadados sem pacote conforme as personalizações e alterações nas funcionalidades em sua organização de produção, por exemplo, as personalizações no Sales Cloud, Service Cloud ou em um aplicativo do AppExchange. |
Biblioteca compartilhada | Quando há interdependências, usa um pacote comum do Salesforce DX para organizar um conjunto de classes do Apex ou objetos personalizados usados com frequência. Outros pacotes criados por você podem depender desse pacote comum. |
Use um pacote não gerenciado como ponto de partida
Eis um bom fluxo de trabalho inicial para organizar os metadados não gerenciados em vários pacotes:
- Selecione um conjunto pequeno de metadados sem pacote e contidos em si mesmos da sua organização de produção. Selecione metadados que representem um aplicativo, uma personalização em um aplicativo existente, um recurso ou unidade funcional, ou personalizações a objetos padrão.
- Crie um pacote não gerenciado para isolar os metadados que identificou no conjunto geral de metadados da organização. Conforme adicionar os metadados a ele, veja quais metadados dependentes são automaticamente inseridos pelo sistema. Essa etapa ajuda a revelar algumas dependências menos óbvias dos metadados.
- Recupere a origem do pacote não gerenciado usando project retrieve start.
- Configure um projeto do Salesforce DX e um repositório git para gerenciar os metadados do pacote.
- Coloque esses metadados em uma organização temporária usando project deploy start e valide se esses metadados são aqueles que você quer que façam parte de um pacote desbloqueado.
- Crie um pacote desbloqueado usando o indicador --no-namespace.
- Teste e implante o pacote desbloqueado.
- Depois que o pacote desbloqueado passar por todas as execuções de CI e UAT em sandboxes, promova a versão do pacote.
- Instale o pacote desbloqueado na organização de produção.
Os metadados serão movidos automaticamente para o pacote que você criar para eles. Como o nome completo da entidade identifica os metadados na organização e no pacote, nós já substituímos os metadados na organização e atualizamos as referências internas para mostrar que eles passaram a fazer parte do pacote.
Sobre as dependências do pacote
Uma das grandes vantagens dos pacotes desbloqueados é a possibilidade de desenvolver e manter um conjunto de pacotes interdependentes.
- O pacote desbloqueado pode depender de um pacote do AppExchange. Se você estiver usando um pacote do AppExchange, pode colocar sua personalização desse pacote em um pacote desbloqueado. Na hora de instalar o pacote desbloqueado, o pacote do AppExchange precisa estar presente.
- O pacote desbloqueado pode depender de outro pacote desbloqueado. Digamos que você está criando um novo aplicativo para os funcionários enviarem relatórios de despesas. Ele divide algumas funcionalidades de back-end com o aplicativo Folha de pagamento. Nesse cenário, o pacote desbloqueado do relatório de despesas dependerá do pacote desbloqueado do aplicativo Folha de pagamento.
- O pacote desbloqueado pode depender de outro pacote desbloqueado que, por sua vez, pode depender de um terceiro pacote desbloqueado. Há compatibilidade com vários níveis de dependência.
As dependências são expressas na seção packageDirectories do arquivo sfdx-project.json. Por aceitarem dependências, os pacotes desbloqueados promovem o desenvolvimento modular com uma estrutura de dependência avançada. Consulte o Guia do desenvolvedor do Salesforce DX para obter informações sobre o arquivo de configuração de projeto.