¿Cuál es la mejor práctica para manejar información específica del sistema bajo el control de versiones?

Question

Soy nuevo en el control de versiones, por lo que me disculpo si hay una solución conocida para esto. En particular, para este problema, estoy usando git, pero tengo curiosidad por saber cómo lidiar con esto en todos los sistemas de control de versiones.

Estoy desarrollando una aplicación web en un servidor de desarrollo. He definido el nombre de ruta absoluta a la aplicación web (no la raíz del documento) en dos lugares. En el servidor de producción, esta ruta es diferente. Estoy confundido acerca de cómo lidiar con esto.

Yo podría:

1. Reconfigure el servidor de desarrollo para compartir la misma ruta que la producción
2. Edite las dos apariciones cada vez que se actualice la producción.

No me gusta el número 1 porque prefiero mantener la aplicación flexible para cualquier cambio futuro. No me gusta el # 2 porque si comienzo a desarrollar en un segundo servidor de desarrollo con un tercer camino, tendría que cambiar esto para cada confirmación y actualización.

¿Cuál es la mejor manera de manejar esto? Pensé en:

1. Uso de palabras clave personalizadas y expansión de variables (como establecer la propiedad $ PATH $ en las propiedades de control de versión y expandirla en todos los archivos). Git no admite esto porque sería un gran éxito de rendimiento.

2. Uso de enlaces posteriores a la actualización y de confirmación previa. Posiblemente la solución más probable para git, pero cada vez que miraba el estado, informaba que los dos archivos habían sido cambiados. No es realmente limpio.

3. Extraer la ruta de un archivo de configuración fuera del control de versiones. Entonces tendría que tener el archivo de configuración en la misma ubicación en todos los servidores. También podría tener el mismo camino para empezar.

¿Hay una manera fácil de lidiar con esto? ¿Lo estoy pensando demasiado?

Answer 1

NUNCA NUNCA los datos de configuración de código duro como las rutas del sistema de archivos y obligue a que coincidan varias implementaciones. Ese es el lado oscuro, donde hay mucho SUFRIMIENTO.

Me resulta útil y fácil compilar mis sistemas para que sean compatibles con múltiples configuraciones fácilmente, y de forma rutinaria confirma los archivos de configuración en el control de origen lado a lado, pero la producción está ofuscada (no hay contraseñas reales) y el desarrollo está programado (por lo que la comprobación no puede sobrescribir la configuración de un desarrollador). El código siempre se empaqueta de manera neutral para la configuración: el mismo binario se puede implementar en cualquier lugar.

Desafortunadamente, la mayoría de las plataformas de desarrollo / lenguaje no lo admiten fácilmente (a diferencia de Ruby on Rails). Por lo tanto, tienes que construirlo tú mismo, en diversos grados.

En general, el principio básico es incorporar el direccionamiento indirecto en su configuración: no especifique la configuración, sino cómo encontrar la configuración en su código. Y, por lo general, invoca varias direcciones indirectas: específicas del usuario, específicas de la aplicación, específicas de la máquina, específicas del entorno. Cada uno debe encontrarse en un lugar / manera bien definidos, y debe haber una precedencia muy bien definida entre ellos (generalmente usuario sobre máquina sobre aplicación sobre entorno). En general, encontrará que cada configuración configurable tiene un hogar natural en una ubicación, pero no modifique la dependencia en sus aplicaciones.

Encuentro que es MUY valioso diseñar aplicaciones para poder reportar su configuración y verificarla. En la mayoría de los casos, un elemento de configuración faltante o no válido puede provocar el aborto de la aplicación. En la medida de lo posible, realice esa verificación (y anule) en el inicio = falla rápidamente. Los valores predeterminados de los códigos de hardware solo se pueden usar de manera confiable.

Resuma el acceso de configuración para que la mayoría de la aplicación no tenga idea de dónde viene ni cómo se procesa. Prefiero crear clases de Config que expongan las configuraciones configurables como propiedades individuales (se escriben con fuerza cuando son relevantes), luego inyecto " ellos en clases de aplicación a través de IOC. No haga que todas sus clases de aplicaciones invocen directamente el marco de configuración en bruto de su plataforma elegida; La abstracción es tu amiga.

En la mayoría de las organizaciones de clase empresarial (Fortune 500), nadie ve las configuraciones del entorno de producción (ni siquiera las de prueba), excepto el equipo de administración de ese entorno. Los archivos de configuración nunca se implementan en una versión, son editados a mano por el equipo de administración. Los archivos de configuración relevantes nunca se verifican en el control de código fuente junto con el código. El equipo de administración puede usar el control de código fuente, pero es su propio repositorio privado. Sarbanes-Oxley y otras regulaciones similares también tienden a prohibir estrictamente que los desarrolladores tengan acceso general a los sistemas de producción (casi) o cualquier información de configuración confidencial. Sea consciente al diseñar su enfoque.

Disfruta.

Answer 2

Siempre debe separar la historización (para qué es un control de fuente) de la implementación.

Una implementación implica:

• un conjunto de datos identificado (para el cual es útil una etiqueta o etiqueta proporcionada por el SCM)
• un proceso que manipula esos datos (para al menos copiarlos en el lugar correcto, pero también expandir algunos archivos comprimidos, etc.)

Entre las diversas operaciones que realiza una implementación, debe incluir una fase de-variabilization .

Una variable es una palabra clave que representa cualquier cosa que pueda cambiar dependiendo de su plataforma de implementación (que puede ser una PC para una integración continua, un linux para la homologación básica, un viejo Solaris8 para la homologación de preproducción y un Full F15K Solaris10 con zonas para la producción: corta puede variar mucho). Vea la respuesta de Jonathan Leffler para ejemplos prácticos.

Una variable puede representar una ruta, una versión de JVM, algunas configuraciones de JVM, etc., y lo que está poniendo en un SCM debería ser un dato con variables, nunca configuraciones codificadas.

El siguiente paso sería incluir en su ejecutable una forma de detectar cualquier cambio en los archivos de configuración para actualizar mientras se ejecutan algunos parámetros (evitando la secuencia de todos " apagado / cambio / reinicio ").
Eso significa que son dos tipos de variables de implementación :

• estáticas (que nunca cambiarán),
• dinámica (lo que debería tenerse en cuenta durante la sesión de ejecución)

Answer 3

Evita las rutas absolutas siempre que sea posible.

No confíe en su control de versión actual para hacer algo mágico; puede cambiar los sistemas de control de versión en el futuro.

El enfoque más simple funciona para mí: tener un 'config.live' y el 'config' está configurado para el desarrollo. Durante la implementación, simplemente mueva config.live a config y todo está bien. Para configuraciones más complejas, se puede requerir un subdirectorio para cada configuración.

Un conjunto de procedimientos de implementación es esencial, ya que la configuración es solo un área que será diferente.

Es muy probable que cualquier cosa más compleja cause más problemas de los que resuelve.

Answer 4

Use un SCM como Git para el control de versiones y una herramienta de implementación como Capistrano para despliegue . Aunque Capistrano se creó inicialmente para Ruby on Rails, está perfectamente bien utilizarlo para otros marcos e idiomas.

Lo principal es que una herramienta de implementación específica te dará toda la flexibilidad para automatizar cosas como las rutas en ambos extremos.

Answer 5

Me gusta la forma en que Ruby on Rails resuelve este tipo de problema: los archivos de configuración específicos del entorno. Rails admite conexiones de base de datos de desarrollo, prueba y producción, controladas por la configuración en el archivo database.yml. Aquí hay una publicación del blog sobre la creación de otras opciones de configuración específicas del entorno, es para Rails, pero puede darle algunas ideas sobre cómo hacer algo similar para su entorno. http://usablewebapps.com/2008/09/09 / yaml-and-custom-config-for-rails-projects /

Answer 6

Parece que su código de producción es un repositorio completo en git y para actualizar la producción, ¿hace un git pull ? Es posible que desee probar un proceso de compilación independiente que saque el código del repositorio y cree una compilación limpia (sin carpeta .git). Podría tener archivos de configuración específicos del entorno que contengan sus rutas que se copien o creen junto con ellos.