pandora - requerimientos para instalar php

Despliegue de PHP a servidores de Windows/Unix (5)

Tenemos varios proyectos de PHP desarrollados en Windows (xampp) que deben implementarse en una combinación de servidores de Linux / Windows.

Hemos utilizado capistrano en el pasado para implementar desde windows a los servidores de Linux, pero los cambios recientes en la arquitectura y los servidores de Windows dejaron que la configuración anterior no funcionara. La receta funciona bien para la implementación de Linux, pero la configuración de los servidores de Windows ha requerido más tiempo de lo que tenemos ahora. Las ideas para la receta de Capistrano son respuestas válidas. obviamente, los servidores windows / linux no comparten usuarios, por lo que esto lo complica un poco (para la suposición capistrano del mismo nombre de usuario / contraseña en todas partes).

Actualmente estamos usando svn-update para los servidores de Windows, lo que no me gusta, ya que deja todos los archivos svn colgando en los servidores de producción. (y todavía tenemos que svn-update manualmente en Windows) Y la actualización manual de archivos usando winscp y la sincronización de los directorios con sus contrapartes de Linux.

Mi pregunta es qué herramientas / configuración sugieres para automatizar este escenario de implementación: "Diversos desarrolladores de php windows / linux implementados en más de 2 máquinas mixtas de Windows / Linux"

(ps: no tenemos problemas para usar las herramientas de Linux o cualquier cosa que funcione a través de cygwin, simplemente necesitamos hacer que la implementación sea una simple operación de un solo paso)

editar: Actualmente no podemos trabajar en un entorno all-linux, tenemos que implementar tanto en Linux como en el servidor de Windows. Podemos comenzar la implementación desde cualquier lugar, pero preferiríamos poder hacerlo desde cualquier entorno.

¿Por qué ya no puedes usar capistrano?

¿Por qué no te gusta svn-update?

¿Qué cosas en su aplicación requieren una implementación especial?

Capistrano es la mejor herramienta de implementación que he visto. ¿Los cambios de arquitectura hacen que sea imposible arreglar las configuraciones para que funcione de nuevo?

Esto probablemente suene tonto pero ... Solía tener este tipo de problema todo el tiempo hasta que al final decidí que si siempre estoy implementando en Linux, al menos debería intentar desarrollar también en Linux. Yo si. Fue sin dolor. Nunca volví.

Ahora. No estoy sugiriendo que esto sea para todos. Pero, si instala VirtualBox , podría ejecutar una instalación de Linux como un servidor local en su cuadro de Windows. Comparta una carpeta en la máquina virtual y puede usar todas sus técnicas y software conocidos y confiables de Windows y tener la tranquilidad de saber que todo funciona bien en su plataforma de destino.

Además, podrá volver a Capistrano (una buena elección) para la implementación.

Lo mejor de todo es que, si creía conocer Linux / Unix, espere hasta que lo use todos los días en su escritorio. Quién sabe, incluso te puede gustar :)

Uso 4 enfoques diferentes dependiendo del entorno del cliente:

Capistrano y herramientas similares (efectivas, pero complejas)
rsync de + a Windows, Linux, Mac (simple, no impone disciplina)
svn de + a Windows, Linux, Mac (simple, no impone disciplina)
Scripts en el servidor (se ejecuta a través del navegador, complejo)

Hay algunos requisitos que impulsan lo que necesita:

Cuánta disciplina quiere aplicar
Si necesita migraciones de bases de datos (o configuraciones) (arriba y / o abajo)
Si quieres una página estática "estamos abajo"
Quién puede hacer la actualización
Diferencias de configuración entre servidores

Sugiero enfáticamente aplicar la disciplina suficiente para salvarte de ti mismo: implementar en un servidor de desarrollo, permitir migraciones ascendentes y restaurar bases de datos simples, y limitar quién puede actualizar el servidor en vivo a un pequeño número de administradores responsables (donde el servidor dev está abierto a más desarrolladores). También considere empujar a través de un trabajo cron (al servidor de desarrollo), de modo que haya una instantánea diaria de sus cambios incrementales.

La mayoría de las veces, me parece que las configuraciones de svn o rsync son suficientes, con algunas secuencias de comandos del lado del servidor, especialmente cuando el conjunto de administración está limitado a unos pocos desarrolladores.

Puede configurar la propiedad svn:ignore en los archivos de configuración, para que svn update no los borre y luego use svn export /target/path/ para deshacerse de los archivos .svn en su repositorio de Subversion.