O treinamento de lançamento do Salesforce: uma abordagem prática para gerenciamento de lançamento

Gerenciamento de liberação, como o nome sugere, é o processo de gerenciamento, planejamento, programação e controle de uma construção de software por meio de diferentes estágios e ambientes; incluindo testes e implantação de versões de software (Humble & Farley, 2011).

É um tópico muito grande em si e só pode ser aperfeiçoado ao longo do tempo, tentando diferentes iterações com as equipes de desenvolvimento e combinando as necessidades de negócios ou lançamentos de recursos. Tentaremos abordar as práticas do setor de gerenciamento de metadados, construção de CI e gerenciamento de sandbox para gerenciar o treinamento de lançamento de uma organização.

Mas o que é um trem de lançamento?

Um trem de lançamento é uma técnica de entrega de recursos incremental e previsível. Requer que o desenvolvedor configure um processo formal para levar quaisquer alterações feitas no ambiente de desenvolvimento e implantá-las na produção.

Um trem de liberação pode ser dividido em três segmentos:

• Gerenciamento de metadados
• Construção de integração contínua
• Gerenciamento de sandbox

Gerenciamento de metadados

Metadados são dados que fornecem informações sobre outros dados. O Salesforce fornece um modelo de metadados rico e poderoso por meio de sua API de metadados . Os metadados do seu aplicativo descrevem e abrangem um conjunto de métodos que fornecem acesso programático ao código-fonte e à configuração de sua organização.

A API de metadados é a melhor maneira de gerenciar as personalizações no Salesforce. Ele suporta os métodos create , read , update e delete . Você pode usar conjuntos de alterações, o Force.com IDE e a ferramenta Ant Migration para migrar metadados de uma organização para outra, pois todos eles fornecem migrações por meio da API.

Cada ferramenta tem suas próprias vantagens e há várias coisas a serem consideradas ao escolher uma:

Tabela 1: Comparação de ferramentas para migração de metadados

A API de metadados é excelente para cumprir sua finalidade ao desenvolver e migrar alterações na plataforma Force.com. Mas há um pequeno problema - nem todos os metadados do Salesforce são suportados pela API de metadados. A documentação oficial fornece uma lista de componentes não suportados.

Se sua organização estiver fazendo alterações que não são compatíveis com a API de metadados, você deve replicar essas alterações manualmente na organização de destino. A melhor maneira de acompanhar essas mudanças é uma planilha. Se você tiver que recorrer a essa abordagem, é sempre aconselhável que uma única pessoa faça essas alterações e as acompanhe.

Esta seria uma boa lista geral de colunas que se poderia usar para rastrear essas alterações em uma planilha:

• Nome do componente
• Tipo de componente
• Alterar proprietário
• Descrição da funcionalidade
• Mapeamento de recursos
• Dependência com outros componentes
• Revisado/nome do revisor
• URL
• Nome/ID da organização
• Outros comentários

Controle de Versão e Integração Contínua

A migração de alterações para produção deve ser um processo tranquilo, pois é apenas uma repetição da aplicação de alterações no ambiente de teste e preparação. Ainda assim, sempre há uma chance de as coisas irem para o sul, e então você precisa de um plano alternativo. É muito importante manter o backup dos metadados da sua organização, e é para isso que servem o controle de versão e a construção de CI .

O controle de versão é uma necessidade absoluta para qualquer organização. Ele permite que os desenvolvedores trabalhem de forma colaborativa, eficiente e segura. Gerenciar o desenvolvimento e a migração de código multidesenvolvedor e multisandbox é um desafio no Salesforce. O Salesforce também tem seu próprio cronograma de lançamentos e manutenção. Essas atualizações fornecem novos recursos, mas podem introduzir uma alteração na API de metadados que pode interromper sua compilação de CI. Portanto, além de situações em que os desenvolvedores estão substituindo as alterações uns dos outros, o controle de versão ajuda você a criar uma estratégia de reversão. Ter uma estratégia de reversão é essencial quando seu aplicativo é executado no Force.com.

O diagrama de fluxo a seguir descreve uma estrutura prática para controle de versão e CI. Tentaremos fornecer uma breve descrição do que o diagrama representa.

1. Um desenvolvedor verificaria sua alteração no sistema de controle de versão.
2. O CI Server/Jenkins implantaria a compilação mais recente no sandbox de CI e executaria as classes de teste.
3. Se a implantação na etapa 2 for bem-sucedida, as alterações serão mescladas na ramificação de controle de qualidade.
4. A CI então implantaria a confirmação mais recente da ramificação de controle de qualidade para o sandbox de controle de qualidade.
5. Se o QA rejeitar as alterações devido a falhas de teste, as etapas 1 a 3 devem ser executadas novamente até que o QA limpe as alterações.
6. Depois que as alterações passam no teste de controle de qualidade, as alterações são mescladas na ramificação mestre.
7. As alterações mais recentes da ramificação Master são implantadas na sandbox Master.

Pode-se optar por adicionar mais ramificações, dependendo das necessidades da organização. Mas a estrutura acima funciona bem para as estruturas de desenvolvimento de nível médio a empresarial.

Gerenciamento de sandbox

Para aproveitar ao máximo o processo de DevOps da sua organização, é muito importante configurar a estrutura do sandbox. Antes de nos aprofundarmos nisso, vamos discutir os diferentes tipos de sandboxes que o Salesforce nos oferece.

Um sandbox é uma cópia quase exata dos metadados de produção de uma pessoa. Os sandboxes são normalmente usados ​​para fins de desenvolvimento, teste, preparação e treinamento. Existem quatro tipos de sandboxes, e deve-se levar em consideração ao escolher um sandbox. Sandboxes Full Copy podem custar muito dinheiro!

Abaixo está a tabela para os limites impostos pelo Salesforce para diferentes sandboxes.

Tabela 2: Comparação de Limites

Podemos ver que o preço não é a única diferença entre os sandboxes.

O sandbox do desenvolvedor tem um período de atualização de um dia, o que o torna adequado para desenvolvimento, mas pode acomodar apenas 200 MB de dados e nenhum dado de produção. Ao contrário, os sandboxes de cópia completa têm uma cópia exata dos dados de produção; até mesmo os IDs de registro são os mesmos. Isso pode torná-lo ótimo para teste e preparação, mas o período de atualização de 29 dias dificulta a obtenção dos metadados e dados de produção mais recentes na caixa de proteção de cópia completa.

A tabela abaixo funciona como uma regra geral para selecionar sandboxes:

Tabela 3: Casos de uso para seleção de sandbox

Abaixo está a estrutura organizacional típica que é adotada para projetos de médio porte. Para clientes de nível empresarial, a estrutura organizacional se torna mais complexa, mas segue amplamente o modelo abaixo.

O desenvolvimento do Salesforce geralmente é feito no sandbox do desenvolvedor (vermelho) e as alterações são movidas para o sandbox de integração (verde), que geralmente é um desenvolvedor pro ou um sandbox de cópia parcial. Em seguida, as alterações de vários sandboxes de integração são movidas para o sandbox de rollup (amarelo), que deve ser um sandbox de cópia parcial.

Se sua organização tiver alguma integração com o sistema de terceiros que precise de testes de integração e testes de carga a serem executados, é necessário ter um conjunto estável de dados que não mude de versão para versão. Portanto, é melhor ter uma cópia completa ou uma sandbox de cópia parcial para ele.

Essas alterações são então movidas para o sandbox de teste de integração, onde os testes são executados. Em seguida, as alterações são movidas para o sandbox de teste, que deve ser um sandbox de cópia completa. Todas as classes de teste são executadas antes da implantação. Uma validação de implantação deve ser realizada para garantir que a implantação ocorra sem problemas.

Esse processo nos ajuda a garantir que as alterações passem por várias rodadas de testes e pares de olhos. Ele vem com uma grande desvantagem de exigir muito tempo para desenvolver, testar e implantar alterações.

Muitas vezes, há uma necessidade urgente de realizar correções de bugs ou patches. Para lidar com isso rapidamente, deve-se manter um sandbox de desenvolvedor, que enviaria pequenos patches diretamente para o sandbox de rollup.

Como mencionado anteriormente, um sandbox é uma réplica quase exata dos metadados de produção, mas não completamente. Existe uma lista oficial de componentes/recursos que estão desabilitados em uma sandbox.

Outra coisa a considerar ao atualizar um sandbox é que ele copia apenas os metadados e dados de produção. Não há como copiar os metadados de um sandbox para outro, ou mesmo criar um sandbox vazio sem nenhuma configuração de metadados (como organizações de desenvolvedores gratuitas). Isso às vezes se torna um desafio em situações da vida real. A Salesforce tem planos para resolver esse problema, e esse recurso pode estar disponível em breve.

Além disso, se você tiver alguns dados confidenciais em produção, aos quais sua equipe de desenvolvimento ou teste não deve ter acesso, poderá criar modelos de sandbox para sandboxes totalmente e parcialmente copiados.

O que considerar ao implantar

Cobrimos as práticas do setor de gerenciamento do ciclo de vida do aplicativo no ecossistema Salesforce. O gerenciamento de metadados e sandbox desempenha um papel muito importante na criação de pacotes de implantação e cargas úteis. Para aplicativos Salesforce grandes e complexos, o controle de versão ajuda a garantir que as alterações de metadados sejam rastreadas, além de ajudar na criação de uma estratégia de reversão.

O gerenciamento de sandbox é fundamental para projetos grandes ou complexos. Mas os Sandboxes são caros no ecossistema Salesforce, tanto em termos de recursos financeiros quanto de tempo. A formulação de uma estratégia para gerenciamento de sandbox é sempre fundamental para o processo de gerenciamento de versão.

Deixaremos alguns pontos extras que seria bom ter em mente durante sua próxima implantação:

1. Apenas 10.000 arquivos, ou um arquivo ZIP de 39 MB, podem ser implantados de uma só vez. Naturalmente, se a carga útil for muito grande, você deve dividir o pacote em várias partes e depois fazer a implantação.
2. Se a implantação estiver falhando devido a um erro de request timeout , tente remover objetos, campos personalizados e perfis do pacote. Esses componentes demoram mais para serem implantados.
3. Se um tipo de campo for alterado ou houver alterações na hierarquia de papéis, poderá haver longos atrasos devido ao recálculo de dados, exigindo algum tempo para ser concluído.
4. O Salesforce bloqueia qualquer componente que esteja sendo usado atualmente por um usuário no sistema. Se tentarmos implantar enquanto esse for o caso, a implantação falhará.

Esperamos que esta visão geral o ajude durante sua próxima versão do Salesforce.

Fontes