tag manager deployment configuration environment configuration-management

deployment - manager - Gestionar archivos de configuración en diferentes entornos.



https tag manager (7)

¿Cómo gestiona usted (su empresa) los archivos de configuración de las aplicaciones / sistemas que construye? Déjame decirte cómo lo hacemos, y cuál es el problema.

Estoy trabajando en una empresa donde desarrollamos software con unos 15 desarrolladores. Construimos aplicaciones web de línea de negocios que se implementan en nuestro proveedor de hospedaje administrado. Una de nuestras aplicaciones principales consiste en un sitio web y unos diez servicios de WCF. Algunos de los servicios están conectados entre sí.

No sé si se trata de un sistema grande o pequeño, pero mi opinión es que nos lleva demasiado tiempo poner las cosas en funcionamiento en nuestros diferentes entornos (prueba, aceptación y producción).

Tenemos archivos de configuración por entorno en nuestros proyectos de Visual Studio. Así que un web.test.config , un web.acc.config , un web.prod.config y un web.config para el desarrollo. Todos tienen las mismas claves en ellos, pero los valores pueden ser diferentes, dependiendo del entorno para el que están destinados.

Si hago un recuento rápido de los ajustes en la configuración web para la aplicación, cuento con 32. Y cuento con 5 puntos finales. Tenemos cuatro entornos (dev, test, acc y prod), esto significa 128 ajustes y 20 puntos finales en total para una aplicación web. Podemos cometer errores fácilmente, especialmente cuando se acercan los plazos.

Todos somos humanos, por lo que cosas como estas pueden pasarle a cualquiera:

  • Hacemos un cambio en uno de los archivos de configuración, pero olvídese de registrarse antes de construir y desplegar.
  • O hacemos un cambio en el servidor web y nos olvidamos de actualizar en consecuencia en otros cuatro web.configs.
  • O cambiamos solo tres de los cuatro archivos de configuración. Y así.

Luego tenemos la infraestructura en nuestro proveedor de alojamiento gestionado. Por defecto todos los puertos están cerrados. Entonces, si uno de los servicios de WCF necesita hablar con otro de los servicios de WCF ubicados en un servidor diferente, un puerto protegido por firewall debe estar abierto.

Hacemos esto en Prueba, pero en Aceptación tenemos que hacerlo de nuevo, y hemos olvidado qué puertos deben abrirse, así que es más como prueba y error: Oh, mi servicio no puede conectarse a la base de datos, probablemente la el puerto está cerrado. El mismo problema puede ocurrir en la producción también.

Nuestro proveedor de alojamiento gestionado puede tardar unos días en abrir un puerto en un servidor de seguridad, de acuerdo con el SLA. Entonces, esto se convierte rápidamente en un proceso bastante largo. Y al final, nos lleva aproximadamente dos meses tener la prueba, la aceptación y la producción en funcionamiento.

Entonces, mi pregunta es: ¿cómo administra las configuraciones, la infraestructura y el proceso a su alrededor?

¿Ha considerado usar una herramienta de administración de implementación para manejarlo? Trabajé en el equipo de operaciones para implementar un producto que tiene aproximadamente 10 sistemas diferentes que necesitan comunicarse entre sí, por lo que realmente entiendo su situación. La implementación de toda la solución tomó aproximadamente 4 horas de pasos manuales + 2 horas de prueba. Decidimos usar Octopus Deploy ( https://octopus.com ) para automatizar el proceso de implementación. Esta herramienta puede realizar la sustitución de variables en los archivos de configuración y puede definir variables por entorno (y mucho más ...) La implementación de toda la solución ahora se activa unos 15 minutos y el resultado final siempre es bueno ... También puede activar la versión la creación y el despliegue directamente desde TFS, VSTS, Jenkins o TeamCity, para que pueda tener un enfoque de CI / CD muy sólido.

Espero que esto ayude.

Echa un vistazo a Config en http://www.configapp.com . La forma en que funcionará es que importará un archivo de configuración base llamado web.config. Luego, desde la aplicación web, crearás 4 entornos, dev, test, acc y prod. Vaya al entorno dev, cree sus variables de entorno y establezca los valores adecuados para el entorno. Mantendrá solo un archivo de configuración con variables de entorno. Puede ver todas las variables de entorno y ver fácilmente las diferencias entre los entornos.

Cometerá menos errores porque solo tiene 1 archivo de configuración para administrar. Cuando agrega una nueva configuración común / estática, todos los entornos tendrán mágicamente esa nueva configuración. Cuando agregue una configuración variable, simplemente vaya a la pestaña del entorno correcto y establezca el valor allí. Puede ver un valor de configuración específico para todos los entornos, por lo que es una forma rápida de verificar si se perdió algo. También puede visualizar cada archivo de configuración por entorno, ya que están justo delante de usted. No necesita RDP / SSH para cada servidor.

No olvidará registrarse ya que Config será la copia maestra y ya no editará los archivos de configuración directamente. Si los edita directamente, tenemos una funcionalidad diff para que pueda ver las diferencias entre el maestro y la copia local. Puede implementar la copia maestra en su servidor local utilizando varios modelos de implementación que se adapten a su equipo. Puede empujar, extracción manual, extracción automática o exportar / copiar.

Admitiremos tipos personalizados, y una cosa que podemos agregar en el futuro es un tipo de datos de puerto. Parte de la validación del puerto sería verificar si el puerto está abierto. Esto solo funcionará usando el plan local, ya que necesita acceso a la red interna. O simplemente puede comprobarlo manualmente. Vaya a la variable de entorno del puerto y visualice todos los puertos configurados actualmente. Compruebe cada puerto en la lista. Si el puerto se ve bien, agregue un comentario en Config que está abierto y se verificó en una fecha determinada. Config está diseñado para la búsqueda y documentación.

Soy parte del equipo de Config, por cierto.

El proyecto Config4 * (descargo de responsabilidad: soy su desarrollador principal) no tiene una integración inmediata con .Net o WCF, por lo que probablemente no sea útil para usted. Sin embargo, una de las características de Config4 * es relevante para su pregunta: es la capacidad de incrustar sentencias if-then-else en un archivo de configuración, de modo que el archivo pueda "adaptarse" a diferentes entornos (como desarrollo, pruebas). , aceptación y producción).

Es posible que pueda modificar ese concepto para trabajar con cualquier sintaxis de configuración que esté usando en su proyecto basado en .Net / WCF (no estoy familiarizado con esas tecnologías, pero supongo que probablemente utilicen archivos de configuración basados ​​en XML) . En particular, podría escribir una secuencia de comandos utilizando, por ejemplo, Python, que usa las sentencias if-then-else para establecer pares nombre = valor específicos del entorno en un map , y luego usar algunas sentencias de print para generar un conjunto de archivos de configuración adaptados para un ambiente. Un esquema de pseudocódigo de tal script es:

#-------- # Set up configuration variables suitable for a specified environment #-------- cfg["variable1"] = "default value"; cfg["variable2"] = "another default value"; if (environment == "testing") { cfg["variable1"] = "override default value for this environment"; cfg["variable3"] = "value suitable for this environment"; ... } else if (environment == "production") { ... } #-------- # Now use print statements to generate configuration files # Alternatively, use the _name=value_ pairs in the map to # perform global search-and-replace on template versions of # configuration files. #-------- ...

Para los puntos de bonificación, la secuencia de comandos también podría generar una lista de verificación de las pruebas que deben realizarse para el entorno, por ejemplo, "Compruebe si es necesario abrir un puerto de firewall entre los siguientes puntos finales: ..."

Estamos desarrollando un sistema de almacenamiento distribuido y detectamos muchos problemas como este con nuestras pruebas de unidad e integración que se ejecutan con cada compilación. Además, estamos utilizando ReviewBoard, para que otros desarrolladores vean los cambios antes de comprometerse. El siguiente paso es el servidor de integración continua (jenkins) que se implementa automáticamente y prueba los artefactos en diferentes entornos. Finalmente, nuestra última línea de defensa es nuestro banco de pruebas de prueba de estrés que se ejecuta contra cualquier versión nueva, antes de que se publique. Por supuesto, es esencial tener un banco de pruebas que imite sus entornos de producción lo mejor posible, pero si siempre se implementa en el mismo proveedor de alojamiento, eso no debería ser demasiado difícil.

  • Con respecto a su caso especial, donde los cambios en un archivo podrían haber sido olvidados en los demás, etc .: Me imagino que esto sería bastante fácil de verificar automáticamente con un script de prueba.

  • Los cambios no comprometidos deben ser tan fáciles de detectar como "git diff master", o lo que sea que use.

  • Saber qué puertos deben estar abiertos para los servicios parece ser más una cuestión de documentación adecuada que de administración de configuración.

Muchos de los sitios que utilizan nuestro sistema también utilizan puppet para administrar la configuración de sus diferentes nodos. No estoy seguro de que esa sea una opción para usted, pero vale la pena echarle un vistazo.

Parece que tiene un entorno lo suficientemente pequeño como para poder administrar fácilmente todos los archivos de configuración utilizando plantillas de Ansible o SaltStack .

Personalmente, si es posible, lo administro de la siguiente manera: Todas las configuraciones de entorno "estáticas" (conexiones de base de datos, LDAP, etc.) se colocan en el archivo de configuración del servidor (no está afectado por las migraciones de código), y las configuraciones "dinámicas" en la base de datos en sí.

Así que solo dependo del equipo de base de datos para actualizar la configuración (si tiene acceso directo a la base de datos, es más fácil). Y no tengo ningún riesgo de ejecutar en mi PC dev un código que apunta a la base de datos prod: D

PERO no tengo experiencia en Visual Studio, así que no estoy seguro de que pueda aplicar algo similar en su caso, pero espero que le pueda dar algunas ideas.