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

Question

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

Tengo una aplicación de Zend Framework que está bajo control de versiones (en un repositorio de Subversion). ¿Cómo hago para "implementar" mi aplicación? ¿Qué debo hacer si tengo un directorio de "cargas" 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 el inicio de sesión en mi servidor, explique el proceso.

Answer 1

La implementación automática + ejecución de pruebas en un servidor intermedio se conoce como integración continua. La idea es que si ingresas algo que rompe las pruebas, recibirías una notificación de inmediato. Para PHP, es posible que desee ver en Xinc o phpUnderControl

Te generalmente no desea implementar automáticamente a la producción embargo. Lo normal es escribir algunas secuencias de comandos que automaticen la tarea, pero que aún tenga que iniciar manualmente. Puede usar frameworks como Phing u otras herramientas de compilación para esto (una opción popular es Capistrano), pero también puede simplemente mezclar unos pocos shell-scripts. Personalmente prefiero este último.

Los scripts mismos podían hacer cosas diferentes, dependiendo de su aplicación y puesta en marcha, sino 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.
• ejecución svn export svn://path/to/repository/tags/RELEASE_VERSION /usr/local/application/releases/TIMESTAMP
• servicios de parada (Apache, demonios)
• ejecución unlink /usr/local/application/current && ln -s /usr/local/application/releases/TIMESTAMP /usr/local/application/current
• ejecución ln -s /usr/local/application/var /usr/local/application/releases/TIMESTAMP/var
• plazo /usr/local/application/current/scripts/migrate.php
• Iniciar servicios

(Asumiendo que tiene su aplicación en /usr/local/application/current)

Answer 2

Depende de su aplicación y de cuán sólidas sean las pruebas.

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

Auto actualización de un repositorio no sería inteligente para nosotros, ya que a veces sólo el proceso de registro para que otros desarrolladores pueden tirar de una versión posterior y combinar Hay cambios en.

para hacer lo que está hablando necesitaría algún tipo de check in y out secundario para permitir la colaboración entre desarrolladores en el área de control primario. Aunque no sé nada de eso o si es posible.

También hay problemas con la bifurcación y otras características similares que tendrían que ser manejadas.

Answer 3

No recomendaría la actualización automática. El hecho de que su unidad pase las pruebas no significa que su aplicación esté funcionando al 100%. ¿Qué ocurre si alguien ingresa una nueva característica aleatoria sin pruebas de unidades nuevas y la característica no funciona? Sus pruebas de unidad existentes pueden pasar, pero la característica podría romperse de todos modos. Sus usuarios pueden ver algo que está medio hecho. Con el despliegue automático de un check-in, es probable que no se dé cuenta por unas horas si algo lo hizo en vivo y no debería haberlo hecho.

De todos modos, no sería tan difícil conseguir un despliegue automático si realmente quisieras. Se necesitaría un gancho-registro de entrada de correos, y realmente los pasos serían:

1) Haz una exportación del registro de entrada sólo 2) Sube exportación al servidor de producción 3) Desempaquetar/config el recién exportación cargada

Siempre realicé los últimos pasos manualmente. En general, es tan simple como exportar SVN, comprimir, cargar, descomprimir, configurar, y los dos últimos pasos solo me dan un par de comandos bash para realizar. Luego cambio el directorio de la aplicación raíz por el nuevo, asegurándome de mantener el anterior como una copia de seguridad, y está bien.

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. Sin embargo, me da jibbly-jibblies.

Answer 4

Aquí hay un excelente artículo sobre el uso de Subversion para implementar proyectos web: responde muchas de sus preguntas.

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

Answer 5

Este tipo de cosas es lo que podría llamarse "Integración Continua". Atlassian Bamboo (costo), Sun Hudson (gratis) y Cruise Control (gratis) son todas opciones populares (en orden de mi preferencia) y tienen soporte para manejar la salida de PHPUnit (porque PHPUnit admite salida de JUnit).

La implementación se puede hacer con un desencadenador de compilación posterior. Al igual que otras personas en este hilo, tendría mucho cuidado antes de realizar implementaciones automatizadas en el checkin (y el paso de prueba).

Answer 6

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

Alias /uploads /home/user/uploads/ 

Hay menos opciones para usted si no tiene el mismo control del servidor.

Tengo un script que utilizo para implementar un script determinado 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 

puse el número Revison, y fecha/hora que se utiliza para el nombre del directorio desprotegido. Los chmod en el medio también hacen que los permisos en las imágenes estén bien, ya que también están enlazados a nuestro servidor de imágenes dedicado.

Lo último que sucede es un enlace simbólico antiguo .../sitio web/dev/se vuelve a vincular al directorio recién desprotegido. La configuración de Apache tiene un doc-root de .../website/dev/htdocs/

También hay una coincidencia .../website/live/htdocs/docroot, y nuevamente, 'live' es otro enlace simbólico. Esta es mi otra secuencia de comandos que eliminará el enlace simbólico en vivo y lo reemplazará con cualquier punto de revelado.

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

sólo estoy empujando una nueva versión del sitio cada pocos dats, por lo que puede que no desee estar usando esto varias veces al día (mi caché APC no le gustaría más que unas pocas versiones de la sitio alrededor), pero para mí, me parece que no hay problemas para mi propia implementación.

Answer 7

cheque fredistrano, que es un clon de Capistrano funciona muy bien (poco corta instalación confuso pero después de todo funciona muy bien)

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

Answer 8

En mi empresa WebDev recientemente comenzó a usar Webistrano, que es una interfaz gráfica de usuario Web de la popular herramienta Capistrano.

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), reversión a versiones anteriores y preferiblemente gratis. Capistrano es bien conocido como una herramienta de implementación para las aplicaciones de Ruby on Rails, pero no está centralizada y está dirigida principalmente a las aplicaciones de Rails. Webistrano lo mejora con una GUI, responsabilidad y agrega soporte básico para la implementación de PHP (use el tipo de proyecto 'pure file').

Webistrano es una aplicación de Ruby on Rails que se instala en un servidor de desarrollo o de etapas. Agrega un proyecto para cada uno de sus sitios web. Para cada proyecto, agrega etapas, como Prod y Dev.

Cada etapa puede tener diferentes servidores para implementar y diferentes configuraciones. Escriba (o modifique) una 'receta', que es un guión ruby ​​que le dice a capistrano qué hacer. En nuestro caso, acabo de utilizar la receta suministrada y agregué un comando para crear un enlace simbólico a un directorio de carga compartido, tal como lo mencionó.

Cuando hace clic en Implementar, Webistrano SSH en su (s) servidor (es) remoto, realiza una comprobación svn del código y cualquier otra tarea que requiera como migraciones de base de datos, enlace simbólico o limpieza de versiones anteriores. Todo esto puede modificarse, por supuesto, después de todo, simplemente está escrito.

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

Answer 9

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

Los fundamentos de un proceso de implementación automatizada dice así:

1. Su código está listo para la producción, por lo que se etiqueta con la versión de la versión: v1.0.0
2. Suponiendo que ya ha configuró su secuencia de comandos de implementación, ejecuta su secuencia de comandos y especifica la etiqueta que acaba de crear.

3. La secuencia de comandos de SSH a su servidor de producción que tiene la siguiente estructura de directorios:

   /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 comunicados con la fecha y hora actual. Dentro de ese directorio, su código se actualiza a la etiqueta que especificó.

5. A continuación, 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.