usar tortoise subversion que informatica hacer definicion como branches php svn zend-framework deployment setup-deployment

php - tortoise - svn merge branch to trunk



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

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

Tengo una aplicación de Zend Framework que está bajo control de versión (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?

Puedo alojar mi aplicación a través de un tercero, así que no sé mucho más que FTP. Si algo de esto implica el inicio de sesión en mi servidor, explique el proceso.

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

Donde trabajo, todo se revisa 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 obtener una versión posterior y fusionar allí los cambios.

Para hacer lo que está diciendo necesitaría algún tipo de control secundario para permitir la colaboración entre los 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 deberían manejarse.

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 conceptos básicos de un proceso de implementación automatizado son los siguientes:

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

  3. El script SSH está en 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. La secuencia de comandos crea un nuevo directorio en el directorio de lanzamientos con la fecha 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 lanzamientos van en el directorio compartido, y los enlaces simbólicos se crean a esos directorios compartidos.

En mi empresa webdev, recientemente comenzamos a usar Webistrano , que es una GUI web para 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 usted 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 (s), realiza una comprobación svn del código y cualquier otra tarea que necesite, como migraciones de bases 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, sobre todo porque no estaba familiarizado con Ruby y 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.

Este tipo de cosas es lo que llamarías "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 posterior a la compilación. 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).

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 buscar en Xinc o phpUnderControl

Sin embargo, en general no querrá implementar automáticamente en producción. 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 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.
  • ejecutar svn export svn://path/to/repository/tags/RELEASE_VERSION /usr/local/application/releases/TIMESTAMP
  • detener servicios (Apache, daemons)
  • ejecutar unlink /usr/local/application/current && ln -s /usr/local/application/releases/TIMESTAMP /usr/local/application/current
  • ejecutar ln -s /usr/local/application/var /usr/local/application/releases/TIMESTAMP/var
  • ejecutar /usr/local/application/current/scripts/migrate.php
  • iniciar servicios

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

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. Necesitarías un gancho de post-check-in, y realmente los pasos serían:

1) Realice una exportación desde el último check-in 2) Cargue la exportación al servidor de producción 3) Descomprima / config la exportación cargada recientemente

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.

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'' de nuevo en lugar como parte del sitio web.

Alias /uploads /home/user/uploads/

Sin embargo, hay menos opciones para usted si no tiene el control del servidor.

Tengo un script que uso 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://[email protected]/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 comprobado. 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 una raíz de documentación de ... / sitio web / dev / htdocs /

También hay una coincidencia ... / sitio web / en vivo / htdocs / docroot, y de nuevo, ''en vivo'' 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

Solo estoy presionando una nueva versión del sitio cada pocas fechas, por lo que es posible que no desee utilizar esto varias veces al día (mi caché APC no quiere más que unas pocas versiones del sitio), pero para mí , Me parece que esto no tiene problemas para mi propia implementación.