Resumen: ¿Hay algún problema con cargar contenido directamente en producción? Esto no es un cambio de código ni de funcionalidad. Sólo edición/adición de contenido. Actualmente utilizamos 4 servidores para hacer esto, es un poco complicado. Para más detalles, lea a continuación.
Acabo de heredar una red de PYMES que tiene todo tipo de idiosincrasias. Una de esas idiosincrasias es desconcertante por su complejidad. Estoy bastante seguro de que es como una máquina de Rube-Goldberg, pero quiero estar seguro.
Tenemos una aplicación cliente/servidor que utiliza un servidor de aplicaciones basado en IIS. Este servidor de aplicaciones media la GUI web y una conexión de base de datos, que en nuestro caso está alojada en otro servidor (MSSQL2005). Hay archivos .tif que se cargan a través de esta aplicación y se almacenan en la base de datos como un blob. También hay datos que crean una máscara sobre la imagen (para que pueda crear formularios poblados). También alojamos un servidor público que actúa como depósito de estas imágenes/máscaras para que otros no tengan que crearlas manualmente.
Bien, ¿conmigo hasta ahora? Básicamente, el archivo .tif y los datos van en un extremo y en el otro extremo, el público puede descargar esta imagen/datos.
Aquí está la parte extraña. En lugar de que nuestros usuarios carguen estas imágenes completas (y sometidas a control de calidad) directamente en producción, las ingresan en un servidor interno. Luego, un proceso extrae el blob y recrea el archivo .tif. Este proceso también extrae sólo los datos necesarios para los formularios. Luego pasa a un servidor provisional. Este servidor de prueba es un duplicado del servidor de producción, pero en realidad nunca usamos esta parte, excepto para este proceso. Una vez en preparación, se ejecuta otra tarea para finalmente replicar la imagen y los datos en el servidor de producción. Sin embargo, el servidor provisional se utiliza para el desarrollo web. Si algo sucede, puede romper esta cadena de eventos y detener las replicaciones.
También vale la pena señalar que se realiza una copia de seguridad de este servidor de producción con regularidad, por lo que la preparación no está destinada a la recuperación ante desastres. El servidor provisional tampoco es público de ninguna manera, por lo que no se utiliza para redundancia. Está ahí simplemente.
Para colmo de males, estas tareas parecen realizarse con scripts vbs, archivos bat y tareas programadas de Windows, en lugar de cualquier tipo de tarea/activador de SQL Server.
Mi pregunta es "¿es todo esto necesario?" ¿Por qué no se puede configurar un activador en el servidor SQL original para actualizar el servidor de producción cada vez que un indicador de control de calidad se establece en verdadero? ¿Por qué pasar por todas estas copias? ¿Hay alguna razón por la que me falta?
Sólo quiero asegurarme de que estoy haciendo lo correcto para arreglar nuestra red.
Gracias por leer.
Respuesta1
Siento el fétido rastro de la pereza. Supongo que en algún momento durante el proceso de desarrollo de esta aplicación en particular, algo no funcionó. O mejor dicho, funcionó en Puesta en Escena pero no en Producción. Y para que las cosas funcionenahora mismoConectaron el servidor de prueba a producción de la manera que mencionas. Lo cual hizo. Y como estaba funcionando, quien no se molestó en intentar averiguar por qué no funcionaba y simplemente lo dejó.
Entra tú.
¿Por qué es así? Porque funciona.
¿Cómo llegó a ser así? Desconocido, pero supongo que algo roto fue una parte clave de por qué llegó a ser así.
Siéntete libre de solucionar estobienforma.