Versionamiento de servicios

1. ¿Qué es una versión de un servicio?

Una versión es una copia controlada de un servicio existente que permite realizar modificaciones sin afectar el servicio vigente que consultan otras plataformas y sistemas del Estado.

El versionamiento existe para:

• Permitir actualizaciones seguras de servicios ya registrados.

• Evitar cambios directos sobre información que ya está siendo utilizada por ciudadanos y sistemas externos.

• Garantizar que toda modificación pase por un proceso de validación antes de convertirse en información oficial.

La versión no reemplaza automáticamente al servicio principal. Solo se convierte en oficial cuando es promovida y aprobada según las reglas establecidas.

2. Servicio principal vs versiones

En el Catálogo existen dos niveles de información:

Servicio principal

• Es la versión oficial y vigente del servicio.

• Es la que consumen:

  • El portal ciudadano.

  • Otras plataformas del Estado.

  • Sistemas que consultan el Catálogo mediante integraciones.

• Su estado es determinante para definir quién puede modificarlo.

Versiones del servicio

• Son copias del servicio principal creadas para:

  • Proponer cambios.

  • Actualizar información.

  • Corregir contenidos.

• Los cambios realizados en una versión no afectan al servicio principal hasta que la versión sea promovida.

3. Estados del servicio y su impacto en el versionamiento

El comportamiento del versionamiento depende del estado del servicio principal, no del estado asignado dentro de la versión.

Estados editables por gestores

Los gestores solo pueden editar directamente un servicio cuando el servicio principal está en alguno de los siguientes estados:

• Borrador

• Corrección

En estos casos:

• El gestor puede editar el servicio principal.

• El gestor puede crear versiones.

• El gestor puede promover una versión a principal, ya que tiene permisos de edición sobre el servicio.

Estados no editables por gestores

Cuando el servicio principal se encuentra en estados como:

• En revisión

• Publicado

Ocurre lo siguiente:

• El servicio principal no puede ser editado por gestores.

• El gestor sí puede crear y editar versiones del servicio.

• El gestor NO puede promover una versión a principal, aunque la versión esté completa o tenga cambios válidos.

Esto es intencional y responde a la necesidad de proteger la información oficial del Catálogo.

4. ¿Por qué un gestor no puede promover una versión si el servicio está publicado?

Promover una versión implica actualizar el servicio principal.

Cuando un servicio está en estado En revisión o Publicado:

• El Catálogo asume que esa información:

  • Ya fue validada.

  • Está siendo utilizada por sistemas externos.

  • No debe cambiar sin una validación institucional.

Por esta razón:

• Solo los perfiles autorizados para editar servicios en estos estados (por ejemplo, analistas) pueden promover versiones.

• El gestor queda limitado a proponer cambios, no a publicarlos directamente.

Esto garantiza:

• Trazabilidad.

• Control institucional.

• Consistencia de la información pública.

5. Flujo correcto de trabajo para gestores usando versiones

Cuando un gestor necesita actualizar un servicio que ya está en revisión o publicado, el proceso correcto es:

1. Crear una nueva versión del servicio.

2. Realizar los cambios necesarios dentro de esa versión.

3. Marcar la versión como lista para revisión (según el flujo definido).

4. Notificar al equipo responsable de validación para que:

   • Revise los cambios.

   • Decida si la versión puede ser promovida.

Hasta que esto ocurra:

• El servicio principal permanece intacto.

• Los ciudadanos y sistemas externos continúan consultando la información vigente.

6. Flujo de trabajo para analistas

Los analistas tienen la responsabilidad de:

• Revisar las versiones creadas por los gestores.

• Validar que los cambios cumplan con:

  • Lineamientos del Catálogo.

  • Normativas vigentes.

  • Estándares de calidad de la información.

• Promover la versión a principal cuando corresponda.

Una vez promovida:

• La versión pasa a ser el nuevo servicio oficial.

• La versión anterior queda registrada como parte del historial.

7. Consideraciones importantes

• Cambiar el estado dentro de una versión no modifica los permisos sobre el servicio principal.

• El versionamiento no sustituye el flujo de validación institucional.

• Un servicio publicado no debe volver a borrador salvo decisiones excepcionales.

• El historial de versiones permite:

  • Auditoría.

  • Seguimiento de cambios.

  • Transparencia institucional.