it-swarm-es.com

¿Puede recomendar formas de administrar la implementación de código en un servidor web basado en Linux?

Siempre he usado un script bash muy simple para implementar el código. Me estoy alejando del uso de Subversion a Mercurial, pero realmente no creo que el software de control de revisión sea importante para la implementación.

¿Cuáles son algunas formas mejores de hacer esto?

#!/bin/sh
date=`date +%Y%m%d_%H%M%S`
tar -zcvf app-dir-$date.tar.gz app/dir 
tar -zcvf app-templates-$date.tar.gz app/templates
tar -zcvf app-media-$date.tar.gz app/media
svn export http://example.com/somepath/trunk hh/ --force
7
citadelgrad

Uso Mercurial para administrar todo , incluidas mis páginas HTML estáticas. Me hace la vida muy, muy fácil.

Beneficios incluidos

  • Todas las ventajas de las ofertas de control de versiones (retrocesos, etiquetas de hitos, etc.)
  • Poder clonar su sitio a toda prisa
  • Siempre tiene una copia de seguridad/copia local que funciona
  • Fácil de mantener sincronizado si tiende a realizar cambios in situ (en el lugar, en el servidor)
  • La mayoría de los hosts compartidos (si está tratando con uno) no le importa instalarlo

Descargo de responsabilidad, escribí el tutorial. Sí, el tipo de VCS que utilizas es importante, hasta cierto punto. Por ejemplo, no usaría algo en este escenario donde no podría comprometerme localmente y hacer un gran Push/update. Eso solo me obliga a agrupar demasiados cambios potencialmente problemáticos en un solo compromiso.

Yo podría hacerlo con Subversion, y no estoy tocando SVN en absoluto. Simplemente creo que Mercurial es una herramienta mucho mejor para el problema que está tratando de resolver.

Es mi opinión que no debería tener que 'evitar' sus herramientas a menos que no tenga otra opción. Hacerlo de alguna manera derrota el propósito de tenerlos, y tienes una opción :)

5
Tim Post

Además de las excelentes sugerencias en las otras respuestas, es posible que desee considerar si es importante para usted realizar una actualización atómica.

En mi servidor FreeBSD, lo logro a través de dos mecanismos:

  • Versiones de todos mis recursos estáticos. (Por ejemplo, http://static.example.com/images/logo.1.png o http://static.example.com/style/main.3.css). Esto me permite svn update el sitio estático directamente antes de actualizar el sitio dinámico, sin preocuparme de que los usuarios vean archivos nuevos en páginas antiguas.

  • Versiones de todo el sitio web dinámico. En mi caso, tengo la raíz de mi documento apuntando a un enlace simbólico. Mi estrategia es tener la nueva versión de producción en su lugar y luego con un solo comando Push it live. .sol. algo como esto:

    cp -Rp www.site1.com.1 www.site1.com.2 (o svn checkout)

    svn update site1.com.2 (puede necesitar un svn switch primero)

    ln -sf site1.com.2 www.site1.com (mover atómicamente los cambios a producción)

Esto garantiza que ninguno de mis usuarios termine viendo una página a medias. Verán la versión anterior si todavía está en su caché, o la nueva.

Esta estrategia solo funciona bien si no está mezclando contenido cargado por el usuario con su sitio dinámico.

1
JasonBirch

Utilizamos ant's tarea scp , con selector modificado . Eso significa que solo actualiza los archivos que han cambiado desde la carga anterior. Desafortunadamente, el selector modificado parece estar diseñado solo para uso personal, no para compartir con los miembros del equipo. El archivo cache.properties tiene nombres de ruta al directorio de trabajo del usuario. Escribimos un montón de objetivos de hormigas para masajear el archivo cache.properties en un formato que se pueda compartir entre los desarrolladores y luego volver a masajear en el formato que las hormigas necesitan. El formato también varía entre un entorno Windows y un entorno GNU/Linux.

0
Don Kirkby

¿No es necesario utilizar el control de versiones para no tener que preocuparse por hacer una copia de seguridad del sitio antes de lanzar una actualización?

Si se hace correctamente, un svn update (o equivalente) debería ser suficiente, y si es un error, ¿lo revierte a un commit anterior? Eso es lo que hacemos de todos modos. Confirme todos los cambios, svn update el servidor intermedio, si todo está bien, entonces svn update el servidor en vivo.

0
Mark Henderson