Usar o desenvolvimento com pacotes para versões mais flexíveis

Objetivos de aprendizagem

Após concluir esta unidade, você estará apto a:
  • Identificar as principais diferenças entre o desenvolvimento com pacotes e o desenvolvimento com conjuntos de alterações.
  • Descrever o que é uma versão de pacote e como ela pode ajudá-lo a gerenciar as alterações em sua organização.
  • Resumir por que não é necessário rastrear alterações de configuração manualmente no caso do modelo de desenvolvimento com pacotes.

Esta unidade descreve por que Calvin e seus colegas decidiram mudar dos modelos de desenvolvimento com conjunto de alterações para o modelo de desenvolvimento com pacotes. Outras equipes podem se interessar pelo desenvolvimento com pacotes por outros motivos. Durante a leitura desta unidade, pense nas escolhas que você faria para sua equipe e quais aspectos do desenvolvimento com pacotes parecem mais interessantes. Veja o conteúdo na prática trabalhando nos módulos indicados no final deste módulo para aprender o processo e tomar as decisões mais fundamentadas em relação ao que vai funcionar para você.

Desafios de gestão de alterações envolvendo conjuntos de alterações

Depois de um tempo, a quantidade de projetos e colaboradores em cada versão para a organização de produção começa a crescer na Zephyrus. Isso é ótimo para os usuários. O uso consistente das etapas do ALM pela empresa estabelece um bom tempo de resposta para as solicitações de aprimoramento com o mínimo de perturbações.

No entanto, a coordenação dessas alterações, especialmente sendo tantas mudanças não relacionadas feitas por equipes diferentes, está virando uma dor de cabeça para Calvin. As versões continuam crescendo em tamanho e complexidade. Ele tem medo de que, dada a dificuldade em juntar e testar as alterações de todos os projetos em uma versão, alguns recursos usados pela equipe da Zephyrus sejam inviabilizados.

Com tantas alterações para coordenar e rastrear a cada versão, Calvin percebeu que era melhor gastar esse tempo fazendo as alterações. Ele também acha que as equipes que personalizam o Salesforce na Zephyrus poderiam ser mais produtivas se passassem menos tempo coordenando suas alterações com as de outros projetos.

Contêiner único ou vários contêineres?

Na Salesforce Trailblazer Community, Calvin pede ajuda a outros membros sobre como gerenciar uma grande quantidade de projetos em cada lançamento. Eles falam sobre um novo modelo de desenvolvimento do Salesforce que oferece mais flexibilidade no gerenciamento de versões. Ele se chama desenvolvimento com pacotes.

No desenvolvimento com pacotes, você gerencia personalizações diferentes como pacotes separados, não como uma grande versão de atualizações na organização. Lembra como, em um desenvolvimento com conjuntos de alterações, você gerenciou um conjunto de alterações de vários projetos como se fossem para um mesmo contêiner? Quando as versões ficam tão complexas que é melhor gerenciar a organização como vários contêineres, é hora de mudar para o modelo de desenvolvimento com pacotes. Se sua equipe já está criando artefatos de versão modulares em outras plataformas, eles verão algumas semelhanças ao trabalhar no desenvolvimento com pacotes.

Por exemplo, um pacote na Zephyrus pode conter uma das personalizações a seguir.

  • Aplicativos personalizados Force.com que eles criaram internamente
  • Extensões do Sales Cloud, do Service Cloud e outras
  • Extensões de um aplicativo AppExchange
  • Atualizações de bibliotecas compartilhadas e funções

Quando você trabalha em um modelo de desenvolvimento com pacotes, cria um artefato de versão que pode ser testado e lançado independentemente dos artefatos de outros projetos. Em vez de criar um conjunto de alterações relativas à produção, sua equipe cria um pacote que contém todos os metadados pertinentes. Os metadados no pacote incluem componentes alterados e não alterados.

A organização das atualizações de metadados em pacotes também ajuda a criar um modelo mental melhor de como os metadados em sua organização estão estruturados. Se você quer gerenciar sua organização como vários contêineres, cada pacote representa um desses contêineres.

Uma versão de pacote é um instantâneo fixo do conteúdo e dos metadados relacionados do pacote. A versão do pacote permite gerenciar o que há de diferente cada vez que você lança ou implanta um conjunto de alterações específico adicionado a um pacote. Se você está introduzindo alterações de metadados em um pacote já implantado, atualize da versão do pacote atual para a versão mais recente.

Calvin está empolgado com o potencial de ganho de produtividade na mudança para o desenvolvimento com pacotes. Ele apresenta a questão a Ernesto, CEO, e aos diretores de outros departamentos da Salesforce que fazem personalizações. Ele se concentra em três pontos principais.

  • Criar uma trilha de auditoria clara de como os metadados da organização mudaram ao longo do tempo
  • Aumentar a produtividade liberando tempo gasto atualmente com o acompanhamento de alterações de configuração
  • Ganhar maior flexibilidade nas versões, pois cada pacote pode ser desenvolvido, testado e lançado independentemente dos pacotes de outros projetos

Os metadados na origem são sua fonte confiável

No desenvolvimento com pacotes, os metadados no projeto do pacote são sua fonte confiável. Isso facilita a integração com um VCS que possa ajudar sua equipe a gerenciar as alterações feitas no projeto.

No desenvolvimento com conjunto de alterações, a fonte confiável é uma combinação entre os metadados já no ambiente e a compilação mais recente do conjunto de alterações. Isoladamente, um conjunto de alterações não pode apresentar o panorama completo, pois ele contém apenas as alterações, como um diff.

Diga adeus ao rastreamento manual de alterações de configuração

Existe um ambiente de desenvolvimento no desenvolvimento com pacotes chamado organizações temporárias. As organizações temporárias têm um papel-chave na redução significativa das alterações que Calvin e sua equipe precisam rastrear em cada versão.

Organizações temporárias são organizações vazias (sem dados ou metadados) fáceis de criar e descartar conforme a necessidade. É possível configurar as organizações temporárias para serem edições diferentes do Salesforce com recursos e preferências diferentes. E mais: você pode reutilizar e compartilhar o arquivo de definição da organização temporária com outros membros da equipe, já que é parte do projeto integrado no VCS. Assim fica muito mais simples todos trabalharem na configuração de uma mesma organização enquanto cada um mantém seu próprio ambiente de desenvolvimento.

Ao usar organizações temporárias para desenvolvimento, primeiro efetue push da origem de seu projeto para o VCS a fim de sincronizar a organização temporária com os mesmos metadados. Se você está planejando usar a Configuração para desenvolvimento, as alterações feitas serão rastreadas automaticamente. Você pode puxar as modificações feitas para incluí-las no projeto e usar seu VCS para confirmar todas as alterações.

Dica

Dica

Como Calvin sabe quais componentes são aceitos pelo rastreamento da origem? O relatório de cobertura de metadados mostra se os tipos de metadados são aceitos pelo rastreamento da origem, pela API de metadados e por outros canais de metadados. Esse relatório gerado dinamicamente é a sua melhor fonte de informações de cobertura de metadados. Para acessar o relatório de cobertura de metadados, acesse https://developer.salesforce.com/docs/metadata-coverage.

Cada pacote tem seu próprio ritmo

No desenvolvimento com pacotes, é possível manter cronogramas de lançamento diferentes para cada pacote. Você usa pacotes para segmentar a propriedade dos metadados da organização, ou seja, cada projeto tem seu próprio pacote mais os pacotes de dependência. É possível gerenciar o upgrade de segmentos individuais independentemente por cada versão de pacote subsequente, o que permite cronogramas de lançamento diferentes.

O que é uma dependência de pacote? Um componente de metadados só pode estar em um pacote de cada vez. Se mais de um pacote precisar do mesmo componente, você poderá pensar em uma estratégia de pacote modular para esse componente. Um pacote contendo um ou mais componentes de metadados compartilhados por vários pacotes é uma dependência de pacote.

Cada pacote (e qualquer dependência de pacote) pode ser testado isoladamente de todos os outros metadados na organização. O isolamento de metadados dessa forma, em pacotes, é o que dá a flexibilidade necessária para controlar a versão desses conjuntos de metadados (pacotes) de forma independente. É ele também que permite a flexibilidade de lançar pacotes de forma independente.

O que vem a seguir?

Cada um dos três modelos de desenvolvimento tem seu próprio módulo no Trailhead. Ao trabalhar com cada módulo, você aprenderá a criar personalizações para o Salesforce usando o modelo de desenvolvimento pertinente.