Esta pregunta toma como ejemplo un servicio Spring Boot, pero podría ser cualquier tecnología.
Asumiendo lo siguiente:
- Los entornos (dev / QA / prod) son propiedad de diferentes equipos. Esto significa que dev no debe tener acceso a la configuración de productos.
- La configuración (digamos application.properties) está externalizada, es decir, no es parte del binario
- El mismo binario / paquete (digamos service.jar) se implementa en cada entorno y se controla mediante una implementación automatizada.
Si bien los cambios en el artefacto binario (service.jar) se propagan automáticamente a cada entorno, los cambios en la configuración aún necesitan intervención manual, lo que inevitablemente termina desincronizándose en cada entorno.
Por ejemplo, supongamos que el equipo de desarrollo agrega algunos pares clave-valor a application.properties en su entorno. ¿Cuál sería la mejor manera de registrar estas nuevas claves, de modo que cuando la implementación se produzca en el equipo de operaciones sepan exactamente qué claves agregar, de modo que se minimice el riesgo de iniciar el nuevo servicio y ver que falla debido a la falta de una clave?
Sé que habrá pasos manuales involucrados, pero me gustaría saber cómo las personas lidian con esto y encontrar la forma más efectiva.
fuente
Respuestas:
Esto es principalmente un problema de comunicación, pero puede hacer que los errores sean menos probables con algunas medidas técnicas y organizativas simples. Primero, debe proporcionar una buena documentación de alta calidad de todas las entradas en sus archivos de configuración, así como algunos ejemplos de fácil acceso o archivos de configuración "predeterminados". El archivo de ejemplo se puede implementar automáticamente en cada entorno, ya que el equipo de producción no debe modificarlo directamente.
A continuación, con cada nueva versión, proporcione un registro de cambios, donde se documenten los cambios importantes. Los cambios en la configuración que podrían evitar que el sistema funcione cuando faltan son siempre importantes, así que asegúrese de que la información esté allí.
La mejor manera de reducir el riesgo de fallar es evitar cambiar su aplicación de una manera que requiera las nuevas claves, por lo que la aplicación debe ser compatible con versiones anteriores de los archivos de configuración siempre que sea posible. A menudo, su aplicación puede comportarse de manera sensata al proporcionar valores predeterminados incorporados para las nuevas claves para el caso de que falten.
Sin embargo, si eso no es posible, su sistema debe hacer que sea lo más fácil posible para el equipo de producción descubrir por qué el nuevo servicio no se inicia cuando falta la clave. Debe haber un mensaje de error claro, que indique exactamente qué clave falta en qué archivo y, si es necesario, dónde encontrar la información sobre la clave que falta, o una pista o ejemplo sobre una entrada significativa para esta clave.
Si la configuración es compleja y el formato cambia de una manera que la edición manual se vuelve propensa a errores, también puede considerar proporcionar herramientas para editar las configuraciones y para migrar a una versión más nueva.
Por ejemplo, estoy usando el navegador web Firefox, y con cada nueva versión (que obtengo automáticamente), se agregan ciertas cosas a la configuración local que se puede inspeccionar en la página "about: config". Esto es comparable a la configuración en su entorno de "producción". Dado que toda la configuración se mantiene estrictamente compatible con versiones anteriores, nunca tengo que agregar nuevas claves a la configuración manualmente solo porque hay una nueva versión del navegador. Y para el caso que quiero cambiar algo allí (tal vez una nueva entrada que no era parte de la versión anterior), utilizo el menú Herramientas / Opciones, o la página "acerca de: config", y puedo encontrar la entrada más algunas tipo de documentación Por lo tanto, recomiendo intentar implementar su sistema de manera comparable.
fuente
En un lugar donde trabajé una vez, tuvieron un problema similar. La configuración de producción fue controlada por el equipo de compilación, solo ellos tenían acceso a ella en el repositorio de código. Las configuraciones dev, qa, test, etc ... pueden ser vistas por todos.
En su ejemplo, un desarrollador actualizaría el archivo localmente, lo registraría en el control de origen y luego alguien solicitaría al equipo de compilación que haga una nueva compilación "solo configuración" que verificó los archivos de configuración y los implementó, pero no volvió a compilar o volver a implementar toda la aplicación.
Depende de los miembros del equipo actualizar los archivos de configuración para otros entornos en el momento adecuado. Cuando llegó el momento de actualizar para la producción, el equipo de compilación tuvo que actualizar el archivo, a través de una solicitud explícita del líder del equipo de desarrollo, aunque generalmente la solicitud simplemente parecía "copiar el archivo app.config de QA1 a PROD". Las cosas sensibles, como las contraseñas, se encontraban en un archivo de configuración separado y, de nuevo, solo el equipo de compilación podía acceder al archivo de contraseña de producción. La diferencia era que los desarrolladores generalmente nosolicitar cambios en los archivos de contraseña porque no habrían tenido contraseñas de producción. La única vez que le pedirían al equipo de compilación que lo actualizara era al agregar una nueva contraseña para un nuevo servicio. E incluso entonces, los desarrolladores probablemente no conocerían la contraseña de Producción, solo sabrían la clave para agregar al archivo (como "newService2.password").
La tecnología utilizada para administrar mucho de esto fue Jenkins. También había una herramienta interna que se usaba para solicitar y programar compilaciones a través de Jenkins.
fuente