Gestionar desarrollo, pruebas y producción

Publicado el 2026-10-07 · Actualizado el 2026-10-07

Gestionar desarrollo, pruebas y producción exige definir el propósito, los datos y las conexiones de cada entorno. Comprueba una versión identificable con ajustes revisados y examina el resultado real después de publicarla.

Identifica los entornos disponibles

Enumera los entornos que realmente existen. Usa desarrollo para trabajo activo, pruebas para revisar una versión candidata y producción para uso real. Registra dirección, responsable, versión activa y forma de reconocer cada uno. Muestra una identificación visible en pruebas para evitar confusión con la aplicación pública. Si solo hay una vista previa, explica qué permite comprobar y qué no demuestra. No la consideres automáticamente un entorno independiente con todos sus recursos separados. El equipo necesita conocer dónde actúa y qué puede afectar.

Elige un recorrido de revisión, como crear una solicitud de servicio, mostrarla y cambiar su estado. Define punto de partida, ejemplos y persona que comprobará el resultado. Con Infera Agent, verifica opciones de vista previa, publicación y recursos antes de organizar el plan. No supongas que existe un botón de transferencia o duplicación. Sin entorno independiente, diseña una prueba limitada con las posibilidades reales y documenta sus límites. Una revisión útil distingue comportamiento visible de resultados que todavía requieren comprobación en otra ubicación o con una configuración diferente.

• Enumera entornos y direcciones reales.
• Registra propósito, responsable y versión.
• Define límites de las pruebas.

Revisa ajustes y datos antes de probar

Prepara una lista por entorno: fuente de datos, destinos de servicios, dirección de retorno y acceso del equipo. Examina valores utilizados por el proyecto, no una nota antigua. La configuración puede variar entre despliegues y separarse del código mediante variables de entorno según el diseño. Referencia: https://www.12factor.net/config . Registra nombre, propósito y responsable sin copiar valores secretos. Comprueba valores ausentes y comportamiento antes del recorrido completo. La lista orienta la inspección; rellenarla no establece por sí solo que la configuración activa sea correcta.

Prepara ejemplos de estados necesarios: solicitud nueva, en proceso y terminada, con texto largo o información ausente si importa. Confirma destino de guardado y cuenta que ve los registros. Los ejemplos bien diseñados suelen bastar sin copiar datos de clientes. Para mensajes o conexiones externas, escribe el destino esperado y comprueba el resultado. Una etiqueta de prueba no demuestra que todas las conexiones usen destinos de prueba. Inspecciona la operación y guarda su referencia para distinguir una muestra visible de su almacenamiento y posibles efectos externos.

• Examina los ajustes realmente usados.
• Comprueba guardado y destinos externos.
• Prepara casos definidos con claridad.

Comprueba una versión y documenta diferencias

Relaciona revisión con versión o cambio identificable. Los entornos pueden ejecutar versiones diferentes del mismo proyecto; referencia: https://12factor.net/codebase . Define modificación y criterios antes de probar. Para servicio, comprueba un registro, visibilidad para la cuenta prevista y actualización de estado sin cambios ajenos. Prueba entrada incompleta, regreso y reapertura. Guarda resultados con versión y entorno para no usar observaciones antiguas como evidencias de una versión reciente. Conserva caso y expectativa juntos, en lugar de una afirmación de éxito sin contexto verificable.

Compara factores relevantes entre pruebas y producción. Reducir diferencias limita brechas de comprobación; referencia: https://www.12factor.net/dev-prod-parity . No afirmes igualdad sin inspección. Datos, conexiones o usuarios pueden variar. Indica lo no comprobado de forma realista y qué requiere seguimiento al publicar. Si cambia la versión durante la revisión, repite los casos afectados. Un éxito anterior no valida un cambio nuevo porque el nombre o aspecto sea parecido. Documenta la decisión sobre cada diferencia importante para que el equipo entienda qué resultados pueden trasladarse y cuáles necesitan otra revisión.

• Relaciona versión, entorno y resultado.
• Comprueba recorrido y datos guardados.
• Registra diferencias y límites.

Publica y revisa el resultado en producción

Prepara un registro breve: versión prevista, ajustes revisados, pruebas y responsable de seguimiento. Distingue preparación, asociación con configuración y ejecución; referencia: https://www.12factor.net/build-release-run . Usa pasos disponibles sin inventar botones. Después comprueba dirección, versión, recorrido principal y resultado guardado. Una página que abre no demuestra operación correcta. Revisa mensaje, estado y destinos asociados. Elige una comprobación apropiada que no genere accidentalmente solicitudes reales ni efectos externos indeseados. La prueba debe demostrar el comportamiento, no producir nuevos casos confusos que el equipo tenga que investigar.

Define actuación ante problemas: quién evalúa, dónde están las evidencias y cómo limitar el efecto o volver a una versión adecuada. Volver a una versión no restaura necesariamente datos anteriores; comprueba compatibilidad con registros actuales. Separa tratamiento de información afectada y corrección del comportamiento futuro. Registra decisiones, resultados y límites de seguimiento, y actualiza la lista de entornos. El equipo debe conocer qué funciona ahora y qué necesita observación, en lugar de depender de la memoria de una sola persona. La vuelta también necesita comprobaciones de resultado.

• Comprueba versión y recorrido en producción.
• Separa vuelta de versión y reparación de datos.
• Registra decisiones y seguimiento.

Preguntas

Empieza gratis Plantillas