Excelencia operativa - Patrones de DevOps
Obtenga más información acerca de Excelencia operativa bien arquitecta → Prácticas de DevOps
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Configuración de Control de versión | ✅ Todos los metadatos almacenados en formato de origen Git utilizando la estructura del proyecto Salesforce DX con .forceignore configurado para excluir archivos irrelevantes; todos los miembros del equipo duplican desde el repositorio central |
| Uso de organización borrador | ✅ Los desarrolladores crean organizaciones borrador efímeras desde el origen para el trabajo de funciones, confirman cambios de vuelta al control de versiones y descartan organizaciones borrador después de completar la función |
| Confirmar mensajes | ✅ Cada confirmación incluye un mensaje claro y conciso que explica qué cambió y por qué; los mensajes siguen la convención del equipo (por ejemplo, “feat:”, “fix:”, “docs:“) |
| Cambiar seguimiento | ✅ Cada modificación de metadatos capturada en el control de versión con identidad de autor, marca de tiempo y diferencia mostrando cambios exactos |
| Proceso de revisión de código | ✅ Todos los cambios vinculados a la producción fluyen a través de solicitudes de extracción que requieren aprobación de revisión antes de la combinación; la configuración declarativa recibe el mismo escrutinio que el código |
| Procedimientos de reversión | ✅ Versiones anteriores recuperables desde el historial de Git mediante Checkout o operaciones de reversión; el equipo ha documentado procedimientos de reversión probados en no producción |
| Seguimiento de auditoría | ✅ Historial de cambios completo conservado en el control de versiones que admite requisitos de cumplimiento e investigaciones de seguridad |
| Estrategia de bifurcación | ✅ Modelo de bifurcación de Git coherente (GitFlow, GitHub Flow o basado en enlaces) apropiado para el tamaño del equipo y la frecuencia de versión; documentado y aplicado |
| Migración desde organización | ✅ La transición al desarrollo dirigido por origen se completó pronto en el ciclo de vida de la solución antes de que los hábitos se solidifiquen en el desarrollo basado en la organización |
| Configuración de .gitignore | ✅ El repositorio excluye archivos generados, parámetros específicos del usuario y credenciales; incluye solo archivos de origen que los equipos pretenden versionar |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Organización como fuente de verdad | ⚠️ El desarrollo se produce directamente en entornos sandbox compartidos con metadatos exportados al control de versiones como idea posterior; las organizaciones y el control de versiones divergen creando fallos de implementación |
| .gitignore inadecuado | ⚠️ El repositorio incluye archivos generados, configuración específica del usuario, grandes binarios o credenciales; repositorio hinchado y riesgos de exposición de seguridad |
| Mensajes de confirmación vagos | ⚠️ Confirmaciones como “corregir fallo” o “actualizaciones” no proporcionan contexto para lo que cambió o por qué; obstaculiza las investigaciones de auditoría y el mantenimiento futuro |
| Confirmaciones poco frecuentes grandes | ⚠️ Los desarrolladores confirman grandes conjuntos de cambios semanalmente en vez de pequeñas confirmaciones incrementales varias veces al día; difícil de revisar, difícil de aislar fallos |
| Confirmar directamente con principal | ⚠️ Los desarrolladores envían los cambios directamente a la rama principal/de producción omitiendo la revisión y validación; elimina las puertas de calidad |
| Sin estrategia de bifurcación | ⚠️ El equipo carece de un modelo de bifurcación coherente; los desarrolladores crean nombres de bifurcación y patrones de combinación arbitrarios; crea confusión y conflictos de combinación |
| Archivos binarios en Git | ⚠️ Archivos binarios de gran tamaño (PDF, vídeos, archivos) confirmados con el tamaño de repositorio hinchado de Git y ralentizando operaciones de duplicación |
| Confirmación de credenciales | ⚠️ Llaves de API, contraseñas, credenciales de integración o tokens de seguridad confirmados para el control de versiones; crea vulnerabilidad de seguridad incluso después de la eliminación de confirmaciones posteriores |
| Ignorar conflictos de combinación | ⚠️ Conflictos de combinación resueltos aceptando una parte sin análisis; pierde cambios o introduce fallos |
| Sin verificación confirmada | ⚠️ El equipo nunca verifica que los metadatos confirmados representan realmente cambios previstos; los errores de formato de metadatos o cambios no intencionados se deslizan por |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Sandboxes de desarrollador | ✅ Los desarrolladores individuales utilizan entornos sandbox de desarrollador para el trabajo de funciones, pruebas de unidad e iteración rápida; cada desarrollador tiene un entorno exclusivo |
| Sandboxes de Developer Pro | ✅ Los equipos que desarrollan paquetes gestionados o requieren límites de almacenamiento más altos utilizan entornos sandbox de Developer Pro para el trabajo colaborativo |
| Sandboxes de copia parcial | ✅ Las pruebas de integración utilizan entornos sandbox de copia parcial con muestras de datos representativas (10.000 registros por objeto) configuradas a través de plantillas de datos |
| Sandboxes de copia completa | ✅ Pruebas de rendimiento, organización similar a producción y validación de migración de datos utilizan entornos sandbox de copia completa que contienen datos de producción completos y configuración |
| Controles de sensibilidad de datos | ✅ Acceso de sandbox de copia completa restringido a funciones que requieren datos de producción; enmascaramiento de datos Shield Platform Encryption aplicado para uso que no es de producción cuando sea apropiado |
| Configuración de extremo de integración | ✅ Cada nivel de sandbox se conecta a extremos de prueba correspondientes para integraciones externas; las integraciones de producción nunca se conectan desde entornos sandbox |
| Configuración específica del entorno | ✅ La arquitectura de integración utiliza tipos de metadatos personalizados o configuración personalizada para externalizar direcciones URL de extremo, credenciales y marcas de función por entorno |
| Automatización posterior a la actualización | ✅ Las actualizaciones de sandbox desencadenan secuencias de comandos automatizadas Salesforce CLI restaurando parámetros específicos de sandbox incluyendo credenciales de integración, inicialización de datos de prueba, estados de indicador de función y capacidad de entrega de correo electrónico |
| Actualizar programación | ✅ Programación de actualización de sandbox documentada y comunicada; actualizaciones planificadas durante periodos de baja actividad para minimizar la interrupción del equipo |
| Plantillas de datos | ✅ Los entornos sandbox de copia parcial utilizan plantillas de datos bien diseñadas seleccionando datos representativos entre objetos manteniendo la integridad referencial |
| Convenios de nomenclatura | ✅ Los entornos sandbox siguen una convención de nomenclatura clara que indica el propósito, el propietario y el ciclo de actualización (por ejemplo, “dev-integration-q2”, “uat-release-2-4”) |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Sandbox de desarrollo compartido | ⚠️ Todos los desarrolladores trabajan en un único entorno sandbox compartido sobrescribiendo los cambios de otros; crea confusión acerca de qué es el estado de implementación |
| Sandboxes obsoletos | ⚠️ Los entornos sandbox no actualizados durante meses difieren significativamente de la configuración de producción; las pruebas en entornos no representativos conducen a fallos de implementación |
| Sin gobernanza de datos en copia completa | ⚠️ Sandboxes de copia completa que contienen PII de producción, datos financieros, datos HIPAA accesibles para todo el equipo de desarrollo sin controles de acceso o enmascaramiento de datos |
| Integraciones de producción desde Sandbox | ⚠️ Los entornos sandbox se conectan directamente a extremos de integración de producción creando riesgo de transacciones de prueba que afectan a datos de producción o sistemas externos |
| Configuración manual posterior a la actualización | ⚠️ Las actualizaciones de sandbox requieren horas de reconfiguración manual restaurando los parámetros; los gastos generales desaconsejan actualizar sandboxes con la frecuencia que sea necesaria |
| Sin documentación de sandbox | ⚠️ El equipo carece de documentación acerca de propósitos de sandbox, programaciones de actualización, contenido de datos o procedimientos de acceso; los desarrolladores adivinan qué entorno utilizar para qué propósito |
| Tipo de entorno único | ⚠️ El equipo utiliza solo un tipo de entorno sandbox (normalmente desarrollador o copia completa) para todos los fines; pierde los beneficios de una estrategia de entorno sandbox apropiada por actividad |
| Acaparamiento de sandbox | ⚠️ Sandboxes asignados a particulares o proyectos y nunca liberados cuando ya no son necesarios; escasez artificial a pesar de las licencias disponibles |
| Datos de prueba inadecuados | ⚠️ Los datos de prueba en entornos sandbox no representan características de datos de producción (volúmenes, relaciones, casos periféricos); las pruebas en entornos poco realistas pierden problemas de producción |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Etapa de confirmación de origen | ✅ Los desarrolladores confirman cambios en bifurcaciones de funciones en Git con mensajes de confirmación claros que explican el contexto y la justificación |
| Etapa de análisis estático | ✅ Salesforce Code Analyzer explora Apex buscando vulnerabilidades de seguridad (OWASP Top 10), antipatrones de rendimiento (SOQL en bucles, DML en bucles), problemas de calidad de código (complejidad, duplicación) y riesgos límite reguladores; se ejecuta en segundos proporcionando comentarios inmediatos |
| Etapa de prueba de unidad | ✅ Las pruebas Apex ejecutan la validación de la lógica comercial y el regulador limita el cumplimiento en organizaciones borrador efímeras o entornos sandbox de integración exclusivos; las pruebas correctamente aisladas se completan en menos de 5 minutos |
| Etapa de implementación de validación | ✅ Los metadatos se implementan en sandbox de integración utilizando Salesforce CLI con –checkonly flag para implementación solo de validación ejecutando pruebas sin confirmar cambios |
| Etapa de prueba de integración | ✅ Las pruebas automatizadas validan flujos de trabajo de múltiples componentes, contratos de integración externa, flujos de eventos de plataforma y cadenas de procesamiento asíncrono en entornos de integración compartidos con gestión de datos de prueba |
| Etapa de exploración de seguridad | ✅ Las herramientas de seguridad adicionales buscan credenciales codificadas, dependencias vulnerables, infracciones de CRUD/FLS e infracciones de políticas de cumplimiento; compilaciones de fallos críticos |
| Etapa de implementación de UAT | ✅ Los cambios que pasan todas las puertas automatizadas se implementan en un entorno de prueba de aceptación de usuarios para validación comercial; la implementación puede automatizarse o requerir aprobación manual basándose en el riesgo de cambio |
| Etapa de implementación de producción | ✅ Tras la aprobación de UAT, los cambios se implementan en producción con ejecución automatizada de un solo clic, registro integral y capacidad de reversión inmediata |
| Tiempo de ejecución de oportunidades en curso | ✅ Las oportunidades en curso de extremo a extremo se completan en menos de 15 minutos para cambios típicos que permiten comentarios rápidos; más tiempo para implementaciones grandes o conjuntos de pruebas extensos |
| Construir artefactos | ✅ Oportunidades en curso conserva paquetes de implementación, resultados de pruebas, informes de análisis de seguridad y registros de ejecución para el cumplimiento y la solución de problemas |
| Herramientas de canalización | ✅ Los equipos utilizan Salesforce DevOps Center para CI/CD nativo de plataforma, o se integran con plataformas externas (Acciones de GitHub, GitLab CI, Azure DevOps, CircleCI, Jenkins, Copado, Gearset, AutoRABIT) |
| Notificaciones de fallos | ✅ Los fallos de canalización desencadenan notificaciones para confirmar el autor y los canales relevantes con contexto de diagnóstico que permite una rápida solución |
| Protección de sucursal | ✅ Ramas principales/de producción protegidas que requieren pasar comprobaciones de IC y revisiones aprobadas antes de la combinación; se evitan las confirmaciones directas |
| Promoción de entorno | ✅ Flujo de cambios a través de ruta de promoción definida (desarrollo → integración → UAT → producción) con validación en cada etapa |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Implementaciones manuales | ⚠️ Cambios implementados manualmente a través de conjuntos de cambios o comandos Salesforce CLI con pasos incoherentes; errores humanos, pasos fallidos, falta de seguimiento de auditoría |
| Sin análisis estático | ⚠️ Las oportunidades en curso omiten Salesforce Code Analyzer o herramientas similares; las vulnerabilidades de seguridad, los antipatrones de rendimiento, los problemas de calidad del código llegan a producción |
| Pruebas insuficientes | ⚠️ Las oportunidades en curso solo validan una cobertura mínima del 75% sin ejecutar pruebas de integración o validar flujos de usuario clave; las regresiones se deslizan por |
| Sin escaneo de seguridad | ⚠️ Las oportunidades en curso nunca buscan credenciales codificadas, dependencias vulnerables o infracciones de CRUD/FLS; problemas de seguridad descubiertos en revisiones de producción o seguridad |
| Ejecución de canalización lenta | ⚠️ Las oportunidades en curso de extremo a extremo tardan de 45 a 60+ minutos en desalentar confirmaciones frecuentes y ralentizar bucles de comentarios; los desarrolladores confirman con menos frecuencia acumulando cambios más grandes |
| Fallos de canalización ignorados | ⚠️ Los equipos ignoran o sustituyen los fallos de oportunidades en curso en el cumplimiento de los plazos; las puertas de calidad se convierten en teatro en vez de controles reales |
| Sin paridad de entorno de prueba | ⚠️ CI/CD valida en entornos con diferentes características de configuración, límites o datos que los de producción; pasar la validación no garantiza el éxito de la producción |
| Falta capacidad de reversión | ⚠️ Las oportunidades en curso automatizan la implementación pero no proporcionan reversión automatizada; la recuperación de una implementación incorrecta requiere procedimientos de emergencia manuales |
| Sin registros de implementación | ⚠️ Implementaciones ejecutadas sin registro integral; la solución de fallos o la auditoría de implementaciones se vuelve difícil |
| Pruebas de todo o nada | ⚠️ Oportunidades en curso ejecuta todas las pruebas para cada cambio independientemente de lo que cambió; el conjunto de pruebas de 30 minutos se ejecuta incluso para actualizaciones de documentación |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Indicadores de funciones | ✅ Los cambios de alto riesgo se implementan con funciones desactivadas detrás del tipo de metadatos personalizados o la configuración de parámetros personalizados; permite pruebas en producción sin exposición del usuario, implementación gradual en segmentos, pruebas A/B y reversión instantánea a través de cambios de configuración |
| Ámbito de indicador de función | ✅ Marcadores de funciones reservados para cambios de alto riesgo que afectan a procesos comerciales críticos, operaciones sensibles al rendimiento o nuevos patrones de integración; no todas las funciones necesitan marcas |
| Implementaciones canarias | ✅ Publicación de cambios críticos para el negocio en subconjuntos de usuarios pequeños primero (5-10% a través de conjuntos de permisos o filtrado de atributos de usuario); cohorte canaria supervisada intensivamente 24-48 horas midiendo índices de éxito, rendimiento, índices de error antes de ampliar la implementación |
| Ventanas de implementación | ✅ Implementaciones programadas durante periodos de bajo uso informadas por registros de uso de API de Supervisión de eventos que muestran patrones de tráfico reales; evita el uso máximo, cierre de fin de mes, cierre de fin de trimestre, eventos comerciales importantes |
| Comunicación de implementación | ✅ Las partes interesadas reciben notificación anticipada de plazos de implementación incluyendo duración prevista, funcionalidad afectada y cronología de decisión de reversión |
| Procedimientos de reversión | ✅ Procedimientos de reversión documentados y probados para cada tipo de implementación; el equipo puede ejecutar la reversión en menos de 30 minutos cuando sea necesario |
| Pruebas de reversión | ✅ Procedimientos de reversión validados en entornos que no son de producción antes de implementaciones significativas que garanticen la existencia de capacidad de recuperación |
| Validación de implementación | ✅ Las pruebas de humo posteriores a la implementación validan flujos de usuarios críticos, extremos de integración y funciones clave inmediatamente después de la versión |
| Coordinación de cambios | ✅ Estrategia de implementación coordinada cuando los cambios abarcan múltiples sistemas o requieren versiones sincronizadas entre Salesforce y plataformas externas |
| Supervisión durante la implementación | ✅ Supervisión mejorada activa durante el plazo de implementación y el periodo de observación posterior a la implementación (24-48 horas) vigilando picos de índice de error, degradación del rendimiento o fallos de flujo de usuarios |
| Patrón azul-verde para integraciones | ✅ Los servicios externos frente a Salesforce utilizan implementaciones de color verde azulado manteniendo dos entornos similares a los de producción, implementándose en inactivos primero, cambiando el tráfico después de la validación |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Implementaciones de Big Bang | ⚠️ Grandes versiones que contienen muchas funciones, refactorizaciones y cambios implementados simultáneamente sin implementación gradual; el fallo afecta a todos los usuarios de inmediato |
| Implementaciones de horas punta | ⚠️ Publicaciones programadas durante el horario laboral pico (mediodía, fin de mes, fin de trimestre) cuando el uso es más alto y el impacto de los problemas en los usuarios se maximiza |
| Sin plan de reversión | ⚠️ Las implementaciones se realizan sin procedimientos de reversión documentados y probados; cuando surgen problemas, el equipo se esfuerza por determinar la recuperación |
| Alternancias de funciones como pensamiento posterior | ⚠️ Indicadores de funciones agregados de forma reactiva cuando se producen problemas en vez de diseñados de forma proactiva para cambios de alto riesgo; limita las opciones de reversión a la reversión de implementación completa |
| Sin validación de implementación | ⚠️ Cambios implementados en producción sin pruebas de humo posteriores a la implementación; el equipo asume que la implementación se realizó con éxito y continúa; problemas descubiertos horas después por los usuarios |
| Procedimientos de reversión no probados | ⚠️ Procedimientos de reversión documentados pero nunca probados en no producción; durante el incidente real, el procedimiento falla o resulta inadecuado |
| Cambios simultáneos de múltiples sistemas | ⚠️ Cambios coordinados entre Salesforce y sistemas externos implementados sin pruebas de sincronización o compatibilidad; crea fallos de integración |
| Sin mejoras de supervisión | ⚠️ Las implementaciones se realizan sin supervisión mejorada durante el plazo de implementación; problemas detectados a través de quejas de usuarios en vez de alertas proactivas |
| Implementaciones de fin de semana | ⚠️ Principales versiones implementadas el viernes por la noche o los fines de semana cuando se reduce la cobertura a petición y se limita la disponibilidad de asistencia de proveedores |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Cobertura de prueba de unidad | ✅ Cobertura de prueba significativa que valida reglas comerciales, casos extremos, rutas de error y enfoque de límite regulador; supera significativamente el requisito mínimo del 75% |
| Calidad de prueba de unidad | ✅ Las pruebas validan la lógica comercial, no la funcionalidad de la plataforma; las pruebas de unidad bien escritas son rápidas (milisegundos), aisladas (sin estado compartido) y centradas (cada prueba valida un comportamiento) |
| Estrategia de datos de prueba | ✅ Las pruebas utilizan métodos @TestSetup para datos de prueba comunes; evite consultas SOQL en pruebas donde sea posible; utilice Test.loadData() para cargar recursos estáticos |
| Simular dependencias externas | ✅ Las pruebas de unidad se burlan de llamadas externas utilizando adaptadores de prueba e inyección de dependencias que permiten una ejecución rápida sin solicitudes HTTP reales |
| Pruebas de integración | ✅ Validar interacciones entre desencadenadores, flujos, eventos de plataforma, trabajos por lotes y llamadas externas que se ejecutan en entornos sandbox con datos de prueba representativos |
| Fiabilidad de prueba de integración | ✅ Las pruebas de integración son repetibles y deterministas; fallos esporádicos solucionados a través de mecanismos de sincronización como identificadores de reproducción de eventos de plataforma y sondeos de trabajos por lotes |
| Pruebas de extremo a extremo | ✅ Las pruebas de navegador automatizadas (Selenium, Playwright, Provar) validan trayectorias de usuario completas para flujos críticos para el negocio que ejercen el sistema a través de la interfaz de usuario exactamente como interactúan los usuarios |
| Enfoque de prueba de E2E | ✅ Las pruebas de E2E se centran en rutas de usuario de mayor valor debido a una ejecución más lenta (minutos por prueba) y una mayor carga de mantenimiento desde cambios en la interfaz de usuario |
| Pruebas de carga | ✅ Rendimiento validado bajo cargas de usuarios y volúmenes de datos simultáneos realistas utilizando servicios de prueba de carga de Salesforce o herramientas externas; revela problemas de límite regulador, contención de bloqueo, degradación del rendimiento |
| Frecuencia de prueba de carga | ✅ Las pruebas de carga se ejecutan antes de las versiones principales y periódicamente (trimestralmente) para validar el rendimiento a 3x-5x volúmenes de producción actuales |
| Pirámide de prueba | ✅ Distribución de pruebas equilibrada: muchas pruebas de unidad (cientos, minutos), menos pruebas de integración (docenas, minutos), pocas pruebas E2E (menos de 20, minutos); comentarios rápidos en base, validación integral en la parte superior |
| Aislamiento de prueba | ✅ Las pruebas no dependen entre sí; pueden ejecutarse en cualquier orden; cada prueba deja el sistema en estado limpio o utiliza @TestSetup para un punto de inicio coherente |
| Casos de prueba negativos | ✅ Las pruebas validan la gestión de errores, la aplicación de reglas de validación, la aplicación de permisos y la degradación elegante en condiciones adversas |
| Pruebas de límite regulador | ✅ Las pruebas validan específicamente el comportamiento que se acerca a los límites reguladores incluyendo límites de consulta SOQL, límites DML, tiempo de CPU, tamaño de pila |
| Ejecución de pruebas continua | ✅ Las pruebas se ejecutan automáticamente en cada confirmación a través de oportunidades en curso de CI/CD; las pruebas que fallan evitan la implementación en entornos superiores |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Pruebas de cobertura | ⚠️ Pruebas redactadas únicamente para alcanzar una cobertura mínima del 75% sin validar reglas comerciales o casos de borde; pruebas que no afirman nada o prueban rutas de código triviales |
| Funcionalidad de plataforma de prueba | ⚠️ Las pruebas validan que Salesforce guarda registros o consultas SOQL funcionan en vez de validar la lógica comercial; derrocha esfuerzo en garantías de plataforma |
| Sin estrategia simulada | ⚠️ Las pruebas de unidad realizan llamadas reales a sistemas externos; las pruebas son lentas, frágiles para la disponibilidad del sistema externo y consumen límites de API |
| Fallos de prueba esporádicos | ⚠️ Las pruebas pasan o fallan de forma impredecible basándose en el tiempo de ejecución, el estado de los datos o el orden de ejecución de las pruebas; los equipos aprenden a ignorar los fallos y a volver a ejecutar hasta que pasan las pruebas |
| Sin pruebas de integración | ⚠️ Solo existen pruebas de unidad; el equipo nunca valida que los desencadenadores, flujos, eventos de plataforma y trabajos por lotes funcionen correctamente |
| Solo pruebas manuales de E2E | ⚠️ Flujos de usuario críticos validados manualmente antes de cada versión; sin pruebas E2E automatizadas; regresiones descubiertas en producción cuando las pruebas manuales pierden escenarios |
| Pruebas sin carga | ⚠️ Rendimiento nunca validado bajo cargas simultáneas realistas; problemas de límite regulador, contención de bloqueo o degradación de rendimiento descubiertos en producción |
| Probar dependencias de datos | ⚠️ Las pruebas dependen de registros específicos existentes en la organización o asumen una configuración de usuario concreta; se interrumpen cuando se actualiza el entorno sandbox o cambia la configuración |
| Sin casos de prueba negativos | ⚠️ Las pruebas solo validan escenarios de rutas felices; nunca prueban la gestión de errores, la aplicación de validación o las comprobaciones de permisos; modos de fallo sin descubrir |
| Pruebas omitidas | ⚠️ Pruebas fallidas comentadas fuera de @isTest y omitidas en vez de corregidas; el conjunto de pruebas se degrada con el tiempo a medida que se ignoran más pruebas |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Revisar cobertura | ✅ Todos los cambios vinculados a producción fluyen a través de revisión de código a través de solicitudes de extracción que requieren aprobación antes de la combinación; incluye Apex, Aura, LWC, Flujos, reglas de validación, conjuntos de permisos, reglas de colaboración |
| Lista de comprobación de criterios de revisión | ✅ Lista de comprobación explícita que cubre la seguridad (aplicación de CRUD/FLS, validación de entrada), el rendimiento (masificación, optimización de SOQL), el cumplimiento del límite regulador (patrones de procesamiento, prevención de recursividad), la mantenibilidad (nomenclatura, documentación, complejidad), la cobertura de pruebas (pruebas significativas, casos extremos), la coherencia arquitectónica (patrones de diseño, separación de preocupaciones) |
| Revisar límites de tamaño | ✅ Extraer solicitudes mantenidas por debajo de 400 líneas de cambios significativos que permiten una revisión minuciosa; grandes funciones divididas en cambios incrementales más pequeños que son revisables individualmente e implementables de forma independiente |
| Revisar tiempo | ✅ Revisiones completadas en un día hábil manteniendo el impulso del desarrollo y proporcionando comentarios rápidos; las revisiones demoradas crean gastos generales de cambio de contexto |
| Comprobaciones previas a la revisión automatizadas | ✅ Análisis estático, pruebas de unidad y análisis de seguridad se ejecutan automáticamente antes de que se solicite la revisión humana; las comprobaciones automatizadas detectan problemas mecánicos de modo que los revisores se centran en el diseño y la lógica comercial |
| Responsabilidad de revisión distribuida | ✅ Responsabilidad de revisión de código distribuida entre el equipo evitando cuellos de botella y compartiendo Knowledge; los desarrolladores jóvenes revisan el código senior y explican su propio código durante las revisiones |
| Calidad de comentarios de revisión | ✅ Los revisores proporcionan comentarios específicos sobre los que se pueden realizar acciones con justificación; distinguen entre cambios requeridos (problemas de bloqueo) y sugerencias (mejoras agradables) |
| Revisar documentación | ✅ Las descripciones de solicitudes de extracción explican qué cambió, por qué cambió, qué pruebas se realizaron y cualquier consideración de implementación especial o procedimiento de reversión |
| Revisión de configuración declarativa | ✅ Los flujos, las reglas de validación y los cambios de permisos reciben el mismo rigor de revisión que el código; la configuración es arquitectónica y merece escrutinio |
| Seguimiento de comentarios | ✅ Todos los comentarios de revisión tratados antes de la combinación; preguntas respondidas, cambios implementados o justificación proporcionada de por qué no se adoptó la sugerencia |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Sin revisión de código | ⚠️ Cambios confirmados directamente en la rama de producción sin ninguna revisión por pares; elimina el mecanismo de detección de defectos primarios |
| Estampado de goma | ⚠️ Los revisores aprueban solicitudes de extracción en cuestión de segundos sin examinar realmente cambios; la revisión se convierte en cumplimiento de casillas de verificación en vez de puerta de calidad |
| Cuello de botella de un solo revisor | ⚠️ Solo un desarrollador superior autorizado para revisar el código; crea cuello de botella y punto único de fallo; Knowledge concentrado en vez de distribuido |
| Solicitudes de extracción masiva | ⚠️ Extraer solicitudes que contienen miles de líneas de cambios que abarcan múltiples funciones; imposible de revisar minuciosamente lo que lleva a un examen superficial |
| Revisiones demoradas | ⚠️ Las solicitudes de extracción no se revisan durante días o semanas; los desarrolladores pierden contexto y pasan a otro trabajo; los comentarios de revisión llegan cuando el desarrollador cambió el contexto mental |
| Sin criterios de revisión | ⚠️ El equipo carece de criterios explícitos para lo que los revisores deben examinar; la calidad de la revisión varía enormemente según el revisor; algunos revisores se centran en el estilo, otros en la lógica, ninguno integral |
| Revisar sin pruebas | ⚠️ Los revisores aprueban cambios basándose solo en la inspección de código sin extraer la bifurcación y las pruebas localmente o validar el paso de pruebas automatizadas |
| Comprobaciones automatizadas ignoradas | ⚠️ Los revisores aprueban solicitudes de extracción a pesar de fallar el análisis estático, los análisis de seguridad o las pruebas de unidad; frustra el propósito de puertas de calidad automatizadas |
| Cultura de revisión hostil | ⚠️ Las revisiones se convierten en crítica personal o ejercicio competitivo en vez de mejora de calidad colaborativa; desincentiva el aprendizaje y la seguridad psicológica |
| Sin revisión declarativa | ⚠️ Los flujos, las reglas de validación, los conjuntos de permisos y las reglas de colaboración se implementan sin revisión mientras el código Apex recibe escrutinio; crea brechas de calidad en la configuración declarativa |