Decompor seus metadados

Objetivos de aprendizagem

Após concluir esta unidade, você estará apto a:
  • Descrever como os clientes empresariais usam os pacotes desbloqueados com o Salesforce DX.
  • Descrever as diferenças entre o desenvolvimento com pacotes e o desenvolvimento com conjuntos de alterações.
  • Descrever como implantar metadados usando pacotes.
  • Fazer uma lista com os prós e contras dos pacotes desbloqueados.

Por que o desenvolvimento com pacotes é o futuro

Se você terminou o módulo Modelo de desenvolvimento com pacotes, sabe que o desenvolvimento modular baseado em pacotes é uma revolução. Mas talvez esteja pensando: como colocar em prática esses princípios? Como o modelo modular facilita a minha vida?

Novato na plataforma ou veterano experiente, o empacotamento é ideal para você. Sim, isso mesmo! Agora o empacotamento não serve só para os parceiros ou ISVs.

Sendo um cliente de longa data, você desenvolveu aplicativos e personalizações na plataforma para várias versões. Quanto mais você personaliza e desenvolve na plataforma, mais complexidade produz na sua organização. Sua organização do Salesforce se tornou um enorme contêiner com todos os metadados que você gerencia e com os quais interage. Costumamos chamar essa profusão de recursos de “sopa da felicidade”.

Uma caixa cheia de sopa da felicidade, com diversas formas geométricas que representam diversos metadados relacionados. Abaixo da sopa da felicidade estão 3 outras caixas de formatos diferentes, representando como você organizará seus metadados em pacotes.

Se você distribuiu recentemente as personalizações do Salesforce, você implantou metadados nas organizações de produção usando a ferramenta de migração do Salesforce, conjuntos de alterações ou até pacotes não gerenciados. Chamamos esse modelo de desenvolvimento tradicional de desenvolvimento com conjuntos de alterações (o antigo desenvolvimento baseado na organização). Em geral, seu desenvolvimento se deu dentro dos limites de um sandbox ou de uma organização de produção.

O ciclo de vida de desenvolvimento do aplicativo com conjuntos de alterações envolve mover as alterações da organização entre os ambientes de desenvolvimento e teste até que essas alterações sejam liberadas na organização de produção. No final das contas, porém, a organização de produção é a “fonte da verdade”. Mesmo que você faça o controle de alterações externo com um sistema de controle de versão, tudo reside na organização.

Mas agora há outras opções! No modelo de desenvolvimento com pacotes, a nova e melhor fonte da verdade é o seu sistema de controle de versão. Você usa os projetos do Salesforce DX para organizar essa fonte em diretórios de pacote. O objetivo final é criar pacotes usando esses diretórios, que permitem versões e são fáceis de manter, atualizar e instalar.

Dito isso, migrar para o desenvolvimento com pacotes não é uma decisão irreversível. Vamos acabar com esse mistério e mostrar como dar os primeiros passos.

O que é um pacote?

Caso ainda esteja começando a usar o empacotamento, pense no pacote como um contêiner a ser preenchido com metadados. É uma unidade distribuível de funcionalidade.

Imagine que você criou um aplicativo personalizado para seus funcionários fazerem o controle de despesas. Você incluiu objetos personalizados, classes do Apex, componentes do Lightning e muito mais. No modelo de desenvolvimento com conjuntos de alterações, todos os metadados pertencentes a esse aplicativo personalizado estão contidos em sua organização do Salesforce. No entanto, não estão isolados ou organizados de modo a facilitar a atualização e a manutenção No modelo novo, você organiza esses metadados em contêineres bem definidos chamados pacotes.

A esta altura, com certeza você não vai se surpreender quando descobrir que os motivos que mais justificam o uso de pacotes têm a ver com os metadados, ou seja, com a organização de seus metadados. Sem pacotes, pode começar a ficar difícil lidar com seus metadados do Salesforce.

Pacotes desbloqueados ao resgate

O Salesforce oferece vários tipos de pacote diferentes, cada um com suas próprias características. Por ora, vamos trabalhar com um tipo especial, o pacote desbloqueado, que é especialmente adequado para os aplicativos empresariais internos.

Os pacotes desbloqueados ajudam a adicionar, editar e remover metadados de sua organização de modo rastreável para que você possa reutilizar os componentes e atualizar os aplicativos do Salesforce de modo mais fácil e rápido. Eles encapsulam todas as alterações e atualizações aos metadados que você planeja fazer.

É claro que o aplicativo muda com o passar do tempo – e, com ele, o conteúdo do pacote. Para controlar as alterações, são criadas versões do pacote. Cada versão é um artefato imutável, um instantâneo do conteúdo do pacote.

Em sua organização de produção, é possível inspecionar quais metadados vêm de cada versão do pacote e qual é o conjunto de metadados associado à versão do pacote. Esse processo de inspeção é o mesmo para os pacotes que tenham sido instalados do AppExchange.

É o fim daquelas planilhas para controlar as alterações aos metadados. Chega de post-it!

O que é um pacote desbloqueado?

O pacote desbloqueado oferece muita flexibilidade. Seus administradores podem fazer as alterações diretamente na produção para responder a solicitações de alteração de emergência, porque os metadados nos pacotes desbloqueados podem ser modificados na organização de produção.

Embora os pacotes desbloqueados proporcionem flexibilidade para alterar diretamente a organização de produção, lembre-se: com grandes poderes vêm grandes responsabilidades. E aí, seu sentido aranha se ativou?

Os pacotes desbloqueados são controlados pelo desenvolvedor. A instalação de um novo pacote substitui as alterações feitas diretamente na organização de produção. É essencial que os administradores comuniquem à equipe de desenvolvimento todas as alterações feitas diretamente na organização de produção para que o pacote seja devidamente atualizado.

E o que podemos colocar no pacote desbloqueado? Boas notícias! É possível colocar quase todos os tipos de metadados e componentes do Salesforce no pacote desbloqueado.

O relatório de cobertura de metadados é a principal fonte da verdade de informações de cobertura de metadados entre vários canais. Esses canais incluem API de metadados, rastreamento da origem de organizações temporárias, pacotes não bloqueados, pacotes gerenciados de segunda geração, pacotes gerenciados clássicos e muito mais. Para acessar o relatório de cobertura de metadados, acesse https://developer.salesforce.com/docs/metadata-coverage.

Como começar?

Antes de irmos ao que interessa, vale a pena repetir uma informação bem importante: a adoção das novas ferramentas e princípios de desenvolvimento do Salesforce DX não é uma decisão irreversível. É possível dar passos de formiga ou se jogar de cabeça. Não vamos julgar.

Então, se você estiver pronto para ampliar seu repertório, por onde começar?
  • Se acabou de chegar ao Salesforce ou está começando um novo projeto, siga o modelo de desenvolvimento com pacotes desde o início.
  • Se for começar usando uma imensidão de recursos vindos de origens não diferenciadas, pode adotar gradualmente o empacotamento conforme começa a dividir seus metadados e organizá-los em contêineres lógicos.

É possível começar aos poucos, empacotando componentes e esquemas que talvez reutilize mais tarde em vários aplicativos. Quando chegar a hora, você pode definir dependências entre os pacotes. É você que define o ritmo da adoção e a complexidade que pode absorver.

É essa flexibilidade que define os pacotes desbloqueados.

Desenvolvimento com pacotes usando o Salesforce DX

Agora que você conhece alguns dos conceitos principais do empacotamento, vamos dar uma olhada nesse fluxo de trabalho. Para simplificar as coisas, vamos assumir que você é o único desenvolvedor e gerente de lançamento, mas outro colega trabalha com a garantia de qualidade (QA).

Para começar, crie um pacote associado a um diretório de seu projeto no Salesforce DX. Como desenvolvedor, você modifica os metadados do projeto, e as alterações vão se acumulando. Use as organizações temporárias para desenvolver e fazer testes de unidade com as alterações (1).

Como gerente de lançamento, quando estiver pronto para passar pelo QA, crie uma versão do pacote. O QA instala o pacote e começa a trabalhar. O pacote também pode ser usado para teste de unidade e CI (2). Durante esse processo, você corrige bugs, acrescenta recursos novos ou modifica os existentes. Depois, cria uma nova versão do pacote e recomeça o processo de teste de unidade (1).

É a natureza iterativa do modelo de desenvolvimento com pacotes.

Repita o processo com o QA até ter uma boa versão. Em seguida, instale essa versão em seu sandbox de testes de aceitação do usuário (UAT) e, eventualmente, na produção (3).

Mostra o fluxo de trabalho do pacote da esquerda para a direita. A codificação usa organizações temporárias para desenvolvimento e teste. A integração contínua usa organizações temporárias para o teste de unidade. O envio contínuo usa sandboxes de desenvolvedor e parciais para criação e UAT. A liberação usa Full Sandboxes para o teste final antes de liberar para a produção.

Instalar a versão do pacote se assemelha a implantar metadados. É possível instalar uma versão do pacote em qualquer organização, seja ela temporária, sandbox ou de produção. É como implantar um conjunto de metadados.

É isso aí! Agora você conhece o ciclo de vida básico do aplicativo no modelo de desenvolvimento com pacotes.

Agora que você já liberou seu primeiro pacote

No mundo da alta tecnologia e do desenvolvimento de software, nunca sobra muito tempo para ficar acomodado. A próxima versão costuma ser terrivelmente enorme. Mais uma vez, é hora de vestir a capa e a máscara para voltar ao trabalho e desenvolver novos recursos e personalizações. E mais uma nova versão do pacote.

É possível criar todas as novas versões necessárias enquanto você altera, adiciona ou remove metadados do pacote. Cada versão do pacote tem seu próprio número (por exemplo, 1.3.0.2), e você pode usar uma atualização de pacote para aplicar essas alterações à versão do pacote instalada.

Esse processo, modificar metadados → criar versão do pacote → testar versão do pacote → implantar na produção, pode ser feito quantas vezes forem necessárias.

Pronto para tentar? Vamos criar seu primeiro pacote desbloqueado.