Directrices sobre el movimiento de datos de configuración

Las directrices y reglas básicas a seguir para el movimiento de datos de configuración mientras se trabaja con varios entornos de kit de herramientas de desarrollador y nube.

• El entorno de nube Master-Config actúa como el origen de configuración de la verdad para todos los entornos. La configuración se crea aquí y se debe mover utilizando la Herramienta de despliegue de configuración (CDT) sólo desde aquí a otros entornos de nube, y no viceversa.
• Después de actualizar la aplicación, no importe la CDT en el entorno de creación (MC) de la versión anterior.
• Si es necesario realizar una configuración ad hoc en el entorno de producción, primero debe realizarse en el entorno de configuración maestra, verificarse en el entorno de preproducción y, a continuación, activarse en el entorno de producción. Estas configuraciones se deben conciliar manualmente en entornos de nube inferiores.
• Los entornos de kit de herramientas de desarrollador son entornos locales extraídos de entornos de nube que un SI puede configurar. Se extraen principalmente del entorno de nube de integración (pero no se restringen a él).
  • No crean configuraciones. Para ellos, su entorno de nube padre debe ser el entorno de creación para las configuraciones.
  • Los datos de configuración nunca se deben mover de los entornos de kit de herramientas de desarrollador a la nube (solo la excepción es para los clientes que utilizan BOPIS Deployment Accelerator por primera vez cuando cargan BOPIS Deployment Accelerator en la nube).
• Si un cliente tiene necesidades de desarrollo/pruebas mejoradas (desarrollo paralelo simultáneo en varias versiones, proyectos POC diferentes, etc.) que no están siendo satisfechas por un único conjunto de entornos de nube de Integración/QA, puede elegir comprar entornos de recinto de pruebas de nube adicionales.
  • Siempre que se realizan configuraciones delta en dichos entornos, deben fusionarse manualmente en el entorno Master-Config.
• Un implementador (SI) no debe modificar las configuraciones proporcionadas por la aplicación como Criterios de agente, flujos y condiciones.
  • Los criterios de agente proporcionados por la aplicación son una configuración de ejemplo, pertenece al producto y puede cambiar entre releases. La configuración de ejemplo es una forma de exponer los nuevos parámetros añadidos para el agente.
  • Los Servicios proporcionados por la aplicación se publican y su comportamiento está documentado. Un SI no debería modificar estos servicios. Además, su comportamiento puede mejorarse con respecto a las versiones y la documentación se actualizaría en consecuencia.
  • Las Condiciones proporcionadas por la aplicación también se publican y su comportamiento está documentado. Su comportamiento puede mejorarse con respecto a las versiones. Además, se puede utilizar una condición proporcionada por la aplicación en algunos servicios y manejadores de sucesos proporcionados por la aplicación. Por lo tanto, la modificación de una condición podría fallar en dichos servicios y manejadores de sucesos.

  En su lugar, un SI debe crear un componente nuevo examinando la configuración proporcionada por la aplicación. El Gestor de aplicaciones también proporciona una opción 'Guardar como'. Al utilizar esta opción, el SI puede duplicar fácilmente un componente y utilizarlo en la configuración necesaria.