php - variable - todas las etiquetas de html5 y sus atributos pdf

¿Cómo implementar sus aplicaciones PHP correctamente?

Question

Cómo implementar correctamente las aplicaciones desde el desarrollo hasta la producción y cómo lidiar con múltiples configuraciones de sitio. Todo mi desarrollo se realiza a través de svn ubicado en var / svn / myapp / trunk y el código de producción real está en / var / www / myapp.

Reviso el último código de mi máquina local en un directorio llamado "myapp_latest_svn". Tengo un código específico de sitio y ubicación en mi configuración principal.php, que tiene H_PATH = '' http://myapp.com '' y configuraciones de configuración de db para db_host, db_user_name y db_password, que es como usted sabe diferente en la configuración de la máquina local /myapp.com es solo un alias de Apache) y en el servidor de producción (el sitio en vivo se ejecuta en myapp.com).

Además, el archivo .htaccess es diferente al del servidor de producción. En resumen, hay una serie de diferencias entre desarrollo y producción.

Mantengo todo mi trabajo en SVN. Todas las mañanas uso la actualización de SVN que actualiza el código más reciente en mi repositorio svn local. Cuando estoy listo para empezar a funcionar, compilo una versión con svn Commit.

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

Estoy buscando una forma automatizada de pasar del desarrollo a la producción completa con la creación de versiones y sin edición manual de archivos, lo que es propenso a errores y es una mala práctica.

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

También haciendo copias múltiples de settings.php (una para localhost, beta y prod). Luego, utilizando 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 estemos implementando. De esa forma todo se automatiza. Pero esta es también una manera aburrida de ir.

La ultima manera es

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

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

} else {

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

}

Esto está bien en lo que concierne a settings.php. Pero en lo que se refiere al .htaccess, no se puede verificar como el anterior en .htaccess.

Lo que no quiero que termine haciendo cada vez que implemento mi sitio, tengo que cambiar la configuración.

Mi esquema de base de datos no está en el control de versiones, por lo que db no es un problema para mí, solo la configuración.php y .htaccess.

También, ¿cómo puedo decirle a svn que no actualice algunos directorios ya que también es específico del sitio (/ log, / cache, / asset, / downloads)? También necesito conservar 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 al servidor de producción cuando exporto.

¿Cómo puedo usar Phing o incluso un script de shell para integrarlo sin causar ninguno de estos problemas al compilar desde svn a servidores de producción?

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

Gracias por adelantado,

en algún momento

Answer 1

Almaceno mis archivos de configuración y .haccess en SVN con nombres de archivos renombrados, por ejemplo, settings.php.example y .htaccess.example. De esta manera, cuando creo una nueva versión, no necesito preocuparme por sobrescribir cosas.

Answer 2

Puedes pensar en Capistrano, Magallanes, Deployer, pero también son scripts. Puedo recomendarte que pruebes walle-web , una herramienta de implementación escrita en PHP con yii2 lista para usar. Lo he alojado en nuestra empresa durante meses, funciona sin problemas al implementar pruebas, simular, entorno de producción.

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

Depende de grupos de herramientas bash, rsync, git, link, pero una interfaz de usuario web en general es buena para la operación, inténtalo :)

Answer 3

Te recomiendo que mires a Capistrano por tus problemas de despliegue. Lo usé para implementar sistemas PHP, y hará todo lo que describas (con un poco de trabajo de script en tu 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, así que no los verifico por accidente. Cuando se trata de la implementación, mi receta de implementación de la tapa se configura para que escriba los archivos de configuración en la versión implementada. De esta manera, nunca tengo que preocuparme por la implementación y perder nada crítico.

Cap también se ocupa de los activos cargados (vinculando los directorios para que permanezcan en cada implementación), y también realiza una copia de seguridad automática de todos los archivos de activos y la base de datos en la implementación en Amazon S3. Bastante ingenioso, ¿eh?

Answer 4

Tengo una tarea de 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 le digo el entorno, lee el archivo .properties apropiado (es decir, local.properties, production.properties, etc.)

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

Crea estos archivos:

common / build / templates / settings.tpl

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

construir / plantillas / htaccess.tpl

http://##H_PATH##

build / properties / local.properties

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

construir / propiedades / producción.propiedades

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 desee configurar el sitio para ejecutarse localmente, simplemente escriba:

phing config

a continuación, escriba:

local

y pulse volver. ¡Eso es! Una gran ventaja de esto es que ya no necesita CUALQUIER sentencia if / else en su código. Además, no depende de las variables $ _SERVER, por lo que funcionará bien en la línea de comandos.