Cómo actualizar mejor un sitio web desde la subversión

Question

Tengo un sitio web PHP respaldado por una base de datos MySQL y un pequeño equipo de programadores que envían el código a subversión. Por lo general, escribimos código, lo evaluamos localmente, nos comprometemos con la subversión y luego copiamos los archivos cambiados a un área oculta para realizar pruebas en línea.

Sin embargo, se pueden cometer errores. Ocasionalmente quiero actualizar el sitio para que sepa, sin lugar a dudas, que el código del sitio y la base de datos realmente representan lo que está en subversión. Me gustaría acercarme lo más posible a una solución de un clic para que sea infalible.

¿Cuál es la mejor manera de hacerlo?

Por cierto, si es necesario, desarrollamos en máquinas con Windows.

Answer 1

La exportación se puede hacer de forma automática después de cada confirmación con un gancho post-commit:

http://svnbook.red-bean.com/en/1.5/svn.ref.reposhooks.post-commit.html

se puede configurar el gancho para exportar automáticamente el proyecto dentro del área oculta para la prueba en línea.

Answer 2

¿Qué hay de verificar el código para ubicarlo desde donde desea ejecutarlo?

Answer 3

No recomendaría revisar su código en su servidor de producción. Esto puede exponer los archivos de control svn (.svn) en el servidor.

Recomendaría utilizar un script (python, ruby, etc.) combinado con la línea de comando svn y el cliente FTP para exportar los archivos desde svn y ftp los archivos al servidor. El comando svn export se puede usar para verificar un conjunto de archivos del servidor svn sin todos los directorios .svn. Además, no olvide etiquetar el repositorio svn al hacer esto para tener un punto de control de lo que ha implementado.

Answer 4

La administración de la versión de código y la administración de la versión de la base de datos son dos problemas muy diferentes. La solución que prefiero se realiza en tres etapas (Test, Deployment Test, Live) en lugar de dos.

• actualizar el código y aplicar los cambios de base de datos a través de scripts en el entorno de desarrollo
• Descargar la base de datos en vivo a un entorno de prueba despliegue, restaurarlo y aplicar los scripts de cambio
• probar el código en contra de la 'sincronizado' base de datos activa
• actualización del entorno en vivo a través de sVN de la rama correspondiente en el repositorio (lo hacemos a través de túneles SSH, ya que es un entorno Linux) y aplicar las secuencias de comandos de cambio a la db vivo

Editar: La actualización para el entorno en vivo se realiza mejor mediante la exportación en lugar de la verificación/actualización. Esto no deja el archivo de control de svn dando vueltas. Esto puede o no tener implicaciones de seguridad, pero te obliga a especificar qué rama estás revisando cada vez.

Su 'un clic' probablemente podría ser un guión para el último paso.

Answer 5

recomendaría:

• copiando cada una vieja construcción de su propio directorio (para restauraciones rápidas; es probable que sólo necesita para mantener uno de estos) en una parte no web accesible de su servidor.
• Luego use svn export para obtener toda la compilación nueva de svn. No use svn checkout, ya que esto dejará directorios .svn por todos lados.

Answer 6

Si instala el cliente de línea de comandos de Subversion, es bastante fácil de hacer un script de archivo por lotes/corteza que va a hacer un check out exportación de la última revisión del repositorio a una carpeta en el servidor. Esto requiere que tenga la misma estructura de archivos en Subversion que en el servidor (a menos que quiera agregar la lógica para cambiar la estructura en el script, por supuesto).

Answer 7

Te recomiendo que escribas algún tipo de script que haga esto por ti. Ya sea que hagas esto con PHP u otra cosa depende de ti. Solo ten en cuenta la seguridad cuando hagas esto.

Hacer una exportación de su proyecto no exportará ningún svn: externals que haya configurado, lo que significa que debe realizar múltiples exportaciones. Cuando se escribe esto, no debería ser un gran problema. Otra cosa con las exportaciones, si el proyecto es grande (si usa muchos videos, PDF, etc.), entonces una exportación puede ser bastante engorrosa, especialmente cuando su control de versiones está alojado fuera del sitio y solo está disponible a través de HTTP.

Te recomiendo que hagas un checkout y asegúrate de que tu servidor no pueda servir ningún archivo ubicado en las carpetas ocultas .svn.

Answer 8

Implementamos a través de Subversion y usamos herramientas de migración de base de datos (con versiones de esquema) para hacer esto.

(http://blog.lavablast.com/post/2008/02/I2c-for-one2c-welcome-our-new-revision-control-overlords!.aspx)

(Desarrollamos en .NET)

Answer 9

Gracias por todas las respuestas, ayudó mucho a la prueba yo no estaba haciendo demasiado mal. Estamos desarrollando y probando en un proceso de pago local de un repositorio de subversión en línea. Cuando queremos implementar una nueva versión, ejecutamos un script que básicamente elimina la exportación actual en un servidor de pruebas en vivo, crea una nueva exportación y luego se implementa en todos los servidores web a través de rsync.

Problema con esto: Rsync siempre copia todos los archivos al implementar en el servidor en vivo debido a la exportación completamente nueva. De hecho, nunca me tomé el tiempo para averiguar cómo actualizar una exportación.

En otra máquina sólo tengo un check out y desplegar con rsync --sin Svn

Answer 10

¿Ha revisado Beanstalk? http://beanstalkapp.com/ Es un servidor SVN/GIT y cuenta con una implementación FTP automática.