Entender o que é o gerenciamento de ciclo de vida de aplicativos

Objetivos de aprendizagem

Após concluir esta unidade, você estará apto a:
  • Identificar personalizações que podem ser feitas diretamente na organização de produção com segurança.
  • Definir o gerenciamento de ciclo de vida de aplicativos.
  • Explicar por que o uso do processo de gerenciamento de ciclo de vida de aplicativos faz com que as equipes desenvolvam aplicativos mais rapidamente.

Introdução

A Salesforce oferece vários processos e ferramentas de desenvolvimento para atender às necessidades dos usuários. Este módulo apresenta o processo de gerenciamento de ciclo de vida de aplicativos (ALM) e os três modelos de desenvolvimento.
  • Desenvolvimento com conjuntos de alterações
  • Desenvolvimento organizacional
  • Desenvolvimento com pacotes

De forma geral, os três modelos de desenvolvimento seguem o mesmo processo de ALM. Mas os modelos diferem na forma em que permitem o gerenciamento de alterações na organização. O controle de alterações é uma grande questão no desenvolvimento de software, e você poderá escolher o modelo de desenvolvimento que atende melhor a sua situação, se conhecer as diferenças.

Vamos seguir a jornada de um profissional do Salesforce e sua empresa durante a alteração dos desafios de desenvolvimento ao longo do tempo. Ao longo da história, você verá como cada modelo de desenvolvimento atende às necessidades de situações diferentes. Os detalhes sobre como usar os modelos de desenvolvimento são abordados em outros módulos desta trilha.

Nota

Nota

Nas mesmas circunstâncias, você e sua equipe poderiam fazer escolhas diferentes das feitas pela empresa fictícia apresentada neste módulo. O importante é conhecer as opções.

Apresentamos Calvin, o administrador do Salesforce na Zephyrus Relocation Services, Inc.

Calvin Green exerce muitos papéis técnicos na Zephyrus Relocation Services, uma empresa de mobilização de talentos em Fairfax, Virgínia. Um dos papéis de Calvin é personalizar o Salesforce para a equipe de vendas da empresa, que é pequena, mas está em rápida expansão. Usando a interface de configuração na organização de produção, ele cria uma quantidade impressionante de novos painéis e relatórios.

Calvin desenvolveu suas habilidades como administrador do Salesforce no Vetforce, o programa acelerador de carreiras e de treinamento profissional para membros do serviço militar, veteranos e seus cônjuges.

Calvin em sua mesa na Zephyrus, segurando sua caneca de café do Vetforce.

O que podemos mudar na produção com segurança?

Você pode desenvolver alguns tipos de novas funcionalidades em uma organização de produção com segurança. As personalizações que não afetam dados podem ser criadas em segurança em uma organização de produção, como o desenvolvimento de novos painéis, relatórios e modelos de email. No entanto, algumas personalizações feitas diretamente na produção podem criar um caos, com a exclusão de dados ou até pior.

O que pode acontecer se não testarmos as alterações antes de disponibilizá-las na produção?

  • Uma regra de fluxo de trabalho pode criar um loop de processamento infinito por acaso.
  • Uma alteração no tipo de um campo pode modificar dados de maneira irreversível.
  • Um erro de lógica em uma regra de validação pode impedir o salvamento de um registro.
  • As alterações de layout de página podem deixar as pessoas confusas em vez de melhorar a sua experiência.

A maneira mais segura de personalizar sua organização é realizar e testar as mudanças usando um ambiente dedicado ao desenvolvimento. Na verdade, algumas mudanças precisam ser feitas em um ambiente de desenvolvimento. Por exemplo: você não pode escrever código do Apex diretamente em uma organização de produção.

Mudar para conjuntos de alterações para personalizações mais seguras

Conforme a Zephyrus vai crescendo, a demanda de personalizações do Salesforce vai crescendo também. A empresa adiciona outro membro à equipe para ajudar. O aumento das solicitações de personalização inclui novas regras de fluxo de trabalho e layouts de página, e Calvin, com razão, não quer fazer essas alterações diretamente na organização de produção.

Para atender a essa necessidade do negócio, a Zephyrus decide fazer o upgrade para a Professional Edition. Na Professional Edition, a Zephyrus pode criar e testar o que for necessário usando ferramentas de desenvolvimento declarativas (apontar e clicar) em um ambiente de desenvolvimento diferente.

No modelo de desenvolvimento com conjuntos de alterações, Calvin e sua colega Ella podem gerenciar o aplicativo usando ferramentas declarativas. Eles não precisam usar uma interface de linha de comando ou um sistema de controle de versão para atender às necessidades de personalização cada vez maiores da equipe de vendas que eles atendem.

Com ferramentas declarativas, Calvin e Ella podem criar vários detalhes que aumentam a produtividade da equipe de vendas. Por exemplo, Calvin usa o Criador de aplicativo Lightning para criar um filtro que exibe um componente de rich text em uma página de oportunidade quando o Valor é de, no mínimo, US$ 1.000.000.

Como usar o Criador de aplicativo Lightning para criar um filtro.

Colocar um pouco de ordem no caos

Agora que as personalizações são feitas por várias pessoas em vários ambientes, Calvin pensa em como ele pode gerenciar o impacto futuro de todas as alterações, até as menos importantes.

Por exemplo, o objeto padrão Contato não tem um campo para Tipo de contato. Calvin pode adicionar facilmente esse campo personalizado e lançar o novo campo Tipo de contato imediatamente para todos os usuários. Mas será que ele deveria fazer isso?

  • O novo campo Tipo de contato entra em conflito com personalizações feitas por outra pessoa?
  • A equipe de vendas sabe como usar o novo campo ou precisa de treinamento?
  • Se o campo é obrigatório, alguma integração ou processo de importação precisa de atualização?
  • Onde o campo aparece? Em todos os layouts de página? Em quais modos de exibição de lista? Ele aparece em algum relatório ou painel?
  • O campo também deveria estar no objeto de lead? Se for o caso, o processo de conversão de leads mudaria?
  • Esse campo é necessário para integrações com outros sistemas? Se for o caso, talvez seja necessário fazer alterações em middleware, mapeamentos de campo, pontos de extremidade e assim por diante.

Na Salesforce Trailblazer Community, outros membros incentivam Calvin a examinar as etapas de gerenciamento de ciclo de vida de aplicativos que a Salesforce recomenda para desenvolver aplicativos novos e personalizados.

No site de desenvolvedores do Salesforce, Calvin descobre que o ALM define o processo de gerenciar o desenvolvimento de um aplicativo, do design até o lançamento final. O ALM também define uma estrutura para a correção de bugs e o aprimoramento de recursos ao longo do tempo.

Mas adicionar processos não atrasa o desenvolvimento?

Em uma reunião com Ernesto Rondán, diretor do departamento de TI, Calvin defende a mudança para o gerenciamento de ciclo de vida de aplicativos. O ALM (Application Lifecycle Management, Gerenciamento de ciclo de vida de aplicativos) oferece processo e políticas que ajudam na criação de aplicativos de maneira simples e, consequentemente, mais rápida, sem atrapalhar o que já existe. Os aplicativos e ferramentas podem variar, mas as etapas no ciclo de ALM se aplicam a todos os projetos de desenvolvimento do Salesforce.

O ciclo de ALM: planejar a versão, desenvolver, testar, compilar a versão, testar a versão, lançar

Passo 1: planejar a versão
Inicie seu projeto de personalização ou desenvolvimento com um plano. Identifique os requisitos e analise-os. Peça ao gerente de produto (ou funcionário com cargo equivalente) para criar especificações de design e compartilhá-las com a equipe de desenvolvimento para implementação. Determine os vários ambientes de teste e desenvolvimento e as necessidades da equipe enquanto o projeto avança pelo ciclo de ALM.
Passo 2: desenvolver
Conclua o trabalho seguindo as especificações do projeto. Faça o trabalho em um ambiente que contenha uma cópia dos metadados da organização de produção, mas sem dados de produção. Desenvolva na plataforma do Lightning usando uma combinação adequada de ferramentas declarativas (Process Builder, assistente de objeto personalizado e outras na interface de usuário) e programáticas (Developer Console, editor de código-fonte ou o Visual Studio Code).
Passo 3: testar
Execute as alterações feitas para verificar se elas estão funcionando bem, antes de integrá-las ao trabalho de outras pessoas. Faça o teste no mesmo tipo de ambiente usado na etapa de desenvolvimento, mas mantenha os ambientes de desenvolvimento e teste separados. Aqui você deve se concentrar em testar as próprias alterações, não em entender como as alterações afetarão outras partes da versão ou do aplicativo como um todo.
Passo 4: compilar a versão
Junte todos os ativos criados ou modificados durante a etapa de desenvolvimento em um mesmo artefato de versão: um pacote lógico de personalizações que você implanta na produção. Daqui em diante, concentre-se no lançamento, não nas contribuições individuais.
Passo 5: testar a versão
Teste o que você realmente vai implantar, mas teste com segurança em um ambiente de preparo que imita o de produção o máximo possível. Use uma quantidade realista de dados de produção representativos. Conecte seus ambientes de teste com todos os sistemas externos de que eles precisam para imitar os pontos de integração de seu sistema de produção. Execute testes de regressão e de desempenho final completos nesta etapa. Teste a versão com um conjunto pequeno de pessoas experientes que possam fornecer feedback (técnica chamada teste de aceitação do usuário).
Passo 6: lançar
Quando terminar os testes e alcançar suas metas de qualidade, pode implantar a personalização na produção. Treine seus funcionários e parceiros para que eles compreendam as alterações. Se uma versão tiver impacto significativo nos usuários, crie um ambiente diferente com dados realistas para treinar os usuários.