Alcance y condiciones del despliegue
Antes de iniciar una integración conviene dejar claros algunos límites. Estas notas definen qué entendemos por soporte, qué queda fuera del alcance y cómo se manejan los casos que dependen de terceros o de tu propia infraestructura.
¿Qué se considera un despliegue asistido?
Un despliegue asistido cubre la instalación y configuración inicial de los conectores, el middleware y las plantillas de contenedores que compartimos en el foro. Incluye la verificación de conectividad con los endpoints declarados y la validación de los primeros mensajes de prueba. No incluye la adaptación de lógica de negocio propia de tu organización ni el desarrollo de conectores a medida.
¿Qué responsabilidades quedan del lado del equipo interno?
El equipo interno debe garantizar acceso a los entornos de desarrollo y prueba, credenciales válidas para los sistemas de origen y destino, y disponibilidad de los puertos y dominios necesarios. También es responsable de mantener las políticas de seguridad de su red y de aprobar los cambios de esquema antes de que se apliquen en producción. Sin estas condiciones, cualquier plan de implementación pierde validez.
¿Cómo se manejan los incidentes durante la puesta en marcha?
Los incidentes se clasifican por impacto y se resuelven en el orden que establece el plan de contingencia acordado al inicio. Los problemas de configuración propios del despliegue se atienden directamente. Los fallos originados en servicios externos, como proveedores de nube o APIs de terceros, se documentan y se escalan al responsable correspondiente. No asumimos tiempos de resolución sobre componentes que no controlamos.
¿Qué pasa si el entorno productivo difiere del entorno de prueba?
Si las características del entorno productivo no coinciden con lo declarado en la etapa de planificación, el despliegue se detiene hasta que se ajusten las variables. Esto incluye versiones de sistema operativo, políticas de red, límites de memoria o restricciones de seguridad. Preferimos pausar y corregir antes de forzar una configuración que pueda generar inconsistencias en los datos.
¿Cómo se gestionan las versiones de esquemas y las migraciones?
Las migraciones de esquema se versionan y se aplican en orden ascendente. Cada cambio se registra con un identificador único y una descripción del impacto esperado. Las migraciones destructivas, como eliminación de columnas o tablas, requieren aprobación explícita y una copia de seguridad verificada antes de ejecutarse. No aplicamos cambios de esquema directamente en producción sin una ventana de mantenimiento acordada.
¿Qué ocurre con las pruebas de carga y los límites de rendimiento?
Las pruebas de carga se ejecutan con escenarios definidos previamente y sobre entornos que no interfieran con el tráfico real. Los resultados se comparan contra los umbrales de latencia y tasa de error que se fijan al inicio del proyecto. Si los valores superan los límites aceptables, se entrega un informe con las recomendaciones de ajuste, pero la ampliación de infraestructura queda fuera del alcance del despliegue inicial.
