¿Cómo puedo usar Subversion para implementar aplicaciones web?

Somos un pequeño equipo de 4 desarrolladores trabajando en una aplicación web. Usamos trac + svn en un server compartido para control de versiones y tickets y estamos felices y satisfechos con esto. El mismo server compartido también aloja nuestra aplicación web. La aplicación en sí es una aplicación Perl CGI que utiliza CGI :: Application y una cantidad moderada de modules estándar (CPAN) y Perl personalizados que se instalan en las ubicaciones usuales (/ usr / lib / perl …) y algunas inusuales ( / home / usuario / lib / perl ..). Si bien los detalles generales pueden ser irrelevantes, el punto más importante es que la location / disposition de las bibliotecas en nuestras máquinas de desarrollo es diferente de la del server de producción (compartido) . Tenemos que vivir con esto como algo dado. Sin embargo, el layout de la biblioteca es idéntico en todas las máquinas de desarrollo.

Este es un ciclo de trabajo típico pero claramente subóptimo que mis colegas y yo seguimos:

  1. Código y testing en máquinas de desarrollo
  2. Pagar / Comprometer / Actualizar nuestro código en el SVN
  3. Periódicamente " svn export " en el DocumentRoot apropiado del server
  4. Edite manualmente el tree exportado para establecer que la biblioteca incluye coincide con el layout de la biblioteca en el server
  5. Aplicación de testing en el server en vivo, recaudar boletos el uno para el otro
  6. Ir a 1

Claramente, debe haber una manera mejor y agradecería escuchar a otros que podrían estar manejando esto mejor que nosotros. Por ejemplo, ¿hay alguna manera de svn export y arreglar las ubicaciones de la biblioteca de forma automatizada? ¿O hay alguna forma completamente diferente de manejar esta situación de la que hemos estado haciendo hasta ahora?

Gracias por su atención

Debería tener scripts que hagan esto por usted y que puedan ejecutarse desde un buzón local. El mío siempre se ve algo así como:

 $> checkout from source or copy from working $> run sed/perl -pi/copy to convert configs to the production values (ie cp production.config myconfig) $> upload to web server (rsync/ssh/ftp/etc) $> ssh $SERVER migrate_db, set permissions, run unit tests, etc 

El último requiere acceso ssh que siempre busco pero todo lo demás se puede hacer localmente. Por lo general, tendrías un set de configuraciones de desarrollo y un set de configuraciones de producción (o un script para convertir de desarrollo a producción)

Las subidas de un paso son siempre una muy buena idea.

Mantenga un file de configuration (por ejemplo, config.pl) que almacene todas las routes y variables dependientes del sistema. A continuación, establezca la propiedad svn: ignore en este file para que nunca se confirme. Esto le permitirá mantener fácilmente un script de configuration local por sistema que está separado del tree comprometido.

Si no tiene la posibilidad de duplicar su server de desarrollo en producción, ¿por qué no puede duplicar su server de producción en desarrollo? Eso podría requerir una reconfiguration, pero ¿cuál es el riesgo? Todo está registrado en svn.

Pero tal vez eso realmente, realmente no es una opción para ti. Mi preference para implementar aplicaciones web es hacer un checkout de svn y luego ejecutar un script de enlace simbólico. La idea es que usted escriba un sistema de reglas que mapee lógicamente los contenidos de una carpeta a los contenidos de otra. Por supuesto, si suelta enlaces simbólicos de carpeta en la raíz de su documento, debe decirle a Apache que los siga.

Francamente, el escenario más seguro sería configurar una máquina virtual que pueda configurar exactamente como su máquina de producción. De esta forma, puede probar los contenidos de su secuencia de commands de implementación y enviar tickets. Luego, cuando se descubre el problema, modifica la secuencia de commands para que sea más probable que la implementación de desarrollo siga el procedimiento nuevo y mejorado.

Y, como nota al margen: prefiero usar las comprobaciones de svn en lugar de las exportaciones de svn. No debería ser difícil (especialmente si usa una secuencia de commands de implementación) para asegurarse de que apache o lo que sea que su server web no tenga permiso en las carpetas .svn. Idealmente, cualquier cosa que pueda hacer para hacer que un svn rollback sea un command de una línea es absolutamente key.

Si se trata de una caja Linux, podría escribir un trabajo cron para encargarse de esto. Puede usar sed / awk para replace las cadenas necesarias en el código y svn export funciona bien desde un trabajo cron. Debería mantener el guión, pero parece más rápido que hacerlo a mano cada vez.

Para la parte de edición manual, tendría una sucursal separada en Subversion para las modificaciones locales que necesita. Los desarrolladores se comprometen con el enlace troncal y cuando necesita implementarlo, use 'svn merge' o svnmerge.py para combinar los cambios del enlace troncal a la sucursal.

Después de crear la twig la primera vez, realice las modificaciones locales allí.

En los serveres, haga que los directorys en DocumentRoot y / usr / lib / perl y / home / user / lib / perl sean copys de trabajo de Subversion extraídas de la sucursal.

No use svn export, solo tiene que pagar para poder 'cd / usr / lib / perl; svn up '.

Lo único que debe tener cuidado no es exponer sus directorys .svn en DocumentRoot, use esto:

 # Prevent any access to .svn directories. <DirectoryMatch "^/.*/\.svn/"> Options None AllowOverride None Order allow,deny Deny from all </DirectoryMatch> 

Tener las copys de trabajo implementadas en DocumentRoot también es bueno, si necesita deshacer un cambio, simplemente 'svn up -r PREV'.

Codesion ofrece subversión de nivel empresarial y seguimiento a pedido. Además, ahora tenemos la capacidad de publicar / implementar un código con un solo clic a través de ftp, scp, rsync y muchos otros methods. Esta será una manera fácil y rápida para que usted logre lo que está tratando de hacer.

Vea nuestras características de Codesion Publisher:

https://help.codesion.com/View.jsp?procId=01fabe5e83381dda4edda959b97b2c5b