Aquí podría ser tu PUBLICIDAD


Mantener las pruebas y los entornos del servidor de producción limpios, sincronizados y consistentes

votos
16

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 con los servidores de prueba y 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, por lo tanto, modificamos 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, lo que hace que nuestros ajustes y configuraciones sean inútiles. La parte más frustrante es que esto sucede todo el tiempo y que nadie parece saber qué hacer al respecto.

Por supuesto, tenemos una idea general de por qué sucede esto. Cada entorno clonado comienza igual y funciona igual los primeros días, pero tarde o temprano alguien reconfigura algo solo en uno de los entornos del servidor (ya sea una actualización de la base de datos, una biblioteca de componentes, una actualización de un archivo web, u otras configuraciones), lo que conduce a discrepancias. Y a medida que pasa el tiempo, aumentan las discrepancias. Pero la pregunta es: ¿qué podemos hacer al respecto?

Intenté buscar en la web, pero no puedo encontrar una buena respuesta 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 deberíamos hacer sobre este problema? ¿Cómo podemos garantizar que la experiencia de las pruebas coincida con la experiencia cuando se lanza?

Me imagino que otros también tienen este mismo problema. ¿O ellos? Tal vez es solo mi empresa particular que es incompetente? ¿Alguno de ustedes ha encontrado el problema? Si es así, ¿qué hiciste al respecto?

Sinceramente,

Linus, desarrollador de sistemas sueco

Publicado el 12/03/2009 a las 18:33
fuente por usuario Linus
En otros idiomas...        العربية       

5 respuestas

votos
6

Debe comenzar a realizar un seguimiento de cada cambio que realice en el entorno de prueba y proporcionar una forma de propagar esto al entorno de producción.

Para el código , esto significa un sistema de control de versiones como CVS, Subversion o GIT.

Para la base de datos , significa una herramienta de comparación de estructuras o implementar scripts que actualizan la base de datos de producción.

Para la configuración , los dos sistemas deben ser exactamente iguales y cualquier 'ajuste' o cambio 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, continuará teniendo problemas.

Respondida el 12/03/2009 a las 06:40
fuente por usuario jonstjohn


Aquí podría ser tu PUBLICIDAD


votos
0

Para mantener las bases de datos de MySQL en sincronía, me acabo de encontrar con esta herramienta:

http://schemasync.org/

No he utilizado realmente todavía, así que no puedo hablar de si se trata de ningún bien, pero necesitamos alguna manera de controlar la deriva entre esquema de prueba y prod así que vamos a darle un tiro.

Respondida el 02/06/2011 a las 12:05
fuente por usuario Willie Wheeler

votos
0

Por supuesto, tenemos una idea general de por qué sucede esto. Cada entorno clonado comienza de la misma manera y funciona igual 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. Por lo general, las tiendas que no necesitan subcontratar para el trabajo de desarrollo no entienden realmente el proceso de desarrollo. Si le proporcionan un entorno de prueba, lo que obtendrá es un sistema de producción anterior a la última actualización del servidor.

Respondida el 13/03/2009 a las 04:10
fuente por usuario Joel Coehoorn

votos
0

Tus problemas son bastante normales. Hay al menos dos estrategias que sé que funcionan bastante bien:

Si está distribuyendo en Linux, puede construir rpms / debs desde su proceso de desarrollo y usar la función de gestión de paquetes. Sé que muchos proyectos lo hacen con gran éxito para proyectos internos.

Otra alternativa es empaquetar todo el entorno como algún tipo de script de shell. Este script de shell puede / debe configurar el entorno completo con todas las configuraciones. Normalmente este script se mantiene mediante develeopment, y este script sobrescribe cualquier modificación que se haya realizado manualmente. Un script como este generalmente se mantiene mediante desarrollo, se mantiene bajo el control de la versión y se envía a la implementación como una distribución completa. Usamos cygwin para esto. Normalmente, la secuencia de comandos lee algún tipo de configuración que puede ser administrada por las operaciones. He tenido scripts que realmente configuraron 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. Cuanto más suave sea este proceso, mejor para todas las partes involucradas.

Respondida el 12/03/2009 a las 06:41
fuente por usuario krosenvold

votos
0

Debe asegurarse de que los cambios en los entornos se realicen de forma coherente.

Consideraría comenzar con imágenes nuevas y aplicar una estricta política de registro de modificaciones, o usar algo como Capistrano para ejecutar comandos remotos e implementar código en todas las máquinas simultáneamente.

Idealmente, todos los requisitos deben verificarse en su sistema de control de versiones (en la línea de cómo Rails le permite almacenar gemas en el directorio / vendor y preferentemente los carga 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.

Respondida el 12/03/2009 a las 06:37
fuente por usuario Jarin Udom