Mantener las diferencias de configuración entre los entornos de desarrollo y en vivo durante la implementación desde SVN.

Question

Utilizamos el CMS ExpressionEngine (php) para crear sitios web.Para cada sitio, configuramos un repositorio de subversion y confirmamos la instalación de EE, así como cualquier plantilla personalizada, imágenes, javascript, etc.que se utilizan.En el repositorio se incluye el archivo que contiene todas las variables de entorno y el archivo .htaccess.

Contamos con un servidor de desarrollo con una copia de trabajo del repositorio actualizado mediante post-commit que utilizamos para desarrollar.Cuando estemos listos para lanzar, creamos una rama en subversion, realizamos los cambios necesarios para el entorno de producción, etiquetamos el número de versión, exportamos el repositorio, lo subimos a un nuevo directorio en el servidor en vivo y vinculamos simbólicamente los archivos a su lugar.Una reversión es tan simple como volver a crear un enlace simbólico a la versión anterior.

El problema es ese paso en el que tenemos que modificar las variables de entorno que deben ser diferentes para los servidores de desarrollo y producción.Se trata de cosas como (des)comentar reglas de htaccess que redirigirían a lugares equivocados, intercambiar claves API de Google Map porque los dominios son diferentes, ejecutar scripts que minimizan el javascript en un archivo ofuscado para mantener bajos el tamaño y las conexiones http, etc. .

La pregunta es ¿cómo podría esto ser más automatizado?Nos encantaría reducir el procedimiento de liberación al mínimo indispensable.Estoy familiarizado con la existencia de herramientas como Capistrano y Make pero no estoy seguro de cómo podría lograr que modifiquen todos los archivos necesarios...¿Cómo organizarías algo así?¿Vale la pena dedicar tiempo a la automatización cuando sucede tal vez una vez cada dos semanas?

Answer 1

Muchas de las opciones de configuración podría abordarse mediante el encendido de $ _SERVER [ 'HTTP_HOST'].

Por ejemplo

switch ($_SERVER['HTTP_HOST']) {
    case 'developement.domain.com':
        $api_key = "dev environment api key";
        break;
    default:
        $api_key = "live environment api key";
}

A continuación, por cuestiones .htaccess puede configurar un archivo .htaccess alternativo en la definición de host virtual utilizando la AccessFileName:

<VirtualHost *:80>
    ServerName sitename
    AccessFileName .htaccess-dev
</VirtualHost>

Answer 2

Lidio con este problema agregando un archivo de configuración a Lista de ignorados de subversión.Ya se abordó aquí en Stackoverflow: ver pregunta #149485

Básicamente, sólo mantengo setup.default.php en SVN, y en cada instalación lo copio manualmente a setup.php que está en la lista de ignorados.Esto evita que el archivo se vuelva a registrar en el repositorio.Rara vez se realizan cambios en este archivo y se puede gestionar a medida que se presente el requisito.

Answer 3

Otra alternativa es la rama de los archivos de configuración de una vez, en una rama de lanzamiento, y luego los marcan como han sido editados en el destino, y luego usar un script de mezcla que recuerda cómo hacer una fusión a tres bandas. Si los cambios de configuración en la fuente, entonces probablemente va a generar un conflicto, lo cual es una buena cosa, porque es probable que tenga que hacer cambios similares en el destino.

Por lo tanto, se mantiene dos árboles que van para el tiempo de vida del proyecto: el desarrollo y la liberación. A medida que maduran las cosas en el desarrollo, que integrarlas a liberar. Puede tener una tercera, control de calidad, árbol, así, si usted tiene un proceso de liberación más complicado.

Cuando tiras una nueva versión, se copia desde el área de trabajo a la zona de "liberación" (como una fusión / integración), en lugar de tirar de una nueva rama. Si también desea una instantánea en el tiempo de la liberación de árboles en ese punto, a continuación, hacer una copia / etiqueta separada rama / que utilice únicamente con fines de archivo.

Por cierto:. Esta es una de las áreas en las que brilla Perforce - recuerda lo que ya se fusionaron, y no siempre intentará fusionar dos veces

Answer 4

Nos ocupamos de esto manteniendo un directorio-configuración específica.

Así, por ejemplo, si usted tiene diferentes archivos .htaccess y config.php entre dev y la producción serían mantenidos en / / config / {entorno} trunk /

utilizar scripts / Nant hormigas para crear paquetes de liberación, y los guiones tienen una tarea de construcción para cada entorno. Esas tareas recogen los archivos de configuración específicos.

-

Otro comentarista sugiere para encender HTTP_POST. Lamentablemente no puedo comentar directamente (no un alto representante suficiente). Usando HTTP_POST para determinar la configuración del medio ambiente tiene problemas de seguridad ya que el valor de esto viene desde el cliente.