¿Cómo mantener Subversion y un servidor remoto (a través de FTP) sincronizados?

Question

Estamos teniendo dificultades para mantener subversión y FTP sincronizados. A veces nos olvidamos de realizar cambios y simplemente los empujamos al servidor web, tenemos carpetas .svn dispersas por nuestro servidor web, algunas cosas existen en un lugar y no existen en el otro, etc.

Quiero tomar el momento de arreglar esto, hoy. ¿Cuál es la solución? ¿Hay alguna forma de que SVN se pueda vincular a nuestro servidor web, de modo que podamos comprometernos tanto con el repositorio como con el servidor web a través de FTP? ¿Deberíamos preguntarle a nuestro servidor web por algún otro sistema que se sincronice mejor con el repositorio SVN? ¿Cómo exigimos que el repositorio y el servidor web estén sincronizados? ¿Cómo eliminamos las carpetas .svn?

Como dice el título, ¿cómo podemos mantener nuestro repositorio SVN y nuestro servidor web sincronizados?

Answer 1

Lo que hago en mi servidor es que sea un checkout del código en el servidor.

Así que, en lugar de usar ftp para enviar cosas al servidor, solo me conecto y ejecuto un svn up. Al hacerlo manualmente de esta manera, obtendrá varios beneficios, incluida la capacidad de retrotraer en caso de que el código falle.

También recomendaría usar un sistema de migración db (suponiendo que esté utilizando una base de datos). Esto le permitirá deshacer fácilmente los cambios al esquema db para asegurarse de que su código continuará funcionando en caso de una reversión.

Combinar estos con una herramienta similar a Fabric o Capistrano, le daría un sistema de implementación muy robusto y potente.

Nota sobre DVCS:

Algunas personas aquí han mencionado el uso de un distributed vcs. Algunos de los ejemplos más populares de estos son git y mercurial (hay varios más).

Ambos tienen un patrón de uso diferente que svn, pero eso no se aplica realmente a esta pregunta directamente. La mayor ganancia que puede obtener es que si hace etiquetas para cada inserción en el servidor activo, el costo de hacerlo es minúsculo en comparación con el patrón de etiquetado tradicional para svn.

Si usted deseaba expirement con cualquiera de los GitHub y BitBucket ambos ofrecen repositorio gratuito de alojamiento de git y mercurial respectivamente.

Dicho esto, soy un gran defensor del uso de un dvcs y mi preferencia personal es mercurial.

Answer 2

Configura un post-commit hook que actualiza el FTP y utiliza exclusivamente el SVN para los cambios. De esta forma, cuando se realicen cambios, se actualizará su servidor web.

Esto supone que el servidor web es un servidor intermedio. Ver comentarios para más detalles.

Answer 3

Esto parece un problema hecho a medida para un sistema de control de revisión distribuido.

Answer 4

No querrá realizar cambios en un servidor web en vivo sin ningún tipo de prueba, ¿verdad?

Respuesta breve: al realizar una nueva comprobación (preferiblemente en un servidor central) y copiar solo los bits necesarios para ejecutar la aplicación.

Yo recomendaría la creación de continous integration, donde su servidor de compilación es responsable de recuperar las últimas fuentes desde el repositorio de Subversion, realizar una generación y la preparación de los paquetes de distribución para diversos entornos (prueba/estadificación) y potencialmente ftp'ing arriba a la caja de producción una vez que esté satisfecho con los cambios implementados en su entorno de ensayo o estadificación.

Esa es la única forma sólida de garantizar que los cambios DEBEN confirmarse (no lo sé, pero parece ser incierto en su caso) o de lo contrario simplemente no terminarán en la implementación. Impone el proceso de una buena administración de versiones, sin olvidar que puede agregar todo tipo de otras cosas maravillosas de automatización a su servidor de compilación, como pruebas de unidades y pruebas funcionales.

Answer 5

La mejor manera que encontré para hacer esto es asegurarme de que nada se escape al servidor: esta es una laguna que debe solucionar primero.

Luego, configure una verificación local de las partes de su repositorio que desea sincronizar y use rsync para enviar los datos al servidor (FTP realmente no es útil en este contexto). rsync le permite excluir archivos y directorios, así que use esa función para asegurarse de que los directorios .svn no se sincronicen.

Answer 6

Sugeriría que antes de implementar a continuación, utilice un entorno de prueba donde pueda FTP directamente, y luego presione en vivo, confirme esa versión de archivos y permita que esta tarea se ejecute.

De tigris:

Esto se hace todo el tiempo, y se logra fácilmente mediante la adición de una confirmación post-script gancho a su repositorio. Lea sobre los scripts de gancho en el Capítulo 5 del libro. La idea básica es hacer que el "sitio en vivo" sea solo una copia de trabajo normal, y luego hacer que su script de anotación post-commit ejecute 'svn update' en él.

En la práctica, hay un par de cosas que hay que tener en cuenta. El programa servidor que realiza la confirmación (svnserve o apache) es el mismo programa que ejecutará la secuencia de comandos post-commit hook. Eso significa que este programa debe tener los permisos adecuados para actualizar la copia de trabajo. En otras palabras, la copia de trabajo debe ser propiedad del mismo usuario que svnserve o apache se ejecuta como, o al menos la copia de trabajo debe tener los permisos adecuados establecidos.

Si el servidor necesita actualizar una copia de trabajo que no posee (por ejemplo, usuario joe ~/public_html/area), una técnica es crear un + programa binario para ejecutar la actualización, ya que Unix ganó ' t permitir que los scripts ejecuten + s. Compilar un pequeño programa en C:

#include <stddef.h> 
#include <stdlib.h> 
#include <unistd.h> 
int main(void) 
{ 
    execl("/usr/local/bin/svn", "svn", "update", "/home/joe/public_html/", 
    (const char *) NULL); 
    return(EXIT_FAILURE); 
} 

... y luego chmod + s el binario, y asegúrese de que es propiedad de Joe de 'usuario. Luego, en el enganche post-commit, agrega una línea para ejecutar el binario.

Si tiene problemas para hacer funcionar el gancho, consulte "¿Por qué mis anzuelos de repositorio no funcionan?".

Además, es probable que desee evitar que apache exporte los directorios .svn/en la copia de trabajo en vivo. Agregue esto a su httpd.conf:

# Disallow browsing of Subversion working copy administrative dirs. 
<DirectoryMatch "^/.*/\.svn/"> 
    Order deny,allow 
    Deny from all 
</DirectoryMatch> 

Answer 7

Springloops hace exactamente lo que necesita. Darle una oportunidad. Es SVN combinado con FTP. Trabaja en su copia local de trabajo, luego confirma los cambios en el repositorio, luego a través de Springloops despliega la revisión seleccionada en cualquier servidor (Puesta en escena o Producción) a través de FTP.

Answer 8

Estaba a punto de sugerir Springloops cuando me desplacé hacia abajo y vi la sugerencia de Chris. He estado usando SpringLoops durante los últimos meses y me encanta.

Puede configurar los detalles de FTP para la puesta en escena y los servidores de prod para cada repositorio. Luego puede publicar en esos servidores a través de FTP, especificando el número de revisión para implementar.

Algo que realmente me gusta de esto es que puedo ver en qué versión se encuentra cada servidor a través de la página de implementación en Springloops. Y con todo lo que se implementa a través de Springloops, usted sabe que esto es exacto.

Realmente he estado buscando una solución que sea algo más que un repositorio SVN ... algo con entradas integradas, wiki y control de tiempo. Me gusta mucho Bitbucket, pero no tiene la función de implementación de FTP de Springloops, que por desgracia me lo descarta. Por ahora me quedaré con Springloops hasta que otro servicio pueda ofrecer implementación de FTP.

¿Por qué el despliegue de FTP es tan importante para mí? Escucho a algunas personas murmurando en voz baja ... con mucho gusto le diré: Despliego a varios servidores diferentes. Algunos son buzones dedicados, algunas VM alojadas en la nube y algunos servidores compartidos. No quiero tener que mantener una metodología de implementación separada para cada uno, por lo que el método de implementación común para todos es FTP. Springloops se encuentra muy bien entre mi código fuente y mis servidores. Es por eso :)

Answer 9

Trate http://svn2ftp.com - ninguno de la mayor parte de la gestión de proyectos, simplemente puede configurar SVN repositorios, que se sincronizarán automáticamente con cualquier número de cuentas de S/FTP en cada confirmación.

Answer 10

Este sitio le muestra cómo configurar Subversion para que haga exactamente lo que está buscando. http://www.itforeveryone.co.uk/svn2web.html