implementar sitio web desde el control de versiones: ¿exportación y enlaces simbólicos?

Question

Soy un desarrollador solitario.Tenemos un par de sitios web alojados en un servidor web.El repositorio svn también está en el servidor web.Internamente, tenemos una máquina de desarrollo, que es una réplica bastante cercana del entorno real.

Para el sitio web en vivo, tengo una exportación de Subversion, debidamente nombrada con el número de versión.La raíz del documento del sitio web activo es en realidad un enlace simbólico a ese directorio.De esa manera, puedo retroceder o avanzar fácilmente a las versiones exportadas sin tiempo de inactividad simplemente cambiando hacia dónde apunta el enlace simbólico.

Cuando llegue el momento de implementarlo, exportaré una versión del tronco a un subdirectorio del sitio web activo, como área de preparación, y haré algunas pruebas.De esa manera veo cómo se comporta realmente en el entorno en vivo, sin cambiar nada de lo que ven los usuarios.Luego, si todo parece estar bien, haré otra exportación a la raíz de mi cuenta y cambiaré el enlace simbólico (¡y probaré nuevamente!)

¿Es esto exagerado?¿Cuáles son otras formas de hacerlo?

Answer 1

Está Capistrano, que te ayuda en este proceso.El uso de SSH y claves hace que el proceso sea bastante sencillo para implementar cambios y demás.Si bien esta es una aplicación Ruby, aún puedes usarla para implementar PHP u otras aplicaciones, échale un vistazo. aquí para obtener información

Y este artículo habla de ello, utilizando una carpeta compartida junto con su carpeta de lanzamiento.La carpeta compartida puede contener archivos de configuración para su servidor de implementación individual (URL, conexión de base de datos, etc.), así como activos que se cargan durante la vida de un sitio web y no están en svn.También puedes hacer que Capistrano se encargue de esto por ti.

Si bien alguien que no conozca la configuración puede tener dificultades para ver esto por primera vez, realmente facilita la implementación.Creo que lo que hace Capistrano es bastante simple y probablemente podría escribirse en otro idioma para manejar su escenario específico.

Y otra idea para vincular esto a SVN o cualquier repositorio.Es utilizar sus ganchos para ejecutar estas implementaciones.es decir.Cada confirmación al tronco actualizará el servidor de desarrollo.Y una rama lo enviará a su entorno de ensayo.

Pero este enlace hace un gran trabajo al mostrar cómo configurar ese tipo de entorno.Creo que lo que ha configurado es una buena práctica y no se ha hecho lo suficiente.Lo único que puede ayudarle es la implementación automatizada en diferentes entornos y scripts para ayudarle con la configuración de su nueva implementación.

Actualizar ::
Además, me gustaría señalar que SVN puede manejar enlaces simbólicos.Entonces, si está realizando implementaciones en servidores basados ​​en Unix, puede simplemente colocar los enlaces simbólicos en su repositorio y usar un enlace simbólico relativo.

Entonces si tienes

./releases/200912231043
./shared/uploads

Puedes poner tu enlace simbólico como

./releases/200912231043/uploads -> ../../shared/uploads

Esto le brindará una manera fácil de administrar activos que no están en svn sin usar muchos scripts para implementar.Ahora puede usar una confirmación para implementar en su desarrollo y/o preparación.

Answer 2

Creo que esta es la forma correcta de hacerlo. Parece ideal para mí: Actualizaciones en vivo vienen como una versión completamente probado, los cambios son bien documentable través de los mensajes de confirmación, rodando hacia atrás (y hacia atrás) es fácil y el cambio de una versión a otra es atómica lo que no hay tiempo de inactividad. Me esfuerzo por hacerlo de la misma manera con cada proyecto.

¿Cuál es tu pregunta? ¿No está seguro acerca de algo? ¿No está funcionando para usted? Si es así, ¿qué parte de ella exactamente?

Answer 3

Es un poco lo que he de hacer para el último par de años por un par de proyectos -. Y nunca tuvo un solo problema con esa manera de hacer las cosas

La posibilidad de "reducción" con los enlaces simbólicos podría ser visto como un poco exagerado, sí ... Pero el día que lo necesite para guardar el sitio web en el que se ha instalado una versión con un error crítico, lo va a apreciar que tener capacidad!
He utilizado este algo así como 2 veces en 3 años - pero, cada vez, lo que realmente salvó el día ^^

Una cosa que me parece extraño, sin embargo:? Si he entendido bien, se está probando la nueva versión de la página web en la (producción) de base de datos en vivo

Si es así, si hay un error en la aplicación, que podría destruir su base de datos de producción -. El cual, obviamente, sería malo

Me gustaría utilizar otra base de datos para ese entorno de prueba, personnaly -. Así como una medida de seguridad

También:? Que está haciendo una gran cantidad de pruebas, lo cual es bueno ... Pero ¿por qué no automatizar algunos de los

Sería permitirá probar más rápido, más a menudo, y que le pasa menos tiempo de prueba, y más tiempo desarrollando; -)