2008-08-20 11 views

Respuesta

6

Para algunos proyectos que utilizo Capistrano para expulsar a vivir. Está construido sobre ruby ​​y hace que implementar script sea muy fácil y usa ssh.

En otros proyectos, tengo una pequeña aplicación de implementación que usa bash para hacer una exportación de svn a un directorio temporal y luego sincronizarla en el servidor en vivo. Puede hacer que rsync use ssh.

Yo prefiero mucho el método de Capistrano, incluso si su proyecto no está en ruby ​​/ rails.

0

Siempre puede escribir una pequeña aplicación cliente/servidor que cifra en la fuente, empuja los archivos y luego descifra en el destino. Eso es un poco de trabajo, pero probablemente una cantidad trivial. Y es programable siempre que su herramienta de automatización sea compatible con la ejecución de algo en el sistema de archivos (lo que creo que todos hacen).

El único inconveniente es que es posible que no pueda obtener mensajes de error significativos sobre fallas en su entorno de integración sin un poco más de trabajo por su parte (aunque dependiendo de su configuración, esto podría ser tan simple como enviar mensajes de error a stdout).

0

hm, aquí usamos un "servidor" de ensayo para realizar pruebas en el entorno en vivo (en realidad, es un host virtual Apache en el servidor de producción) y araxis merge (una herramienta de comparación de archivos línea a línea realmente inteligente) para sincronizar el desarrollo y la puesta en escena.

una vez probado, solo; reemplazar los archivos en la producción de Webroot :)

/mp

4

Este parece ser el tipo de cosas que se podrían hacer fácilmente con SFTP. Eche un vistazo a PuTTY (psftp y pscp) o WinSCP para Windows, o rsync y OpenSSH para Unixes.

1

Haga una copia del directorio de su sitio en vivo, use rsync para actualizar esa copia con su última versión, luego cambie el nombre de los directorios activos y actualizados para que la versión actualizada esté ahora activa.

En bash:

#!/bin/bash 

set -e 
cp -R /var/livesite /var/newversion 
rsync [email protected]:/var/readytogolive /var/newversion 
mv /var/livesite /var/oldlivesite 
mv /var/newversion /var/livesite 

Viola!

Editar: @Ted Percival - Esa es una buena idea. Ni siquiera sabía sobre "set -e". Script actualizado Editar: actualizado de nuevo a sugerencia de Ted (aunque creo que todavía funcionaría si de alguna manera fallara el comando cp, y si cp falla probablemente tenga problemas más serios.)

1

@Neall, agregaría un set -e en el segundo línea, porque no desea que el sitio en vivo sea reemplazado si el rsync falla por algún motivo. set -e hace que la secuencia de comandos se cierre si falla alguno de sus comandos.

Editar: El set -e debe ser lo primero en el guión, justo después de #!/bin/bash.

1

Voy a la recomendación para la segunda Capistrano, aunque si usted está buscando una solución basada en la interfaz gráfica de usuario puede probar con el extremo frontal Webistrano. Semántica limpia, basada en ssh, sana de implementación y retrotracción, y fácil creación de scripts y extensibilidad a través de ruby.

0

En un trabajo independiente que hice, configuramos tres entornos separados.

  • Un servidor Dev, que ejecutó las compilaciones utilizando CruiseControl. Cualquier check-in desencadenaría una compilación. La prueba de QA se hizo aquí.
  • Un servidor de prueba, en el que se realizaron las pruebas de aceptación del usuario.
  • Producción.

El flujo de trabajo fue como sigue:

  1. cheques revelador en cambios en SourceControl.
  2. CruiseControl construye y despliega la construcción en Dev.
  3. Dev es QA'ed
  4. Después de pasar el control de calidad, se ejecuta un script robocopy que implementa Dev build en Test.
  5. La prueba está UAT'ed
  6. Después de las pasadas de prueba, se ejecuta un script robocopy que implementa Prueba a PRD.
Cuestiones relacionadas