Salesforce Centro de Excellence - 7/10

Mauricio: Fala pessoal, tudo bom? Hoje, no episódio 7, nós vamos falar sobre o Gate 4, que trata de Ambientes, Pipeline e Release. No episódio passado, a gente fechou o Gate 3. Três causas de desvio arquitetural, nenhuma delas envolvendo má fé, e uma delas criada pela própria governança. Automatizar tudo que a máquina faz para preservar a atenção humana. E o quarto defeito... a constante 0,3 no código, contra 0,4 na ADR. Nenhuma ferramenta encontra isso. O código passou, está aprovado, revisado com evidência. E agora vem a parte que, na minha experiência, concentra mais do concentra mais dor por metro quadrado do que qualquer outra na plataforma. Colocar produção. Hoje você vai ver três coisas. A primeira, desenhar uma topologia de ambientes de propósito vez de conviver com a que foi se formando sozinho ao longo dos anos. A segunda, montar o pipeline e o runbook de release com critérios de go e no go decididos antes da janela, não durante. E a terceira, tratar os três releases anuais do Salesforce como obrigação de governança, porque eles vão acontecer com você ou sem você. E nós vamos construir runbook para o account health score, incluindo uma parte desconfortável, passo que não tem rollback. A gente vai escrever isso no documento uma vez e descobrir isso na madrugada pessoal. Então vamos lá. Quase toda a dor de release que eu já vi, rastreia de volta para uma estratégia de ambientes que nunca foi desenhada. Ela foi acumulada. Alguém criou uma sandbox para projeto 2021 e ela ficou. Virou ambiente de UAT por acidente. Hoje, ninguém sabe o que tem lá dentro e todo mundo tem medo de recriar. os seus tipos e as restrições que importam de verdade para vocês saberem. A Developer só aumenta dados, limite pequeno de dados, recria dia. A Developer Pro só aumenta dados, tem limite maior de dados, também recria-se dia. A Partial Copy, uma amostra dos dados de produção, definida por uma Sandbox Template. Tem cinco dias de para você recriar ela. E a Foo, a cópia completa de produção, com período de 29 dias para você poder recriar ela novamente. Esse número de 29 dias é o que desenha toda a sua topologia. E deixa eu explicar por que. 29 dias significa que seu ambiente de staging não pode ser recriado sobre demanda. Se você quebrar alguma coisa lá numa terça, você não vai recriar na quarta-feira. E isso tem uma consequência que a maioria das equipes não tira. O full sandbox precisa ser tratado como ambiente gerenciado de vida longa com controle de mudanças próprio. Não é rascunho. Não é lugar somente de testar coisas. E tem tipo que é mais subutilizado ainda, a scratch orcs. Elas são orientadas ao código fonte, descartáveis, criadas a partir de arquivo de definição. Você levanta, usa e joga fora. São a ferramenta certa para o desenvolvimento de features e para a validação de CI. no modelo baseado pacotes. E quase todo time que eu conheço tem 4 sandbox de desenvolvimento, sendo disputadas e nenhuma scratch org configurada. Topologia funcional para uma prática de porta médio. Scratch orgs ou sandbox developer. Uma por feature. Uma developer pro compartilhada para integrar a sprint. Uma partial copy para o AT, com dados representativos. E uma full para staging e teste de desempenho. E a de produção. Agora, onde isso desmorona na prática? Na semeadura de dados. O dados da sandbox template do partial copy controlam quais objetos vêm e quanto. Vale investir neles com seriedade, e a maioria das equipes preenche no automático. Mas além do template, você precisa de uma abordagem que preserve integridade referencial entre objetos relacionados. Não adianta trazer account sem contact ou oportunidade apontando para registro que não veio. O requisito, qualquer que seja a ferramenta que você escolha, é este. Uma sandbox recriada precisa ficar utilizável horas, não semanas. Porque a sandbox que leva 3 semanas para ficar útil é a razão pela qual as equipes param de recriar. E aí você tem ambiente de dados de 18 meses atrás, onde tudo passa e a falsa confiança é o pior do que nenhuma confiança. e item que quase nunca está escrito o check list post refresh. Recriar uma sandbox quebra coisas silêncio. E-mails de usuários precisam ser mascarados, senão você dispara notificação para o cliente real. Endpoints de integração precisam ser repontados, senão a sandbox conversa com o sistema de produção do parceiro. Name Credentials e Connect Apps reconfigurados, Jobs Agendados restabelecidos, Configuração de entrega de e-mail redefinida, Escreva como Run Book, É executado com frequência suficiente para valer a automação. Agora vamos conversar sobre pipelines e re-release. Pipeline, quais são os seus estágios? Commit, análise estática com o code analyzer do episódio passado. Deploy no ambiente de validação, execução de testes, validação contra a produção, modo check only, aprovação e deploy. E eu quero parar nesse penúltimo, porque é o passo que mais reduz falhas noite de release, que é o mais pulado. A validação check-only roda ou deploy contra a produção de verdade, com os metadados de produção, com os dados de produção, com as dependências de produção, sem efetivar nada. e o resultado fica elegível para quick deploy depois. O que ela expõe é justamente o que o sandbox nenhum expõe Dependência que existe produção e não existe no seu ambiente de desenvolvimento Metadado incompatível com alguma coisa que alguém mudou lá na semana passada Teste que passa na sandbox e falha no volume real Descobrir isso às 10 da manhã da quinta-feira é totalmente irritante. Descobrir às 11 da noite de sábado com a janela correndo? Aí já é outra coisa. ferramentas. Existem três caminhos. O DevOps Center, é a opção incluída pela SalesForce, apoiada GitHub e adequada para quem está saindo do change set. Pipeline próprio com a SalesForce CLI GitHub Actions, GitLab ou Azure DevOps, que dá mais controle ou é plataforma de terceiro, que entrega mais coisas prontas a custo. E o trabalho do Coec não é escolher o melhor, é escolher uma e torná-la único caminho para a produção. A ferramenta importa muito menos do que a exclusividade. Uma pipeline excelente convivendo com o Chainset Manuais não é uma pipeline. é apenas uma sugestão. Exclusões Apagar campos e objetos não é simétrico a criar. Nem sempre é reversível. O dado vai junto e precisa de aprovação própria e decisão explícita sobre preservação. Trate como uma categoria separada no processo, não como mais item no pacote. O Run Book de Release, o que precisa estar dentro dele. O conteúdo do Release, com rastre e habilidade até os itens de trabalho. Sequência de Deploy, incluindo passos antes e depois. Passos manuais que não dá para automatizar, com o dono nomeado. Scripts de migração ou backfill. Passos de ativação ou filter flag Roteiro de validação pós deploy Plano de rollback Plano de comunicação E responsável nomeado pela decisão de go no go critérios de gol no gol decididos antes da janela nunca durante testes verdes validação stage concluída uat aprovado nenhum defeitos de severidade 1 ou 2 aberto hold back testado suporte avisado e janela confirmada contra o calendário de congelamento. O motivo de decidir antes é psicológico, não é técnico. Às 11 da noite de sábado, com o time cansado, o deploy meio feito, todo critério aparece negociável. E a lista escrita com antecedência é a única coisa que protege a decisão da situação. Os releases da Salesforce. O Salesforce entrega três releases principais no ano. Spring, Summer e Winter. E isso não é evento de fundo, é uma obrigação de governança. E é a que mais empresas tratam como notícia vez de tratar como trabalho. Aqui vai cinco passos a cada versão. 1. Revisar os releases notes buscando o que afeta a sua org. 2. Não ler tudo. Buscar as principais que afetam sua org. descontinuações, mudanças de comportamento padrão, prazos de aposentadoria de recursos que você usa, são exemplos. 2. Usar a instância de preview. As sandbox são movidas para a versão nova cronograma publicado antes de produção ser atualizada. Você se inscreve e ganha uma janela para testar. Essa janela é presente e a maioria das empresas não abre ele. 3. Rodar a suíta de regressão completa contra a sandbox preview. 4. Avaliar e agendar os critical updates. Esses têm data de aplicação obrigatória. Eles se tornam compulsórios independentemente de que você estar pronto e não estar pronto. Não adianta adiar eles. 5. Publicar resumo interno do que muda para os usuários e do que o COE já avaliou. A consequência de pular o preview é simples. Você descobre o impacto produção, com o usuário dentro, trabalhando. E a culpa nunca é da Salesforce. O cronograma foi publicado com meses de antecedência. A instância de preview estava disponível. As releases notes estavam lá. Isso é sempre uma falha de processo interna. Congelamento de mudanças. Publique o calendário. Fechamento financeiro, picos sazonais de negócio, os próprios releases da plataforma e defina o caminho de exceção junto. Porque congelamento sem exceção documentada é violado por definição no primeiro incidente urgente. E uma vez violado informalmente, ele perde autoridade para o resto do ano. Agora vamos montar exemplo. O Room Book do account Health Score. Com quatro elementos que vamos mostrar. dependência anterior ao deploy. A credencial fonte externa de tickets precisa estar configurada produção antes do deploy. Não é metadado. É uma configuração feita por uma pessoa com segredo que vem de outro time. Isso vai no runbook como passo manual com o dono nomeado e prazo. Porque se essa pessoa estiver de férias na sexta-feira, o release não acontece. E é o melhor saber na terça-feira antes disso acontecer. 2. Backfill Existe job que calcula a pontuação histórica de toda a base. Ele precisa rodar depois do deploy. porque depende do código novo e antes do componente ser exposto ao usuário. Sem inverter, 140 pessoas abrem o account e vêem pontuação vazia. E a primeira impressão de recurso novo é difícil de recuperar. 3. Exposição controlada. O componente fica atrás de custom permission. No Deploy, ninguém tem. A permissão é concedida primeiro ao grupo piloto, depois ampliada. Isso separa duas coisas que normalmente acontecem juntas e não deveriam. Entregar o código e ligar o recurso. Quando estão separadas, o Deploy deixa de ser evento de risco. 4. esse é item mais desconfortável. O plano de rollback. Reverter o código. Reverter o componente. Reverter a automação. E não reverter o backfill. O job escreveu pontuação histórica milhares de registros. Reverter isso é outro trabalho com outro script que precisa existir separadamente ou você aceita que os dados fiquem. Isso vai escrito no runbook com essas palavras. O Rollback não reverte os dados gravados pelo backfill. Não esqueçam disso pessoal. E aqui está o ponto do episódio inteiro. Não é que o rollback devesse ser perfeito. Muitos não são. E tudo bem. É que a hora de descobrir essa limitação é agora. Na terça. Escrevendo o documento com calma. E não às 11h30 da noite de sábado. Quando alguém pergunta, dá para voltar? E a resposta honesta é... Voltar o quê? Vamos recapitular pessoal, os 29 dias da full sandbox desenham sua topologia inteira. Staging é ambiente gerenciado, não rascunho. E a semeadura de dados é onde a estratégia de ambientes morre. Sandbox que leva semanas para ficar útil, deixa de ser recriada. A validação check only contra a produção é o passo que mais reduz falha release. E o gol no gol se decide antes da janela, porque às 11 da noite todo critério que aparecer é negociável. Os três releases anuais da Seles Force são trabalho agendado, não notícia. E aqui se faz seu item de ação. Documenta a topologia de ambientes, com cadência de recriação e dono de cada ambiente. Mais template de runbook, de release e seus critérios de go no go publicados. E comece pelo dono. Se você conseguir escrever o nome de responsável ao lado de cada ambiente que a empresa tem, você já vai descobrir duas ou três sandbox que ninguém reivindica. essas são as interessantes. No próximo episódio vamos trabalhar último gate. O recurso está produção e é o momento que a maioria dos programas de governança para de prestar atenção. E é exatamente quando o trabalho do COE começa a valer. No episódio 8 vamos falar sobre operação, saúde de org e dívida técnica. As quatro perguntas do gate 5 30 dias depois do release, a varredura mensal de saúde e o registro da dívida técnica com a regra de financiamento que é a única que eu conheço que funciona de verdade. Por quê? Trabalho de dívida que precisa vencer uma disputa de priorização contra funcionalidades de receita nunca, jamais é agendado. E vamos ver o account healthscore que vai voltar com três achados. deles é uma premissa de design que estava simplesmente errada. Até lá!