synchronization - Mantener los entornos de servidor de prueba y producción limpios, sincronizados y consistentes
production-environment consistency (5)
Por supuesto que tenemos una idea general de por qué sucede esto. Todos los entornos clonados comienzan de la misma manera y funcionan igual durante los primeros días, pero tarde o temprano alguien reconfigura algo en solo uno de los entornos de servidor.
Creo que estás siendo generoso, o has tenido mucha suerte. En la medida en que no las tiendas que necesitan contratar un trabajo de desarrollo no entienden realmente el proceso de desarrollo. Si le proporcionan un entorno de prueba, todo lo que obtendrá será su sistema de producción anterior a la última actualización del servidor.
Parece que la empresa para la que trabajo siempre está luchando con los entornos de servidor de nuestros clientes .
Específicamente, casi siempre encontramos problemas al probar servidores y servidores de producción, y el hecho de que siempre parecen estar configurados de manera diferente. Cuando probamos las aplicaciones que desarrollamos, los servidores de prueba se comportan de una manera, y así ajustamos y configuramos nuestras aplicaciones para que se ajusten a ese comportamiento en particular. Pero cuando instalamos la misma aplicación en los servidores de producción observamos otro comportamiento que no es consistente con los servidores de prueba, por lo que inutilizamos nuestros ajustes y configuraciones. La parte más frustrante es que esto sucede todo el tiempo y que nadie parece saber qué hacer al respecto.
Por supuesto que tenemos una idea general de por qué sucede esto. Todos los entornos clonados comienzan de la misma manera y funcionan igual los primeros días, pero tarde o temprano alguien reconfigura algo en uno solo de los entornos de servidor (ya sea una actualización de la base de datos, una actualización de una biblioteca de componentes, una actualización de archivos web, u otras configuraciones), lo que lleva a la discrepancia. Y a medida que pasa el tiempo, se acumulan más y más discrepancias. Pero la pregunta es: ¿qué podemos hacer al respecto?
He intentado buscar en la web, pero no puedo encontrar buenas respuestas sobre qué hacer. También intenté encontrar algunas soluciones por mi cuenta, pero la mayoría de mis ideas parecen ser problemáticas de alguna manera. Las nuevas rutinas, sin importar cuán rigurosas sean, pueden ser eludidas. La clonación regular de los servidores de producción para crear servidores de prueba es un proceso tedioso y a menudo muy lento. La replicación automática no siempre es confiable o incluso posible. Entonces, ¿qué diablos debemos hacer con este problema? ¿Cómo podemos garantizar que la experiencia cuando se realicen las pruebas coincidirá con la experiencia cuando se publique?
Me imagino que otros también tienen este mismo problema. ¿O ellos? Tal vez es solo mi compañía en particular que es incompetente? ¿Alguno de ustedes ha encontrado el problema? Si es así, ¿qué hiciste al respecto?
Sinceramente,
Linus, desarrollador de sistemas sueco.
Debe asegurarse de que los cambios en los entornos se realicen de manera coherente.
Consideraría comenzar con imágenes nuevas y aplicar una política de registro de modificación estricta, o usar algo como Capistrano para ejecutar comandos remotos e implementar código en todas las máquinas simultáneamente.
Lo ideal sería que todos los requisitos se verifiquen en su sistema de control de versiones (siguiendo las líneas de cómo Rails le permite almacenar gemas en el directorio / proveedor y las carga preferentemente en tiempo de ejecución), junto con un archivo Léame que describe exactamente cómo configurar el entorno. (bibliotecas requeridas, etc). El archivo Léame debe ser actualizado rigurosamente por cualquier persona que realice cambios en el entorno.
Debe comenzar a realizar un seguimiento de cada cambio que realice en el entorno de prueba y proporcionar una manera de propagarlo al entorno de producción.
Para el código , esto significa un sistema de versiones como CVS, Subversion o GIT.
Para la base de datos , significa una herramienta de comparación de estructuras o implementa scripts que actualizan la base de datos de producción.
Para la configuración , los dos sistemas deben ser exactamente iguales y cualquier ''cambio'' o cambio necesario debe aplicarse primero al servidor de prueba y luego aplicarse al servidor de producción durante una implementación.
Hasta que tenga un proceso que funcione, seguirá teniendo problemas.
Para mantener sincronizadas las bases de datos MySQL, acabo de encontrar esta herramienta:
En realidad no lo he usado todavía, así que no puedo hablar sobre si es bueno, pero necesitamos alguna forma de controlar la deriva del esquema entre la prueba y la punción, así que vamos a darle una oportunidad.
Tus problemas son bastante normales. Hay al menos dos estrategias que sé que funcionan bastante bien:
Si está distribuyendo en Linux, puede crear rpms / debs a partir de su proceso de desarrollo y usar la función de administración de paquetes. Sé que muchos proyectos hacen esto con gran éxito para proyectos internos.
Otra alternativa es empaquetar todo el entorno como una especie de script de shell. Este script de shell puede / debe configurar el entorno completo con todas las configuraciones. Normalmente esta secuencia de comandos se mantiene por desarrollo, y esta secuencia sobrescribe cualquier modificación que se haya realizado manualmente. Un script como este generalmente se mantiene mediante el desarrollo, se mantiene bajo el control de versiones y se envía a la implementación como una distribución completa. Usamos cygwin para esto. Normalmente, el script lee algún tipo de configuración que puede ser administrada por las operaciones. He tenido scripts que realmente configuran todo el sistema desde cero, como si se instalara en una máquina totalmente vacía y recién instalada.
Ambas estrategias deberían incluir preferiblemente la producción automatizada de estos artefactos desde su sistema de script / compilación de compilación. Cuanto más suave sea el proceso, mejor será para todas las partes involucradas.