Sugerencia de implementación del sitio PHP [Cerrado

Question

Actualmente estoy bastante preocupado por la forma de despliegue que está adoptando mi equipo ... está muy anticuado y sé que no funciona muy bien. Pero no sé exactamente cómo cambiarlo, así que por favor dale algunas sugerencias al respecto ...

Aquí está nuestra configuración actual:

• 2 servidores web
• 1 servidor de bases de datos
• 1 servidor de prueba

Adaptación de implementación actual

1. Desarrollamos y trabajamos en el servidor de pruebas, cada cambio se carga manualmente al servidor de prueba.
2. Cuando se completa un cambio o característica, luego comprometemos los cambios en el repositorio SVN.
3. Después de cometer los cambios, luego cargamos nuestros cambios en el primer servidor web, donde habrá un cronjob que se ejecuta cada minuto para sincronizar los archivos entre los servidores.

Algo muy molesto es que cada vez que cargamos un archivo justo cuando comienza el trabajo de sincronización, el archivo que está sincronizado parecerá dañado, ya que solo está medio supuesto. Otra cosa es que cuando hay una falla de implementación, será extremadamente difícil de revertir. Estos son básicamente el problema que enfrento, ¿qué debo hacer?

Además, dado que hay archivos en el primer servidor web que deben sincronizarse con los otros servidores en cualquier momento, por lo que el Cronjob estaba allí por el motivo.

P/S: Lo siento, olvidé mencionar eso, el servidor SVN está alojado. No tenemos demasiado control sobre él, pero creo que puedo editar ganchos ...

Answer 1

Use un marco de implementación como Phing Para administrar la implementación en los servidores web y deshacerse del trabajo cron. Básicamente, una versión en el sistema de producción no debe ocurrir automáticamente, pero solo después de estar segura de que la construcción actual no está rota. Y no debe tener una dependencia del sistema de desarrollo.

Dado que Phing usa XML y PHP para configurar y controlar el proceso de implementación, puede controlar el proceso. Este es un beneficio adicional, ya que puede mantener la implementación conectada a compilaciones específicas de su aplicación.

Para evitar que el sitio web de producción se vea afectado por el proceso de implementación, considere cargar una nueva construcción en un directorio separado y luego simplemente un enlace simbólico. Si algo sale mal, puede simular fácilmente a una versión anterior.

También considerar Usando un servidor CI.

Answer 2

Hice lo mismo en mi último lugar. Lo que teníamos era:

• un repositorio por sitio web
• Una rama para cada sitio web dedicado al sitio en vivo (es decir, /branches/live) y sitio de prueba (es decir /branches/testing)
• 2 servidores web que podrían hablar con SVN
• un servidor de prueba que podría hablar con SVN
• Todos los servidores tenían instalado el cliente de línea de comandos SVN

Cada servidor web operaba de forma independiente, por lo que realmente no se sabían el uno del otro, que se dejó al equilibrador de carga. Cada servidor tenía un cronjob que se ejecutaba cada 3 horas y exportado la última versión de cada sitio web live rama en la carpeta correcta en el sistema de archivos.

En nuestro servidor de prueba, fue un verificar del testing sucursal para cada sitio web, y sin cronjob. Los desarrolladores actualizaron las carpetas cada vez que querían sacar algo para que los usuarios prueben antes de que se ponga en marcha.

Durante los desarrollos, se hicieron compromisos al trunk del sitio web. Cuando los cambios estaban listos para las pruebas, se fusionaron en la rama de pruebas y el pago se actualizó manualmente en el servidor de prueba. Cuando los cambios estaban listos para comenzar, se fusionaron con la rama en vivo y los servidores se habrían actualizado al final del día.

En 3 años solo tuvimos un problema en el que un desarrollador había cometido algo incorrectamente y tuvo que retroceder el sitio.

Answer 3

Como una solución parcial, cree una URL en el sitio web que desencadine el comando RSYNC cuando lo visite, para que pueda controlar cuándo se ejecuta RSYNC (obviamente, debe asegurarse de presionar el servidor 1 con esta URL y no exponer esta URL para el publico). Mejor aún, use Curl para invocar la URL RSYNC al final de cualquier script de carga que use.