MyZapp

Dirigir un proyecto de puesta en servicio

Available in en es fr

Updated on 10/26/2026

Esta página está dirigida al integrador que pone en servicio MyZapp en casa de un cliente. Encadena las etapas de un proyecto, desde el planteamiento hasta el paso a producción, y remite para cada una a la página que la detalla.

Plantear el proyecto

  • Tres instancias: una de desarrollo, donde se construye la configuración, una de pruebas, donde el cliente la valida, y la producción. La configuración pasa de una a la siguiente mediante un GOLIVE, siempre iniciado por la instancia que recibe: pruebas lee desarrollo, producción lee pruebas (ver «Preparar la instancia de origen de un GOLIVE»).
  • Licencias: cada instancia tiene su propia identidad y sus propias licencias. Un módulo sin licencia en una instancia no recibe nada en ella (ver «Gestionar las licencias de la instancia»).
  • Seguimiento del proyecto: el módulo Proyectos puede llevar el propio proyecto, con sus tareas, hitos y equipo (ver «Dirigir un proyecto» y «Seguir un proyecto»).

Lo que pasa por el GOLIVE y lo que no

Antes de planificar, clasifica cada necesidad en una de estas cuatro familias:

  • la configuración (procesos, formularios, catálogo, referencial de tickets, plantillas, menús, bases de conocimientos, tipos de objeto de la CMDB, reglas del CRM…): se construye en desarrollo y se promueve por GOLIVE, por selección;
  • lo que es propio de cada instancia (direcciones, conexiones, secretos, licencias, agentes): nunca viaja, y se configura en cada instancia;
  • los datos de negocio (tickets, solicitudes, cuentas y oportunidades del CRM, activos…): no pasan por el GOLIVE, sino por la migración de datos;
  • las trazas de ejecución (registros, historiales): se quedan donde se produjeron.

Tampoco viajan las cuentas, los grupos y sus miembros, ni los permisos: un elemento promovido solo designa el grupo o la cuenta que espera, y el destino lo encuentra en su propia instancia.

Construir en desarrollo

  1. Crea los grupos y configura los permisos en cada instancia, con los mismos códigos: no se promueven. Los menús, en cambio, sí.
  2. Construye la configuración: service desk, catálogo, formularios, procesos, contenidos.
  3. Carga si hace falta los datos de demostración para probar la configuración con casos realistas (ver «Cargar los datos de demostración»). No los cargues en producción.

Preparar la migración de datos

Los datos de la herramienta anterior se migran con las importaciones de los módulos, por ejemplo:

  • los tickets: importación de un archivo JSON, en la que cada ticket se convierte en un ticket nuevo (ver «Importar y exportar tickets»);
  • las cuentas y contactos del CRM: importación CSV o Excel con detección de duplicados (ver «Duplicados, fusión, importación y exportación»).

Las cuentas de usuario deben existir antes que los datos que las citan: un ticket cuyo solicitante no se encuentra se ignora. Créalas primero, a mano o mediante la sincronización de un directorio (Active Directory, Microsoft 365 o Google Workspace).

Repite la migración en pruebas, con datos reales, hasta obtener un informe sin rechazos.

Hacer las pruebas

  1. En la instancia de pruebas, declara desarrollo como origen (ver «Declarar el origen de un GOLIVE»).
  2. Elige los elementos, previsualiza, resuelve las diferencias bloqueantes y aplica (ver «Elegir y previsualizar un GOLIVE» y «Aplicar un GOLIVE y consultar el historial»).
  3. Tras comprobarlos, reactiva los disparadores de la lista Para reactivar: llegan desactivados.
  4. Haz que el cliente valide la configuración y la migración de datos. Una corrección se hace en desarrollo y vuelve a pasar por un nuevo GOLIVE: no corrijas directamente en pruebas lo que debe ir a producción.

Un GOLIVE correcto se deshace desde su historial, total o parcialmente, si las pruebas revelan un problema.

Pasar a producción

  1. En producción, declara la instancia de pruebas como origen y aplica el GOLIVE validado.
  2. Configura lo que es propio de la producción: conexiones, buzones, secretos, licencias.
  3. Importa la documentación entregada con la versión (ver «Actualizar la documentación»).
  4. Haz la migración de datos definitiva y reactiva los disparadores de la lista Para reactivar.
  5. Comprueba la instancia (ver «Supervisar la instancia») y conserva el historial de los GOLIVE como constancia del paso a producción.

Después de la puesta en servicio

Las evoluciones siguen el mismo camino: desarrollo, GOLIVE hacia pruebas, validación, GOLIVE hacia producción. La opción Modificado desde de la página GOLIVE solo muestra lo que cambió en el origen desde una fecha.

Para formar a los usuarios del cliente, la Academia ofrece itinerarios (ver «Diseñar un itinerario de la Academia»).

Applies from version 1.0 Verified for version 1.0

Was this article helpful?

Still need help? Create a request