git - tipos - ¿qué es un sistema control de versiones local?

¿Cuál es la mejor práctica para manejar información específica del sistema bajo control de versión? (6)

Evite caminos absolutos 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 versiones en el futuro.

El enfoque más simple funciona para mí: tener un ''config.live'' y ''config'' configurado para el desarrollo. Durante la implementación simplemente mueva config.live a config y todo estará bien. Para configuraciones más complejas, puede ser necesario 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.

Cualquier cosa más compleja seguramente causará más problemas de los que resuelve.

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

Estoy desarrollando una aplicación web en un servidor de desarrollo. He definido el nombre de la ruta absoluta para 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:

Vuelva a configurar el servidor de desarrollo para compartir la misma ruta que la producción
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 futuros cambios. No me gusta el número 2 porque si empiezo a desarrollar en un segundo servidor de desarrollo con una tercera ruta, tendría que cambiar esto para cada confirmación y actualización.

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

Uso de palabras clave personalizadas y expansión de variables (como establecer la propiedad $ PATH $ en las propiedades de control de versiones y expandirla en todos los archivos). Git no lo admite porque sería un gran golpe de rendimiento.
Usar ganchos post-actualización y pre-commit. Posiblemente la solución más probable para git, pero cada vez que miraba el estado, informaba que los dos archivos estaban siendo cambiados. No realmente limpio.
Tirando de la ruta de un archivo de configuración fuera del control de la versión. Entonces tendría que tener el archivo de configuración en la misma ubicación en todos los servidores. Bien podría tener el mismo camino para comenzar.

¿Hay alguna manera fácil de lidiar con esto? ¿Estoy más pensando?

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

No siempre codifique los datos de configuración como las rutas del sistema de archivos y fuerce las implementaciones múltiples para que coincidan. Ese es el lado oscuro, donde hay mucho SUFRIMIENTO.

Me resulta útil y fácil construir mis sistemas para admitir múltiples configuraciones fácilmente, y rutinariamente transfiero los archivos de configuración al control de fuente uno al lado del otro, pero la producción está ofuscada (no hay contraseñas reales) y el desarrollo está modelado (por lo tanto, un pago puede hacerlo '' sobrescribir la configuración de un desarrollador). El código siempre se empaqueta de forma neutral en cuanto a configuración: el mismo binario se puede implementar en cualquier lugar.

Desafortunadamente, la mayoría de las plataformas de lenguaje / desarrollo no admiten esto 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 la indirección en su configuración: especifique no la configuración, sino cómo encontrar la configuración en su código. Y generalmente invocan varios indirectos: específicos del usuario, específicos de la aplicación, específicos de la máquina, específicos del entorno. Cada uno debe encontrarse en un lugar / manera bien definida, y debe haber una precedencia muy bien definida entre ellos (generalmente el usuario sobre la máquina sobre la aplicación sobre el entorno). Generalmente encontrará que cada configuración configurable tiene un hogar natural en una ubicación, pero no codifica esa dependencia en sus aplicaciones.

Considero que es MUY valioso diseñar aplicaciones para poder informar su configuración y verificarla. En la mayoría de los casos, un elemento de configuración faltante o no válido debe dar como resultado el aborto de la aplicación. Tanto como sea posible, realice esa verificación (y aborte) al inicio = falla rápidamente. Los valores predeterminados de código duro solo se pueden usar de manera confiable.

Resuma el acceso a la configuración para que la mayoría de la aplicación no tenga ni idea de dónde proviene ni cómo se procesa. Prefiero crear clases de Config que expongan configuraciones configurables como propiedades individuales (fuertemente tipadas cuando sea relevante), luego las "inyecto" en clases de aplicación a través de IOC. No haga que todas sus clases de aplicación invoquen directamente el marco de configuración sin formato 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 de entorno de producción (o incluso prueba), excepto el equipo de administración para ese entorno. Los archivos de configuración nunca se implementan en una versión, sino que son editados a mano por el equipo de administración. Los archivos de configuración relevantes ciertamente nunca se controlan en el control de fuente lado a lado con el código. El equipo de administración puede usar el control de fuente, pero es su propio repositorio privado. Sarbanes-Oxley y regulaciones similares también tienden a prohibir estrictamente a los desarrolladores tener acceso general a sistemas de producción (cercanos) o cualquier información de configuración sensible. Tenga cuidado al diseñar su enfoque.

Disfrutar.

Parece que tu código de producción es un repositorio completo de git y para actualizar la producción, ¿lo haces? Es posible que desee probar un proceso de compilación separado que verifique el código de su repositorio y cree una compilación limpia (sin la carpeta .git). Podría tener archivos de configuración específicos del entorno que contengan las rutas que se copian o crean junto con él.

Use un SCM como Git para control de versiones y una herramienta de implementación como Capistrano para implementación . Aunque Capistrano fue creado inicialmente para Ruby on Rails, está perfectamente bien usarlo para otros marcos e idiomas.

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

Siempre debe separar la historización (para qué sirve el control de origen) de la implementación.

Una implementación implica:

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

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

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 integración continua, un linux para la homologación básica, un antiguo Solaris8 para homologación de preproducción y un FISK completo Solaris10 con zonas para producción: es corto, puede variar mucho). Ver 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 "apagar / cambiar configuraciones / reiniciar todo").
Eso significa que son dos tipos de variables de implementación :

estáticos (que nunca cambiarán),
dinámicos (que deberían tenerse en cuenta idealmente durante la sesión de tiempo de ejecución)