php, files cargados por el usuario, control de versiones y deployment del website

Tengo un website al que regularmente actualizo el código. Lo mantengo en control de versiones. Cuando deseo implementar una nueva versión del sitio, realizo una export y luego enlace simbólico el nombre del directory servido al directory de la implementación.

Hay un lugar donde los usuarios pueden upload files, y una vez noté que, después de haber implementado una nueva versión, ¡los files del usuario habían desaparecido! Por supuesto, no los había agregado al repository, y dado que el sitio servido era de una export, de todos modos no se cargaron en un directory controlado por la versión.

PHP aún no tiene funcionalidad svn integrada, por lo que no pude hacer mucho programáticamente los files cargados por el usuario. Mi solución fue crear un website adicional, files.website.com, que se encuentra en un directory paralelo al website servido, y se sirve fuera de un directory que está bajo control de versión. De esta forma, no se borran cuando realizo una actualización al website. De vez en cuando, agrego manualmente los files cargados al proyecto svn, elimino los eliminados por el usuario y confirmo la nueva versión. Estoy trabajando en un script de shell para ejecutar desde cron para hacer esto, pero no es mi fuerte, así que está en un segundo plano porque no es una necesidad apremiante.

¿Hay una mejor manera de hacer esto?

Por lo general, no guardo los datos / files generados por el usuario en svn. solo el código, el esquema db / datos de testing. Lo que suelo hacer para implementar es una rsync de una copy de trabajo actualizada que excluye los directorys dir y .svn de carga. El contenido IMO debe manejarse mediante mecanismos de copy de security de sistema de files / db más tradicionales y no de control de versiones.

EDITAR:

Para que quede claro, su estrategia de enlace simbólico parece una buena práctica. Si bien le falta la parte de respaldo, eso es lo que piensa. Id probablemente solo tar | gzip tar | gzip las cosas cargadas en el trabajo cron en lugar de interactuar con SVN. Y luego probablemente tenga uno separado para usar mysqldump para volcar el db y el gzip también.

Continuaría con la práctica de exportar el sitio ya que las actualizaciones son necesarias pero tienen un enlace simbólico a un directory fuera del directory controlado por la versión con el contenido subido por el usuario. De esta forma, cuando realizas una export, solo necesitas volver a crear el enlace simbólico si se destruye. Por supuesto, debe hacer una copy de security de ese contenido del usuario según sea necesario.

En lugar de realizar manualmente la export y administrar enlaces simbólicos, puede hacer que su directory de implementación sea una comprobación de subversión (desde una twig de producción). De esta forma, la implementación es tan simple como registrar sus actualizaciones en la sucursal de producción.

Esto funciona siempre que tenga el control suficiente de su server de subversión y de su configuration de host, y su depósito de subversión está "listo para ejecutarse". En esta situación, su directory de usuario podría ser un marcador de position vacío en subversión y lo dejaría solo el process de actualización que se ejecuta en la confirmación (como de costumbre para la svn update ). Todavía recomendaría (como lo mencionan @ Flash84x y @prodigitalson) un process por separado para hacer una copy de security del contenido del usuario.

Hay un artículo de Ars Technica con una descripción de cómo configurarlo.

Actualización : si sigue este enfoque, asegúrese de que su server web no permita el acceso a los files .svn en el process de pago de implementación.