Excelência operacional – Padrões de DevOps
Saiba mais sobre uma excelência operacional bem arquitetada → Práticas DevOps
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Configuração do controle de versão | ✅ Todos os metadados armazenados no formato de origem Git usando a estrutura de projeto Salesforce DX com .forceignore configurado para excluir arquivos irrelevantes; todos os membros da equipe clonam do repositório central |
| Uso da organização teste | ✅ Os desenvolvedores criam organizações teste efetivas da origem para trabalho de recurso, confirmam alterações de volta ao controle de versão e descartam organizações teste após a conclusão do recurso |
| Confirmar mensagens | ✅ Cada confirmação inclui uma mensagem clara e concisa explicando o que mudou e por quê; as mensagens seguem a convenção da equipe (por exemplo, “feat:”, “fix:”, “docs:“) |
| Rastreamento de alteração | ✅ Cada modificação de metadados capturada no controle de versão com identidade do autor, carimbo de data e hora e dif mostrando alterações exatas |
| Processo de revisão de código | ✅ Todas as alterações vinculadas à produção fluem por meio de solicitações de pull que exigem aprovação de revisão antes da mesclagem; a configuração declarativa recebe a mesma análise do código |
| Procedimentos de reversão | ✅ Versões anteriores recuperáveis do histórico do Git por meio de operações de checkout ou reversão; a equipe tem procedimentos de reversão documentados testados em não produção |
| Trilha de auditoria | ✅ Histórico de alterações concluído preservado no controle de versão com suporte a requisitos de conformidade e investigações de segurança |
| Estratégia de ramificação | ✅ Modelo de ramificação do Git consistente (GitFlow, GitHub Flow ou baseado em trunk) adequado ao tamanho da equipe e à frequência de lançamento; documentado e imposto |
| Migração baseada em organização | ✅ Transição para o desenvolvimento orientado por origem concluído logo no início do ciclo de vida da solução antes de os hábitos se solidificarem em relação ao desenvolvimento baseado em organização |
| Configuração .gitignore | ✅ O repositório exclui arquivos gerados, configurações específicas do usuário e credenciais; inclui apenas os arquivos de origem das equipes que pretendem obter a versão |
Anti-Padrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Organização como fonte da verdade | ⚡️ O desenvolvimento ocorre diretamente em sandboxes compartilhados com metadados exportados para o controle de versão conforme pensado; organizações e controle de versão divergem, criando falhas de implementação |
| .gitignore inadequado | ⚡️ O repositório inclui arquivos gerados, configurações específicas do usuário, binários grandes ou credenciais; aumenta o repositório e arrisca a exposição de segurança |
| Mensagens de confirmação vagas | Confirmações como “corrigir bug” ou “atualizações” não fornecem contexto para o que mudou ou por quê; impede investigações de auditoria e manutenção futuras |
| Confirmações insuficientes grandes | ⚡️ Os desenvolvedores confirmam grandes conjuntos de alterações semanalmente em vez de pequenas confirmações incrementais várias vezes por dia; difícil de revisar, difícil de isolar falhas |
| Confirmar diretamente no principal | ⚡️ Os desenvolvedores enviam alterações diretamente para a agência principal/produção ignorando revisão e validação; elimina portões de qualidade |
| Sem estratégia de ramificação | ⚡️ A equipe não tem um modelo de ramificação consistente; os desenvolvedores criam nomes de ramificação arbitrários e padrões de mesclagem; cria confusão e conflitos de mesclagem |
| Arquivos binários no Git | ⚡️ Arquivos binários grandes (PDFs, vídeos, arquivos) confirmados no Git aumentando o tamanho do repositório e desacelerando as operações de clonagem |
| Confirmação de credenciais | Chaves de API, senhas, credenciais de integração ou tokens de segurança confirmados no controle de versão; cria uma vulnerabilidade de segurança mesmo após a remoção de confirmações posteriores |
| Ignorar conflitos de mesclagem | ⚡️ Conflictos de mesclagem resolvidos aceitando uma parte sem análise; perde alterações ou introduz bugs |
| Nenhuma verificação de confirmação | ⚡️ A equipe nunca verifica se os metadados confirmados representam de fato as alterações pretendidas; erros de formato de metadados ou alterações indesejadas são ignorados |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Sandboxes do desenvolvedor | ✅ Desenvolvedores individuais usam sandboxes de Desenvolvedor para trabalho de recursos, teste de unidade e iteração rápida; cada desenvolvedor tem um ambiente dedicado |
| Sandboxes Developer Pro | ✅ Equipes que desenvolvem pacotes gerenciados ou exigem limites de armazenamento mais altos usam sandboxes Developer Pro para trabalho colaborativo |
| Sandboxes de Cópia parcial | ✅ O teste de integração usa sandboxes de Cópia parcial com amostras de dados representativas (10.000 registros por objeto) configuradas por meio de modelos de dados |
| Sandboxes de Cópia completa | ✅ Teste de desempenho, preparação semelhante à produção e validação de migração de dados usam sandboxes de Cópia total contendo dados e ajustes de produção completos |
| Controles de confidencialidade de dados | ✅ Acesso ao sandbox de cópia completa restrito a papéis que exigem dados de produção; mascaramento de dados da Shield Platform Encryption aplicado para uso não de produção quando apropriado |
| Configuração do ponto de extremidade de integração | ✅ Cada nível de sandbox se conecta a pontos de extremidade de teste correspondentes para integrações externas; as integrações de produção nunca se conectam de sandboxes |
| Configuração específica do ambiente | ✅ A arquitetura de integração usa tipos de metadados personalizados ou configurações personalizadas para externalizar URLs de ponto de extremidade, credenciais e sinalizadores de recurso por ambiente |
| Automação pós-atualização | ✅ Atualizações de sandbox acionam scripts automatizados do Salesforce CLI restaurando configurações específicas do sandbox, incluindo credenciais de integração, sementeamento de dados de teste, estados de sinalizador de recurso e capacidade de entrega de email |
| Atualizar agendamento | ✅ Agenda de atualização de sandbox documentada e comunicada; atualizações planejadas durante períodos de baixa atividade para minimizar interrupções da equipe |
| Modelos de dados | ✅ Sandboxes de Cópia parcial usam modelos de dados bem projetados selecionando dados representativos entre objetos mantendo a integridade referencial |
| Convenções de nomenclatura | ✅ Os sandboxes seguem uma convenção de nomenclatura clara indicando a finalidade, o proprietário e o ciclo de atualização (por exemplo, “dev-integration-q2”, “uat-release-2-4”) |
Anti-Padrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Sandbox de desenvolvimento compartilhado | ⚡️ Todos os desenvolvedores trabalham em um único sandbox compartilhado substituindo as alterações uns dos outros; cria confusão sobre o que é o estado implantável |
| Sandboxes obsoletos | Sandboxes não atualizados por meses divergem significativamente da configuração de produção; testes em ambiente não representativo levam a falhas de implementação |
| Sem governança de dados em cópia completa | Sandboxes de Cópia completa contendo PII de produção, dados financeiros e dados HIPAA acessíveis a toda a equipe de desenvolvimento sem controles de acesso ou mascaramento de dados |
| Integrações de produção do sandbox | ⚡️ Os sandboxes se conectam diretamente a pontos de extremidade de integração de produção criando o risco de transações de teste afetando dados de produção ou sistemas externos |
| Configuração pós-atualização manual | As atualizações de sandbox exigem horas de configurações de restauração de reconfiguração manual; a sobrecarga impede a atualização de sandboxes com a frequência necessária |
| Sem documentação de sandbox | ⚡️ A equipe não tem documentação sobre propósitos de sandbox, agendas de atualização, conteúdo de dados ou procedimentos de acesso; os desenvolvedores adivinham qual ambiente usar para qual finalidade |
| Tipo de ambiente único | ⚡️ A equipe usa apenas um tipo de sandbox (geralmente Developer ou Full Copy) para todos os fins; perde os benefícios da estratégia de sandbox adequada por atividade |
| Agrupamento de sandbox | ⚡️ Sandboxes alocados a indivíduos ou projetos e nunca liberados quando não são mais necessários; escassez artificial, apesar das licenças disponíveis |
| Dados de teste inadequados | Dados de teste em sandboxes não representam características de dados de produção (volumes, relacionamentos, casos de extremidade); testes em ambientes irrealistas ignoram problemas de produção |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Estágio de confirmação de origem | ✅ Os desenvolvedores confirmam alterações em ramificações de recursos no Git com mensagens de confirmação claras explicando o contexto e a racionalidade |
| Estágio da análise estática | ✅ O Salesforce Code Analyzer verifica o Apex quanto a vulnerabilidades de segurança (Top 10 do OASP), antipadrões de desempenho (SOQL em loops, DML em loops), problemas de qualidade de código (complexidade, duplicação) e riscos de limite do regulador; é executado em segundos fornecendo feedback imediato |
| Estágio de teste de unidade | ✅ Testes do Apex executam a validação da lógica de negócios e da conformidade do limite do regulador na organização teste efetiva ou no sandbox de integração dedicado; testes adequadamente isolados são concluídos em menos de 5 minutos |
| Estágio de implementação de validação | ✅ Implantação de metadados em sandbox de integração usando o Salesforce CLI com sinalizador –checkonly para testes de execução de implementação somente validação sem confirmação de alterações |
| Estágio de teste de integração | ✅ Testes automatizados validam fluxos de trabalho de vários componentes, contratos de integração externos, fluxos de evento de plataforma e cadeias de processamento assíncronas em relação ao ambiente de integração compartilhado com o gerenciamento de dados de teste |
| Estágio de verificação de segurança | ✅ Ferramentas de segurança adicionais verificam credenciais embutidas em código, dependências vulneráveis, violações de CRUD/FLS e violações de política de conformidade; descobertas críticas quebram compilações |
| Estágio de implantação de UAT | ✅ Alterações que passam todos os portões automatizados para o ambiente de teste de aceitação do usuário para validação de negócios; a implementação pode ser automatizada ou exigir aprovação manual com base no risco de alteração |
| Estágio de implantação de produção | ✅ Após a aprovação de UAT, as alterações são implementadas na produção com execução automatizada com um clique, registro abrangente e capacidade de reversão imediata |
| Tempo de execução do pipeline | ✅ O pipeline de ponta a ponta é concluído em menos de 15 minutos para alterações típicas que permitem feedback rápido; mais tempo para implantações grandes ou pacotes de teste extensos |
| Criar artefatos | ✅ O pipeline preserva pacotes de implementação, resultados de teste, relatórios de verificação de segurança e registros de execução para conformidade e solução de problemas |
| Ferramentas de pipeline | ✅ As equipes usam o Salesforce DevOps Center para CI/CD nativo da plataforma ou se integram a plataformas externas (Ações do GitHub, GitLab CI, Azure DevOps, CircleCI, Jenkins, Copado, Gearset, AutoRABIT) |
| Notificações de falha | ✅ Falhas de pipeline acionam notificações para autenticar autor e canais relevantes com contexto de diagnóstico que habilita a correção rápida |
| Proteção de ramificação | ✅ Ramificações principais/de produção protegidas exigindo aprovação de verificações de CI e revisões antes da mesclagem; confirmações diretas impedidas |
| Promoção ambiental | ✅ Alterações fluem pelo caminho de promoção definido (dev → integração → UAT → produção) com validação em cada estágio |
Anti-Padrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Implantações manuais | Alterações implementadas manualmente por meio de conjuntos de alterações ou comandos do Salesforce CLI com etapas inconsistentes; erros humanos, etapas perdidas, falta de trilha de auditoria |
| Nenhuma análise estática | ⚡️ Pipelines ignoram o Salesforce Code Analyzer ou ferramentas semelhantes; vulnerabilidades de segurança, antipadrões de desempenho, problemas de qualidade de código chegam à produção |
| Teste insuficiente | ⚡️ O pipeline valida apenas uma cobertura mínima de 75% sem executar testes de integração ou validar os principais fluxos de usuário; as regressões são ignoradas |
| Sem verificação de segurança | ⚡️ Os pipelines nunca verificam credenciais embutidas em código, dependências vulneráveis ou violações de CRUD/FLS; problemas de segurança descobertos em revisões de produção ou de segurança |
| Execução de pipeline lenta | ⚡️ O pipeline de ponta a ponta leva 45 a 60 minutos, impedindo confirmações frequentes e desacelerando os loops de feedback; os desenvolvedores se comprometem com menos frequência acumulando alterações maiores |
| Falhas do pipeline ignoradas | ⚡️ As equipes ignoram ou substituem falhas de pipeline para cumprir prazos; os portões de qualidade se tornam teatro em vez de controles reais |
| Sem paridade de ambiente de teste | ⚡️ O CI/CD é validado em um ambiente com configuração, limites ou características de dados diferentes da produção; a aprovação da validação não garante o sucesso da produção |
| Funcionalidade de reversão ausente | ⚡️ O pipeline automatiza a implantação, mas não fornece reversão automatizada; a recuperação de uma implantação incorreta requer procedimentos manuais de emergência |
| Sem registros de implementação | Implantações executadas sem registro abrangente; a solução de falhas ou a auditoria de implantações se torna difícil |
| Teste de tudo ou nada | ⚡️ O pipeline executa todos os testes para cada alteração, não importa o que mudou; um pacote de teste de 30 minutos é executado mesmo para atualizações de documentação |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Sinalizadores de recurso | ✅ Alterações de alto risco implantadas com recursos desabilitados por trás do tipo de metadados personalizados ou ajustes de configuração personalizada; habilita o teste em produção sem exposição do usuário, distribuição gradual para segmentos, teste A/B e reversão instantânea por meio de alteração de configuração |
| Escopo do sinalizador de recurso | ✅ Indicadores de recurso reservados para alterações de alto risco que afetam processos de negócios críticos, operações sensíveis ao desempenho ou novos padrões de integração; nem todos os recursos precisam de indicadores |
| Implantações canárias | ✅ Liberação de alterações críticas para os negócios para um pequeno subconjunto de usuários primeiro (5-10% por meio de conjuntos de permissões ou filtragem de atributo de usuário); coorte canária monitorada intensivamente 24-48 horas medindo taxas de sucesso, desempenho e taxas de erro antes de expandir a distribuição |
| Janelas de implementação | ✅ Implantações agendadas durante períodos de uso baixo informadas por logs de uso da API de Monitoramento de evento mostrando padrões reais de tráfego; evita uso máximo, fechamento de fim de mês, fechamento de fim de trimestre e eventos comerciais importantes |
| Comunicação da implementação | ✅ As partes interessadas recebem notificações antecipadas de janelas de implementação, incluindo duração esperada, funcionalidade afetada e linha do tempo de decisão de reversão |
| Procedimentos de reversão | ✅ Procedimentos de reversão documentados e testados para cada tipo de implementação; a equipe pode executar o reversão em menos de 30 minutos quando necessário |
| Teste de reversão | ✅ Processos de reversão validados em ambientes que não sejam de produção antes de implantações significativas garantindo a existência da capacidade de recuperação |
| Validação da implantação | ✅ Testes de fumaça pós-implementação validam fluxos de usuário críticos, pontos de extremidade de integração e funcionalidade-chave imediatamente após a liberação |
| Alteração de coordenação | ✅ Estratégia de implantação coordenada quando as alterações abrangem vários sistemas ou exigem versões sincronizadas entre o Salesforce e plataformas externas |
| Monitoramento durante a implantação | ✅ Monitoramento aprimorado ativo durante a janela de implementação e o período de observação pós-implementação (24 a 48 horas) observando picos de taxa de erro, degradação do desempenho ou falhas de fluxo do usuário |
| Padrão azul-verde para integrações | ✅ Serviços externos em frente ao Salesforce usam implantações azul-verde mantendo dois ambientes semelhantes a produção, implantando para inativos primeiro, alternando o tráfego após a validação |
Anti-Padrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Implantações de Big Bang | Versões grandes contendo muitos recursos, refatoramentos e alterações implementados simultaneamente sem distribuição gradual; a falha afeta todos os usuários imediatamente |
| Implantações de horário de pico | ⚡️ Versões agendadas durante o horário comercial de pico (meio dia, fim de mês, fim de trimestre) quando o uso é mais alto e o impacto do usuário dos problemas é maximizado |
| Sem plano de reversão | As implantações prosseguem sem procedimentos de reversão documentados e testados; quando ocorrem problemas, a equipe trabalha para descobrir a recuperação |
| Recurso alterna como pensamento posterior | Sinalizadores de recurso adicionados reativamente quando ocorrem problemas em vez de projetados proativamente para alterações de alto risco; limita as opções de reversão à reversão total da implementação |
| Sem validação de implantação | ⚡️ Alterações implementadas na produção sem testes de fumaça pós-implementação; a equipe presume que a implantação foi bem-sucedida e avança; problemas descobertos horas depois pelos usuários |
| Procedimentos de reversão não testados | ⚡️ Processos de reversão documentados, mas nunca testados em não produção; durante o incidente real, o procedimento falha ou prova-se inadequado |
| Alterações simultâneas de vários sistemas | Alterações coordenadas no Salesforce e em sistemas externos implementadas sem testes de sincronização ou compatibilidade; cria falhas de integração |
| Sem aprimoramento de monitoramento | As implantações prosseguem sem monitoramento aprimorado durante a janela de implantação; problemas detectados por meio de reclamações do usuário em vez de alertas proativos |
| Implantações de fim de semana | ⚡️ Versões principais implantadas na sexta-feira à noite ou em fins de semana quando a cobertura na chamada é reduzida e a disponibilidade de suporte do fornecedor limitada |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Cobertura de teste de unidade | ✅ Cobertura de teste relevante que valida regras de negócios, casos de extremidade, caminhos de erro e abordagem de limite do regulador; excede significativamente 75% do requisito mínimo |
| Qualidade do teste de unidade | ✅ Os testes validam a lógica de negócios, não a funcionalidade da plataforma; testes de unidade bem escritos são rápidos (milissegundos), isolados (sem estado compartilhado) e focados (cada teste valida um comportamento) |
| Estratégia de testar dados | ✅ Os testes usam métodos @TestSetup para dados de teste comuns; evite consultas SOQL em testes quando possível; use Test.loadData() para carregar recursos estáticos |
| Simular dependências externas | ✅ Testes de unidade simulam chamadas externas usando fragmento de teste e injeção de dependência permitindo execução rápida sem solicitações HTTP reais |
| Testes de integração | ✅ Valide interações entre acionadores, fluxos, eventos de plataforma, trabalhos em lote e chamadas externas em sandboxes com dados de teste representativos |
| Confiabilidade do teste de integração | ✅ Os testes de integração são repetíveis e determinísticos; falhas esporádicas tratadas por meio de mecanismos de sincronização, como IDs de repetição de evento de plataforma e pesquisa de trabalho em lote |
| Testes de ponta a ponta | ✅ Testes automatizados do navegador (Selenium, Playwright, Provar) validam jornadas completas do usuário para fluxos críticos para os negócios exercendo o sistema por meio da IU exatamente conforme os usuários interagem |
| Foco de teste E2E | ✅ Testes E2E focam caminhos do usuário de maior valor devido à execução mais lenta (minutos por teste) e à maior carga de manutenção resultante de alterações na interface do usuário |
| Carregar teste | ✅ Desempenho validado sob cargas de usuário simultâneas e volumes de dados realistas usando serviços de Teste de carregamento do Salesforce ou ferramentas de terceiros; revela problemas de limite do controlador, contenção de bloqueio e degradação de desempenho |
| Frequência de carregamento de teste | ✅ Testes de carregamento são executados antes das versões principais e periodicamente (trimestral) para validar o desempenho em 3x a 5x dos volumes de produção atuais |
| Pirâmide de teste | ✅ Distribuição de testes equilibrada: muitos testes de unidade (centenas, minutos), menos testes de integração (duzas, minutos), poucos testes E2E (menos de 20 minutos); feedback rápido na base, validação abrangente no topo |
| Isolamento de teste | ✅ Os testes não dependem uns dos outros; podem ser executados em qualquer ordem; cada teste deixa o sistema em estado de atualização ou usa @TestSetup para um ponto de partida consistente |
| Casos de teste negativos | ✅ Os testes validam o tratamento de erros, a imposição de regras de validação, a imposição de permissões e a degradação adequada sob condições adversas |
| Teste de limite do controlador | ✅ Os testes validam especificamente o comportamento se aproximando dos limites do controlador, incluindo limites de consulta SOQL, limites de DML, tempo de CPU, tamanho de heap |
| Execução de teste contínuo | ✅ Os testes são executados automaticamente em cada confirmação por meio do pipeline CI/CD; falhas nos testes impedem a implantação em ambientes mais altos |
Anti-Padrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Testar para cobertura | ⚡️ Testes escritos apenas para atingir a cobertura mínima de 75% sem validar regras de negócios ou casos de ponta; testes que não afirmam nada ou testam caminhos de código triviais |
| Testar a funcionalidade da plataforma | Os testes validam se o Salesforce salva registros ou consultas SOQL funcionam em vez de validar a lógica de negócios; desperdiça esforço em garantias de plataforma |
| Sem estratégia simulada | ⚡️ Testes de unidade fazem chamadas reais a sistemas externos; os testes são lentos, frágeis em relação à disponibilidade do sistema externo e consomem limites de API |
| Falhas de teste esporádicas | ⚡️ Testes são aprovados ou falham de modo imprevisível com base no momento da execução, no estado de dados ou na ordem de execução do teste; as equipes aprendem a ignorar falhas e executar novamente até que os testes sejam aprovados |
| Sem teste de integração | Existem apenas testes de unidade; a equipe nunca valida se acionadores, fluxos, eventos de plataforma e trabalhos em lote funcionam corretamente juntos |
| Somente teste manual E2E | Fluxos de usuário críticos validados manualmente antes de cada versão; nenhum teste E2E automatizado; regressões descobertas em produção quando o teste manual perde cenários |
| Sem teste de carregamento | Desempenho nunca validado sob cargas simultâneas realistas; problemas de limite do controlador, contenção de bloqueio ou degradação de desempenho descobertos na produção |
| Testar dependências de dados | Os testes dependem de registros específicos existentes na organização ou presumem uma configuração de usuário específica; interromper quando o sandbox for atualizado ou a configuração mudar |
| Nenhum caso de teste negativo | ⚡️ Os testes validam apenas cenários de caminho feliz; nunca testam manipulação de erros, imposição de validação ou verificações de permissão; os modos de falha não são descobertos |
| Testes ignorados | ⚡️ Testes com falha não comentados em @isTest e ignorados em vez de corrigidos; o pacote de testes se degrada com o tempo conforme mais testes são ignorados |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Revisar a cobertura | ✅ Todas as alterações vinculadas à produção fluem por revisão de código por meio de solicitações de pull que exigem aprovação antes da mesclagem; inclui Apex, Aura, LWC, Fluxos, regras de validação, conjuntos de permissões, regras de compartilhamento |
| Revisar a lista de verificação de critérios | ✅ Lista de verificação explícita que abrange segurança (imposição de CRUD/FLS, validação de entrada), desempenho (massificação, otimização SOQL), conformidade com o limite do regulador (padrões de processamento, prevenção de recursão), capacidade de manutenção (nomeação, documentação, complexidade), cobertura de teste (testes significativos, casos de ponta), consistência arquitetônica (padrões de design, separação de preocupações) |
| Revisar limites de tamanho | ✅ Solicitações de pull mantidas abaixo de 400 linhas de alteração relevante permitindo revisão aprofundada; recursos grandes divididos em alterações incrementais menores que podem ser revisadas individualmente e implementadas de modo independente |
| Revisar horário | ✅ Revisões concluídas em um dia útil mantendo o impulso de desenvolvimento e fornecendo feedback rápido; revisões atrasadas criam sobrecarga de alternância de contexto |
| Verificações pré-visualização automatizadas | ✅ Análise estática, testes de unidade e verificação de segurança são executadas automaticamente antes da análise humana solicitada; verificações automatizadas capturam problemas mecânicos para que os revisores se concentrem no design e na lógica de negócios |
| Responsabilidade de revisão distribuída | ✅ Responsabilidade de revisão de código distribuída em toda a equipe, evitando gargalos e compartilhando Knowledge; desenvolvedores júnior revisam código sênior e explicam seu próprio código durante as revisões |
| Revisar a qualidade dos comentários | ✅ Os revisores fornecem feedback específico e acionável com raciocínio; distinguir entre alterações necessárias (bloco de problemas) e sugestões (melhorias recomendáveis) |
| Revisar a documentação | ✅ As descrições da solicitação de pull explicam o que mudou, por que mudou, quais testes foram feitos e quaisquer considerações especiais de implantação ou procedimentos de reversão |
| Revisão de configuração declarativa | ✅ Fluxos, regras de validação e alterações de permissão recebem a mesma rigor de análise do código; a configuração é arquitetônica e merece análise |
| Acompanhamento em comentários | ✅ Todos os comentários de revisão tratados antes da mesclagem; perguntas respondidas, alterações implementadas ou raciocínio fornecido para o motivo pelo qual a sugestão não foi adotada |
Anti-Padrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Sem revisão de código | ⚡️ Alterações confirmadas diretamente na agência de produção sem revisão por pares; elimina o mecanismo de detecção de defeito primário |
| Carimbo de borracha | ⚡️ Os revisores aprovam solicitações de pull em segundos sem realmente examinar as alterações; a revisão se torna conformidade com a caixa de seleção em vez de um gate de qualidade |
| Lacuna de garrafa de Revisor único | ⚡️ Apenas um desenvolvedor sênior autorizado a revisar o código; cria gargalos e ponto único de falha; Knowledge concentrado em vez de distribuído |
| Solicitações de pull em massa | ⚡️ Solicitações de pull contendo milhares de linhas de alterações abrangendo vários recursos; impossível revisar completamente, levando a um exame superficial |
| Revisões atrasadas | ⚡️ As solicitações de pull ficam sem revisar por dias ou semanas; os desenvolvedores perdem o contexto e mudam para outro trabalho; os comentários de revisão chegam quando o desenvolvedor mudou de contexto mental |
| Sem critérios de revisão | ⚡️ A equipe não tem critérios explícitos para o que os revisores devem examinar; a qualidade da revisão varia muito de acordo com o revisor; alguns revisores se concentram no estilo, outros na lógica, nenhum abrangente |
| Revisar sem testar | ⚡️ Revisores aprovam alterações com base apenas na inspeção de código sem puxar ramificação e testar localmente ou validar a passagem de testes automatizados |
| Verificações automatizadas ignoradas | ⚡️ Revisores aprovam solicitações de pull apesar de falhas de análise estática, verificações de segurança ou testes de unidade; derrota o propósito dos portões de qualidade automatizados |
| Cultura de revisão hostil | As análises se tornam críticas pessoais ou exercícios competitivos em vez de melhorias de qualidade colaborativas; desencoraja a aprendizagem e a segurança psicológica |
| Sem revisão declarativa | Fluxos, regras de validação, conjuntos de permissões e regras de compartilhamento são implementados sem revisão enquanto o Apex code é analisado; cria lacunas de qualidade na configuração declarativa |