2009-07-17 22 views
22

Cómo implementar correctamente aplicaciones desde el desarrollo hasta la producción y cómo lidiar con múltiples configuraciones de sitios. Todos mis desarrollos se realizan a través de svn ubicado en var/svn/myapp/trunk y el código de producción real está en/var/www/myapp.¿Cómo implementar correctamente sus aplicaciones PHP?

Reviso el último código de mi máquina local en un directorio llamado "myapp_latest_svn". tengo sitio y código específico de ubicación en mi settings.php principal, que tiene H_PATH = '' http://myapp.com ajustes de configuración & DB para db_host, db_user_name y contraseña_bd que es como saben diferente en configuración del equipo local (donde localhost/miaplicacion. com es solo un alias de Apache) & en el servidor de producción (el sitio en vivo se ejecuta en myapp.com).

También el archivo .htaccess es diferente del del servidor de producción. En resumen, hay una serie de diferencias entre dev y producción.

Guardo todo mi trabajo en SVN. Cada mañana uso SVN Update que actualiza el código más reciente a mi repositorio svn local. Cuando estoy listo para comenzar, construyo un lanzamiento con svn Commit.

Luego, en el lanzamiento, tengo que recordar cambiar todos los archivos dev apropiados a su contraparte de producción. Ahora tuve que editar manualmente la configuración de producción.php & .htaccess para reflejar los cambios específicos del sitio.

Estoy buscando una forma automática de ir de desarrollo a producción completa con control de versiones y sin edición manual de archivos que es propenso a errores y mala práctica.

Una forma es hacer que la versión de producción de los archivos sea de solo lectura (0444). De esta forma, cuando hago una exportación de svn, , no se sobrescriben con la versión dev de los archivos y no tengo que preocuparme por editar los archivos en cada vez que paso de dev a producción. Pero esa es una mala forma de hacer cosas como la integración continua.

También haciendo copias múltiples de settings.php (una para localhost, beta y prod). Luego, usando un script de shell que exporta desde svn, y luego una vez que se realiza la exportación, reemplaza settings.php con la configuración correcta.php, dependiendo de la ubicación en la que estamos implementando. De esa forma todo está automatizado. Pero esto también es un camino flojo por recorrer.

Última manera es

if(eregi ("myapp.com$", $_SERVER['HTTP_HOST'])){ 

    define('H_PATH', 'myapp.com'); 

} else { 

    define('H_PATH', 'localmyapp.com'); 

} 

Esto está muy bien en lo que se refiere a settings.php. Pero, ¿qué pasa con el .htaccess, no se puede verificar como se describe en .htaccess.

Lo que no quiero terminar haciendo cada vez que despliegue mi sitio que tengo que cambiar la configuración.

Mi esquema de base de datos no está en control de versión, por lo que db no es un problema conmigo, solo los settings.php y .htaccess.

Además, ¿cómo puedo decirle a svn que no actualice algunos directorios ya que también es específico del sitio (/ log,/cache,/assets,/downloads). También necesito preservar el acceso de escritura de apache (www_data) intacto para los archivos anteriores también.

Por último, no quiero copiar el directorio troncal vacío y los archivos .svn en el servidor de producción cuando exporto.

¿Cómo puedo usar Phing o incluso un script de shell para integrar sin causar ninguno de estos problemas al construir desde svn a los servidores de producción.

Esto podría ser útil para muchos desarrolladores de aplicaciones wannabe en la naturaleza.

Gracias de antemano,

ocptime

Respuesta

13

me gustaría recomendar que miran Capistrano para sus problemas de implementación. Lo usé para implementar sistemas PHP, y hará todo lo que describa (con un pequeño script en su receta de implementación).

No guardo ningún archivo de configuración en mi repositorio remoto: cuando pago en dev, puedo agregarlos una vez, y luego ignorarlos para no verlos por accidente. Cuando se trata de implementar, mi receta de implementación de tapa está configurada para que escriba los archivos de configuración en la versión desplegada. De esta manera, nunca tengo que preocuparme por implementar y perder algo crítico.

Cap también se ocupa de los activos cargados (enlaces simbólicos de los directorios para que permanezcan en su lugar en cada implementación) y también respalda automáticamente todos los archivos de activos y la base de datos en implementación en Amazon S3. Muy ingenioso, ¿eh?

+0

Gran enlace! ¡Gracias! –

+0

¿Podría explicar qué hacen los directorios de enlaces simbólicos? – dave1010

2

Guardo mis archivos de configuración y .haccess en SVN con nombre de archivo renombrado, p. settings.php.example y .htaccess.example. De esta manera, cuando creo un nuevo lanzamiento, no necesito preocuparme por sobrescribir cosas.

8

Tengo una tarea Phing llamada config, que me pregunta en qué entorno me gustaría configurar el código. La tarea acepta varios valores posibles: local, desarrollo, puesta en escena, producción, etc.

Una vez que lo cuento el medio ambiente, se lee en el archivo .properties apropiado (es decir local.properties, production.properties, etc)

El siguiente paso será la clave para usted: almacene las PLANTILLAS de su configuración y los archivos htaccess, luego ejecute una tarea filterChain replaceTokens para que sus tokens sean reemplazados por los valores del archivo de propiedades.

crear estos archivos:

común/construcción/templates/settings.tpl

define('H_PATH','##H_PATH##'); 
define('ENVIRONMENT', '##ENVIRONMENT##'); 

acumulación/templates/htaccess.tpl

http://##H_PATH## 

build/propiedades/local.properties

site.H_PATH = localmyapp.com 
site.ENVIRONMENT = local 

build/properties/production.properties

site.H_PATH = myapp.com 
site.ENVIRONMENT = production 

common/build/build.xml

<target name="config"> 
    <input propertyname="env" validargs="local,production">Enter environment name:</input> 
    <property file="build/properties/${environment}.properties" /> 
    <copy file="build/templates/settings.tpl" 
    tofile="config/settings.php" overwrite="true"> 
    <filterchain> 
     <replacetokens begintoken="##" endtoken="##">  
      <token key="H_PATH" value="${site.H_PATH}" /> 
      <token key="ENVIRONMENT" value="${site.ENVIRONMENT}" /> 
     </replacetokens>   
    </filterchain> 
    </copy>  
    <copy file="build/templates/htaccess.tpl" 
    tofile="public/.htaccess" overwrite="true">  
    <filterchain> 
     <replacetokens begintoken="##" endtoken="##">  
      <token key="H_PATH" value="${site.H_PATH}" />               
     </replacetokens>   
    </filterchain> 
    </copy>    
    <echo msg="Configured settings.php and .htaccess for ${environment}" />    
</target>        

Ahora, cuando se desea configurar el sitio para ejecutar localmente sólo tiene que escribir:

phing config 

continuación, escriba:

local 

y pulse retorno. ¡Eso es! Un gran beneficio de esto es que ya no necesita NINGUNA declaración if/else en su código. Además, no depende de las variables $ _SERVER, por lo que funcionará correctamente en la línea de comandos.

0

puedes pensar en Capistrano, Magallanes, Deployer, pero también están los script. Le recomiendo que pruebe walle-web, una herramienta de implementación escrita en PHP con yii2 lista para usar. Lo he alojado en nuestra compañía durante meses, funciona sin problemas durante la implementación de prueba, simulación, entorno de producción.

Le permite configurar tareas previas al despliegue, posteriores a la implementación y posteriores al lanzamiento, luego puede cambiar la configuración del entorno, como cp db_test.php db.php.

enter image description here

que dependen de grupos de herramientas de bash, rsync, git, enlace, pero una interfaz de usuario web en general bien para la operación, tener una oportunidad :)

Cuestiones relacionadas