¿Cómo empezar a implementar aplicaciones PHP desde un repositorio de Subversion?

StackOverflow https://stackoverflow.com/questions/800294

Pregunta

He escuchado la frase "implementando aplicaciones" que suena mucho mejor / más fácil / más confiable que cargar archivos modificados individuales en un servidor, pero no sé por dónde empezar.

Tengo una aplicación Zend Framework que está bajo el control de versiones (en un repositorio de Subversion). ¿Cómo hago para " desplegar " ¿mi aplicación? ¿Qué debo hacer si tengo un " subidas " directorio que no quiero sobrescribir?

Alojo mi aplicación a través de un tercero, por lo que no sé mucho más que FTP. Si algo de esto implica iniciar sesión en mi servidor, explique el proceso.

¿Fue útil?

Solución

El despliegue automático + la ejecución de pruebas en un servidor de pruebas se conoce como integración continua. La idea es que si registra algo que rompe las pruebas, se le notificará de inmediato. Para PHP, puede consultar Xinc o phpUnderControl

Por lo general, no desea implementar automáticamente en producción. Lo normal es escribir algunos scripts que automatizan la tarea, pero que todavía necesita iniciar manualmente. Puede usar marcos como Phing u otras herramientas de compilación para esto (una opción popular es Capistrano ), pero también puedes mezclar algunos shell-scripts juntos. Personalmente prefiero este último.

Los scripts en sí podrían hacer cosas diferentes, dependiendo de su aplicación y configuración, pero un proceso típico sería:

  • ssh al servidor de producción. El resto de los comandos se ejecutan en el servidor de producción, a través de ssh.
  • ejecute svn export svn: // ruta / a / repository / tags / RELEASE_VERSION / usr / local / application / releases / TIMESTAMP
  • servicios de parada (Apache, demonios)
  • ejecute unlink / usr / local / application / current & amp; & amp; ln -s / usr / local / application / releases / TIMESTAMP / usr / local / application / current
  • ejecute ln -s / usr / local / application / var / usr / local / application / releases / TIMESTAMP / var
  • ejecute /usr/local/application/current/scripts/migrate.php
  • iniciar servicios

(Suponiendo que tenga su aplicación en / usr / local / application / current )

Otros consejos

No recomendaría la actualización automática. Solo porque sus pruebas de unidad pasen no significa que su aplicación esté funcionando al 100%. ¿Qué sucede si alguien comprueba una nueva función aleatoria sin nuevas pruebas de unidad y la función no funciona? Sus pruebas de unidad existentes podrían pasar, pero la función podría romperse de todos modos. Sus usuarios pueden ver algo que está a medio hacer. Con la implementación automática desde un check-in, es posible que no se dé cuenta durante algunas horas si algo lo hizo en vivo y no debería haberlo hecho.

De todos modos, no sería tan difícil lograr un despliegue automático si realmente quisiera. Necesitaría un enlace posterior al check-in, y realmente los pasos serían:

1) Realice una exportación desde el último check-in 2) Subir exportación al servidor de producción 3) Desempaquetar / configurar la exportación recién cargada

Siempre he realizado los últimos pasos manualmente. En general, es tan simple como SVN exportar, comprimir, cargar, descomprimir, configurar, y los dos últimos pasos, simplemente alias un par de comandos de bash para realizarlos. Luego cambio el directorio de la aplicación raíz por el nuevo, asegurándome de mantener el anterior como copia de seguridad, y es bueno.

Si confía en su capacidad para detectar errores antes de que se activen automáticamente, entonces podría considerar la automatización de ese procedimiento. Aunque me da el jibbly-jibblies.

Este es un excelente artículo sobre el uso de Subversion para implementar proyectos web & # 8212; responde muchas de tus preguntas.

http://athleticsnyc.com/blog/entry/ on-using-subversion-for-web-projects

En mi empresa webdev, recientemente comenzamos a utilizar Webistrano , que es una GUI web para el popular Capistrano. herramienta.

Queríamos una herramienta de implementación rápida y fácil de usar con una interfaz centralizada, responsabilidad (quién implementó qué versión), revertir a versiones anteriores y preferiblemente gratis. Capistrano es conocido como una herramienta de implementación para las aplicaciones Ruby on Rails, pero no está centralizado y está dirigido principalmente a las aplicaciones Rails. Webistrano lo mejora con una GUI, responsabilidad y agrega soporte básico para la implementación de PHP (use el tipo de proyecto 'archivo puro').

Webistrano es en sí mismo una aplicación de Ruby on Rails, que instala en un servidor de desarrollo o de prueba. Usted agrega un proyecto para cada uno de sus sitios web. A cada proyecto agregas etapas, como Prod y Dev.

Cada etapa puede tener diferentes servidores para implementar y diferentes configuraciones. Escribe (o modifica) una 'receta', que es un script de rubí que le dice a capistrano qué hacer. En nuestro caso, solo utilicé la receta suministrada y agregué un comando para crear un enlace simbólico a un directorio de cargas compartidas, tal como mencionaste.

Cuando hace clic en Implementar, los SSH de Webistrano en sus servidores remotos, realiza una verificación svn del código, y cualquier otra tarea que requiera, como migraciones de bases de datos, enlaces simbólicos o limpieza de versiones anteriores. Todo esto se puede modificar, por supuesto, después de todo, es simplemente un script.

Estamos muy contentos con eso, pero me tomó unos días aprender y configurar, especialmente porque no estaba familiarizado con Ruby y Rails. Sin embargo, puedo recomendarlo para uso de producción en pequeñas y medianas empresas, ya que se ha demostrado que es muy confiable, flexible y nos ha ahorrado muchas veces la inversión inicial. No solo acelerando las implementaciones, sino también reduciendo errores / accidentes.

Este tipo de cosas es lo que llamarías " Integración continua " ;. Atlassian Bamboo (costo), Sun Hudson (gratis) y Cruise Control (gratis) son todas las opciones populares (en orden de mis preferencias) y tienen soporte para manejar la salida PHPUnit (porque PHPUnit admite la salida JUnit).

El material de implementación se puede hacer con un desencadenante posterior a la construcción. Al igual que otras personas en este hilo, me gustaría tener mucho cuidado antes de hacer implementaciones automatizadas en el registro (y aprobación de prueba).

cheque fredistrano, es un clon capistrano funciona muy bien (instalación poco confusa, pero después de todo funciona muy bien)

http://code.google.com/p/fredistrano/

Para manejar las subidas, la solución clásica es mover el directorio real fuera del espacio web principal, dejándolo solo para que se revise una versión nueva (como lo hago en el script a continuación) y luego usar Apache para 'Alias' Vuelve a su lugar como parte del sitio web. 

Alias /uploads /home/user/uploads/

Sin embargo, tienes menos opciones si no tienes el control del servidor.

Tengo un script que uso para implementar un script dado en los sitios dev / live (ambos se ejecutan en el mismo servidor). 

#!/bin/sh

REV=2410
REVDIR=$REV.20090602-1027

REPOSITORY=svn+ssh://topbit@svn.example.com/var/svn/website.com/trunk
IMAGES=$REVDIR/php/i
STATIC1=$REVDIR/anothersite.co.uk

svn export --revision $REV  $REPOSITORY $REVDIR

mkdir -p $REVDIR/tmp/templates_c
chown -R username: $REVDIR
chmod -R 777       $REVDIR/tmp $REVDIR/php/cache/
chown -R nobody:   $REVDIR/tmp $REVDIR/php/cache/ $IMAGES
dos2unix $REVDIR/bin/*sh  $REVDIR/bin/*php
chmod 755 $REVDIR/bin/*sh $REVDIR/bin/*php

# chmod -x all the non-directories in images
find $IMAGES -type f -perm -a+x | xargs -r chmod --quiet -x
find $STATIC1 -type f -perm -a+x | xargs -r chmod --quiet -x

ls -l $IMAGES/* | grep -- "-x"

rm dev && ln -s $REVDIR dev

Pongo el número de revisión y la fecha / hora que se usa para el nombre del directorio desprotegido. Los chmod en el medio también hacen que los permisos sobre las imágenes estén bien, ya que también están vinculados a nuestro servidor de imágenes dedicado.

Lo último que sucede es un enlace simbólico antiguo ... / website / dev / se vuelve a vincular con el directorio recién desprotegido. La configuración de Apache tiene una raíz doc de ... / website / dev / htdocs /

También hay un ... / website / live / htdocs / docroot coincidente, y otra vez, 'live' es otro enlace simbólico. Este es mi otro script que eliminará el enlace simbólico en vivo, y lo reemplazará con cualquier punto dev. 

#!/bin/sh
# remove live, and copy the dir pointed to by dev, to be the live symlink
rm live && cp -d dev live

Solo estoy presionando una nueva versión del sitio cada pocos dats, por lo que es posible que no quieras usar esto varias veces al día (a mi caché de APC no le gustaría más que unas pocas versiones del sitio), pero para mí, encuentro que esto es muy libre de problemas para mi propia implementación.

Después de 3 años, he aprendido un poco sobre las mejores prácticas de implementación. Actualmente utilizo una herramienta llamada Capistrano porque es fácil de configurar y usar, y maneja muy bien muchos valores predeterminados.

Los conceptos básicos de un proceso de implementación automatizada son los siguientes:

  1. Su código está listo para la producción, por lo que está etiquetado con la versión del lanzamiento: v1.0.0
  2. Suponiendo que ya ha configurado su script de implementación, ejecuta su script, especificando la etiqueta que acaba de crear.

  3. El script SSH sobre su servidor de producción que tiene la siguiente estructura de directorio: 

    /your-application
    /shared/
        /logs
        /uploads
    /releases/
        /20120917120000
        /20120918120000  <-- latest release of your app
            /app
            /config
            /public
            ...etc
    /current --> symlink to latest release

Your Apache document root should be set to /your-application/current/public

  4. El script crea un nuevo directorio en el directorio de versiones con la fecha y hora actual. Dentro de ese directorio, su código se actualiza a la etiqueta que especificó.

  5. Luego se elimina el enlace simbólico original y se crea un nuevo enlace simbólico, que apunta a la última versión.

Las cosas que deben mantenerse entre las versiones van en el directorio compartido, y los enlaces simbólicos se crean en esos directorios compartidos.

Depende de su aplicación y de la solidez de las pruebas.

Donde trabajo, todo se registra en el repositorio para su revisión y luego se libera.

La actualización automática de un repositorio no sería inteligente para nosotros, ya que a veces simplemente nos registramos para que otros desarrolladores puedan usar una versión posterior y fusionar los cambios.

Para hacer lo que está hablando, se necesitaría algún tipo de control secundario de entrada y salida para permitir la colaboración entre los desarrolladores en el área de control principal. Aunque no sé nada sobre eso o si es posible.

También hay problemas con la ramificación y otras características similares que deberían manejarse.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top