Excelencia operativa - Patrones de DevOps
Obtenga más información acerca de Excelencia operativa bien arquitecta → Prácticas de DevelopOps
Patrones
| Dónde buscar | Qué 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 tras la finalización de funciones |
| 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:“) |
| Seguimiento de cambios | ✅ 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 a través de 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 troncos) 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ó al principio del ciclo de vida de la solución antes de que los hábitos se solidifiquen en torno al desarrollo basado en la organización |
| Configuración de .gitignore | ✅ El repositorio excluye archivos generados, configuraciones específicas de 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 a control de versiones como pensamiento 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 riesgo 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é; dificulta las investigaciones de auditoría y el mantenimiento futuro |
| Confirmaciones poco frecuentes de gran tamaño | ⚠️ Los desarrolladores confirman grandes conjuntos de cambios semanalmente en vez de pequeñas confirmaciones incrementales varias veces al día; fallos difíciles de revisar y aislar |
| Confirmar directamente con principal | ⚠️ Los desarrolladores envían los cambios directamente a la bifurcación 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 arbitrarios y patrones de combinación; crea confusión y conflictos de combinación |
| Archivos binarios en Git | ⚠️ Archivos binarios de gran tamaño (PDF, videos, archivos) comprometidos con el tamaño del repositorio Git y ralentizando las operaciones de duplicación |
| Credenciales de confirmación | ⚠️ 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 | ⚠️ Combinar conflictos 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 pasan por |
Patrones
| Dónde buscar | Qué aspecto tiene |
|---|---|
| Sandboxes de desarrollador | ✅ Los desarrolladores individuales utilizan sandboxes de desarrollador para el trabajo de funciones, pruebas de unidades 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 sandboxes 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 | ✅ Las pruebas de desempeño, la puesta en escena similar a la producción y la validación de migración de datos utilizan sandboxes de copia completa que contienen datos de producción completos y configuración |
| Controles de confidencialidad 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 no 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 sandboxes |
| Configuración específica del entorno | ✅ La arquitectura de integración utiliza tipos de metadatos personalizados o parámetros personalizados para externalizar direcciones URL de extremos, credenciales e indicadores de funciones 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, siembra de datos de prueba, estados de indicador de función y capacidad de entrega de email |
| Actualizar programación | ✅ Programación de actualización de sandbox documentada y comunicada; actualizaciones planificadas durante periodos de baja actividad para minimizar las interrupciones 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 |
| Convenciones 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 los demás; crea confusión acerca de qué es el estado implementable |
| Sandboxes obsoletos | ⚠️ Sandboxes no actualizados durante meses que 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 posterior a la actualización manual | ⚠️ Las actualizaciones de sandbox requieren horas de reconfiguración manual restaurando los parámetros; la sobrecarga desalienta la actualización de 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 la estrategia de entorno sandbox apropiada por actividad |
| Acaparamiento de sandbox | ⚠️ Sandboxes asignados a individuos 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 extremos); las pruebas en entornos poco realistas no tienen problemas de producción |
Patrones
| Dónde buscar | Qué 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 busca vulnerabilidades de seguridad en Apex (OWASP Top 10), antipatrones de desempeño (SOQL en bucles, DML en bucles), problemas de calidad de código (complejidad, duplicación) y riesgos de límite regulador; se ejecuta en segundos proporcionando comentarios inmediatos |
| Etapa de prueba de unidad | ✅ Las pruebas Apex ejecutan la validación de la lógica de negocio y el regulador limitan el cumplimiento en organizaciones borrador efímeras o sandbox de integración exclusivo; las pruebas aisladas correctamente 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 indicador –checkonly para implementación solo de validación que ejecuta 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 CRUD/FLS e infracciones de la política de cumplimiento; las compilaciones de fallos de hallazgos críticos |
| Etapa de implementación de UAT | ✅ Los cambios que pasan todas las puertas automatizadas se implementan en el entorno de pruebas de aceptación de usuarios para la validación de negocio; 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 con 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 | ✅ Canalizaciones mantiene paquetes de implementación, resultados de pruebas, reportes de análisis de seguridad y registros de ejecución para el cumplimiento y la solución de problemas |
| Herramientas de oportunidades en curso | ✅ 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 oportunidades en curso desencadenan notificaciones para confirmar los canales de autor y relevantes con contexto de diagnóstico que permite una solución rápida |
| Protección de sucursal | ✅ Ramas principales/de producción protegidas que requieren pasar comprobaciones de CI y revisiones aprobadas antes de la combinación; se evitan las confirmaciones directas |
| Promoción del 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 omitidos, 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 desempeño, 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 exploración de seguridad | ⚠️ Las oportunidades en curso nunca buscan credenciales codificadas, dependencias vulnerables o infracciones CRUD/FLS; problemas de seguridad descubiertos en revisiones de producción o seguridad |
| Ejecución lenta de oportunidades en curso | ⚠️ 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 oportunidades en curso ignorados | ⚠️ Los equipos ignoran o sustituyen fallos de oportunidades en curso para cumplir 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 características de datos, límites o configuración diferentes a los de producción; pasar la validación no garantiza el éxito de la producción |
| Falta capacidad de reversión | ⚠️ Canalizaciones automatiza la implementación pero no proporciona 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; solucionar fallos o auditar implementaciones se vuelve difícil |
| Pruebas de todo o nada | ⚠️ Canalizaciones 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é aspecto tiene |
|---|---|
| Marcadores de funciones | ✅ Los cambios de alto riesgo se implementan con funciones desactivadas detrás del tipo de metadatos personalizados o la configuración personalizada; permite realizar pruebas en producción sin exposición del usuario, implementación gradual en segmentos, pruebas A/B e implementación instantánea a través del cambio de configuración |
| Ámbito de indicador de función | ✅ Marcadores de funciones reservados para cambios de alto riesgo que afectan a procesos de negocio críticos, operaciones sensibles al desempeño o nuevos patrones de integración; no todas las funciones necesitan marcas |
| Implementaciones canarias | ✅ La versió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 monitoreada intensivamente de 24 a 48 horas midiendo índices de éxito, desempeño, í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 Event Monitoring mostrando patrones de tráfico reales; evita el uso máximo, cierre de fin de mes, cierre de fin de trimestre, eventos de negocio 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 garantizando la existencia de capacidad de recuperación |
| Validación de implementación | ✅ Las pruebas de humo posteriores a la implementación validan flujos de usuario 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 |
| Monitoreo durante la implementación | ✅ Monitoreo mejorado activo durante el plazo de implementación y el periodo de observación posterior a la implementación (24-48 horas) vigilando picos de índices de error, degradación del desempeño o fallos de flujos de usuarios |
| Patrón azul-verde para integraciones | ✅ Los servicios externos que encabezan 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 inmediatamente |
| Implementaciones de horas punta | ⚠️ Lanzamientos programados durante las horas de oficina pico (mediodía, fin de mes, fin de trimestre) cuando el uso es más alto y la repercusión de los problemas en los usuarios se maximiza |
| Sin plan de reversión | ⚠️ Las implementaciones continúan sin procedimientos de reversión documentados y probados; cuando surgen problemas, el equipo se esfuerza por averiguar 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 completa de la implementación |
| 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 de múltiples sistemas simultáneos | ⚠️ Cambios coordinados entre Salesforce y sistemas externos implementados sin pruebas de sincronización o compatibilidad; crea fallos de integración |
| Sin mejoras de monitoreo | ⚠️ Las implementaciones se realizan sin monitoreo mejorado 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 | ⚠️ Versiones principales 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é aspecto tiene |
|---|---|
| Cobertura de prueba de unidad | ✅ Cobertura de prueba significativa validando reglas de negocio, 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 de negocio, no la funcionalidad de la plataforma; las pruebas de unidad bien redactadas 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 simulan llamadas externas utilizando código auxiliar 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 de 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 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 | ✅ Desempeño validado bajo cargas de usuarios y volúmenes de datos simultáneos realistas utilizando servicios de pruebas de carga de Salesforce o herramientas externas; revela problemas de límites reguladores, bloqueo de contención, degradación del desempeño |
| Frecuencia de prueba de carga | ✅ Las pruebas de carga se ejecutan antes de las versiones principales y periódicamente (trimestralmente) para validar el desempeño a volúmenes de producción 3x-5x 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 la base, validación integral en la parte superior |
| Probar aislamiento | ✅ 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 límites reguladores incluyendo límites de consultas 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 fallidas 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 de negocio o casos extremos; pruebas que no afirman nada o prueban rutas de código triviales |
| Funcionalidad de plataforma de pruebas | ⚠️ Las pruebas validan que Salesforce guarda registros o consultas SOQL funcionan en vez de validar lógica de negocio; desperdicia 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 pruebas 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 volver a ejecutarse hasta que pasan las pruebas |
| Sin pruebas de integración | ⚠️ Solo existen pruebas de unidad; el equipo nunca valida que desencadenadores, flujos, eventos de plataforma y trabajos por lotes funcionen correctamente juntos |
| Solo pruebas manuales de E2E | ⚠️ Flujos de usuario críticos validados manualmente antes de cada versión; no hay pruebas E2E automatizadas; se descubren regresiones en producción cuando las pruebas manuales pierden escenarios |
| Pruebas sin carga | ⚠️ Desempeño nunca validado bajo cargas simultáneas realistas; problemas de límite regulador, bloqueo de contención o degradación de desempeño 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é aspecto tiene |
|---|---|
| Revisar cobertura | ✅ Todos los cambios vinculados a la producción fluyen a través de la 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 Revisar criterios | ✅ Lista de comprobación explícita que cubre la seguridad (aplicación de CRUD/FLS, validación de entrada), el desempeño (masificación, optimización SOQL), el cumplimiento de límites reguladores (patrones de procesamiento, prevención de recursividad), la capacidad de mantenimiento (nombre, 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 exhaustiva; 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 retrasadas crean gastos generales de cambio de contexto |
| Comprobaciones previas a la revisión automatizadas | ✅ El análisis estático, las pruebas de unidad y la exploración 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 de negocio |
| 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 junior revisan 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; distinguir 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 abordados antes de la combinación; preguntas respondidas, cambios implementados o justificación 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 bifurcación de producción sin ninguna revisión por pares; elimina el mecanismo de detección de defectos principal |
| Sellado de goma | ⚠️ Los revisores aprueban solicitudes de extracción en cuestión de segundos sin examinar cambios en realidad; 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 un cuello de botella y un punto único de fallo; Knowledge concentrado en vez de distribuido |
| Solicitudes de extracción masivas | ⚠️ 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 permanecen sin revisar durante días o semanas; los desarrolladores pierden contexto y pasan a otro trabajo; los comentarios de revisión llegan cuando el desarrollador ha cambiado de 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 por revisor; algunos revisores se centran en el estilo, otros en la lógica, ninguno integral |
| Revisar sin pruebas | ⚠️ Los revisores aprueban cambios basándose únicamente en la inspección de código sin extraer la bifurcación y probar localmente o validar que las pruebas automatizadas pasan |
| Comprobaciones automatizadas ignoradas | ⚠️ Los revisores aprueban solicitudes de extracción a pesar de fallar el análisis estático, las exploraciones de seguridad o las pruebas de unidades; 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; desalienta 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 |