Cómo hacer una implementación para la aplicación php

Question

Actualmente estoy desarrollando una aplicación php para una organización benéfica y ahora estoy en la etapa de definición de las prácticas de implementación.

Nuestra aplicación utiliza Zend Framework y Doctrine. La aplicación se implementará en diferentes servidores, cada uno con un archivo de configuración diferente. Las máquinas son Windows y Linux (pero todas con Apache y php 5.2+).

La fuente está disponible en un repositorio de subversión y queremos construir y almacenar nuestros paquetes en un servidor Linux.

Preferiblemente queremos que el proceso de actualización sea tan fácil como ejecutar un comando de actualización en el directorio de la aplicación, donde el comando de actualización también actualiza la base de datos (con los scripts de doctrina) y asegura las dependencias de los marcos. Este comando de actualización debe ser un comando en la máquina (no podemos ingresar a ellos). Preferiblemente tenemos la opción de descargar una nueva versión o proporcionar un tarball ya descargado con una nueva versión. (pero solo descargando o solo tarball también está bien)

Los paquetes con instalaciones y actualizaciones (nuevas versiones) también se compilan preferentemente con un solo comando.

He estado leyendo un poco sobre phar's, pear, phing pero no tengo idea de cuál es la mejor manera de hacerlo. Un servidor de integración continua no es realmente necesario, pero pienso en implementar entornos de prueba automáticamente después de compilar una versión.

Inicialmente, solo la actualización de la aplicación php tiene que ser muy fácil, llenando inicialmente un archivo de configuración cuando la instalación se puede hacer a mano.

Answer 1

Has dicho que tienes un claster. Estamos en la misma posición y usamos ZF y Doctrine. Así es como hemos resuelto el problema:

<?xml version="1.0" encoding="UTF-8"?> 
<project name="yourprojectname" basedir="."> 

<target name="deploy" depends="apply-deltas,update-app01,update-app02"> 

</target> 

<target name="update-app01"> 

    <sshexec host="app01" 
    username="yourusername" 
    password="yourpassword" 
    trust="true" 
    command="cd path/to/root/directory &amp;&amp; 
     svn update &amp;&amp; 
     php cmd/clear_cache.php 
     "/> 

</target> 

<target name="update-app02"> 

    <sshexec host="app02" 
     username="yourusername" 
     password="yourpassword" 
     trust="true" 
     command="cd path/to/root/directory &amp;&amp; 
     svn update &amp;&amp; 
     php cmd/clear_cache.php 
     "/> 

</target> 

    <target name="apply-deltas" depends="liquibase-prepare"> 
    <updateDatabase 
      changeLogFile="${db.changelog.file}" 
      driver="${database.driver}" 
      url="${database.url}" 
      username="${database.username}" 
      password="${database.password}" 
      promptOnNonLocalDatabase="${prompt.user.if.not.local.database}" 
      dropFirst="false" 
      classpathref="classpath" > 
      <changeLogProperty name="table.name" value="ant_param_table"/> 
    </updateDatabase> 
    </target> 


<target name="liquibase-prepare"> 
    <path id="classpath"> 
    <fileset dir="${basedir}/libNoPackage"> 
     <include name="**/*.jar" /> 
    </fileset> 
    </path> 

    <taskdef resource="liquibasetasks.properties"> 
     <classpath refid="classpath"/> 
    </taskdef> 
    </target> 

</project> 

Esto está lejos de ser ideal pero funciona bien para nosotros. Espero que ayude.

Enlaces:

Apache Ant

LiquiBase

Si usted tiene algunas preguntas por favor hágamelo saber para que pueda actualizar el answer.t

Answer 2

Tal vez a veces un enfoque más simple funciona mejor . Si mantiene los lanzamientos estables simplemente etiquetados dentro del svn repo, entonces puede simplemente escribir un script batch/bash para descargar la última revisión mientras hace una copia de seguridad anterior sin intervención del usuario; también puede ejecutar los scripts requeridos de esta manera. Otra alternativa es escribir una interfaz simple para esto en PHP, pero depende de cuán simple debe ser.

Answer 3

Comenzaría haciendo que la raíz de la aplicación de los diversos servidores sea una copia de trabajo de SVN. Puede agregar reglas mod_rewrite (o IIRF ASAPI filters for IIS) para asegurarse de que las personas no puedan direccionar sus directorios .svn directamente.

Luego, la actualización a la última fuente puede ser tan simple como una actualización de SVN. Para las necesidades de actualización de su base de datos, mantendría las secuencias de comandos de modificación de la base de datos también en SVN. Es probable que deba envolver la actualización de SVN en un script por lotes/shell para realizar las actualizaciones de la base de datos después de que se descarguen los scripts.

Para la gestión del cambio en los servidores en vivo, también tendría sus copias de trabajo no de tronco, sino una rama de lanzamiento. Puede fusionar el tronco en la rama de liberación cuando esté listo para un lanzamiento. Esto le permitirá probar la implementación y asegurarse de que sea sólida antes de realizarla en los servidores activos. También tiene el agradable efecto secundario de darle una buena réplica de las versiones de lanzamiento del sitio en caso de que necesite localizar los problemas posteriores al lanzamiento.

Por último, dependiendo de la intensidad y el tiempo de estas actualizaciones, es posible que desee que su script de actualización cambie de "mantenimiento" para que los usuarios se encuentren temporalmente con un mensaje correcto en lugar de roto.

Answer 4

Benjamin Eberlei publicó un blog hace unas semanas titulado Trying a Two Step PEAR/PHAR approach to develop and deploy. Describe que es un procedimiento muy interesante y elegante para implementar una aplicación PHP.

Answer 5

He utilizado subversion como una herramienta de implementación con gran efecto.

Use svn update en todos sus servidores de producción o use phing. (O use phing para actualizar svn, incluso.)

Realiza retrocesos y copias de seguridad. Solo recuerde eliminar el acceso a cualquier directorio .svn.

Answer 6

De cualquier manera, yo gestionaría tus compilaciones con phing o algo similar. Deje que ejecute sus pruebas, genere documentos, cree y publique su paquete/tarball.

En cuanto a la distribución, puede run your own PEAR server. La razón fundamental es que dijo que desea que los usuarios extraigan actualizaciones, tiene usuarios de Windows y Linux, y desea manejar dependencias para ellos. PEAR debería ser capaz de manejar todo eso con un solo comando.

Dicho esto, me gustaría ir con lo más simple que funciona y se adapta a sus usuarios. Eso podría ser simplemente un tarball disponible a través de HTTP y un pequeño script de actualización de PHP (o un objetivo de Phing).

Definitivamente proporciona una forma sencilla de deshacer la versión anterior. Con el código/configuración, puede guardar una copia. Con DB, use migraciones (lo que parece que ya está haciendo).