Visual Paradigm Pipeline: Una guía completa

El Visual Paradigm Pipeline es la capa de conexión centralizada entre las herramientas de diagramación y modelado de Visual Paradigm y Visual Paradigm OpenDocs. Permite a los equipos crear activos visuales, almacenarlos como artefactos gestionados en la nube, rastrear sus revisiones e incrustarlos en documentación viva sin tener que exportar, subir y reemplazar repetidamente archivos de imagen.

El flujo de trabajo principal es:

Crear o generar → Comprometer en el Pipeline → Incrustar en OpenDocs → Revisar cambios → Actualizar documentación

El Pipeline está diseñado para mantener sincronizados los diagramas y la documentación a medida que evoluciona un proyecto. En lugar de tratar los diagramas como archivos estáticos PNG o JPG, mantiene una relación entre el visual publicado y su activo fuente.

1. Qué hace el Pipeline

El Pipeline realiza cuatro funciones principales:

1. Almacenamiento centralizado de activos
   Almacena diagramas y otros activos visuales en un repositorio compartido basado en la nube.

2. Tránsito entre herramientas
   Conecta Visual Paradigm Desktop, Visual Paradigm Online, el Chatbot de Diagramación con IA, VPasCode y OpenDocs.

3. Gestión de revisiones
   Registra cambios en los activos visuales y permite a los usuarios revisar revisiones más recientes o restaurar versiones anteriores.

4. Integración con documentación en vivo
   Permite que los activos visuales se incrusten en OpenDocs como elementos gestionados en lugar de archivos de imagen cargados manualmente.

Los activos enviados a través del Pipeline pueden incluir UML, BPMN, ERD, ArchiMate, diagramas de flujo, diagramas de arquitectura, diagramas de secuencia, libros de folios y estanterías de libros, dependiendo de la herramienta de origen y el flujo de trabajo de publicación.

2. El ecosistema del Pipeline

El Pipeline es más fácil de entender como un ecosistema de tres capas.

Capa de generación

Aquí es donde se crean los diagramas y modelos.

• Visual Paradigm Desktop: Se utiliza para modelado empresarial avanzado, diseño de bases de datos, arquitectura de software, UML, BPMN, ERD y otras tareas profesionales de modelado.

• Visual Paradigm Online: Se utiliza para diagramación colaborativa basada en el navegador y planificación visual.

• Chatbot de Diagramación con IA: Convierte descripciones en lenguaje natural en diagramas y modelos visuales estructurados.

• VPasCode: Crea diagramas mediante lenguajes de diagramación basados en texto como PlantUML, Mermaid, Markmap, Graphviz y ECharts.

El Chatbot de IA puede acelerar la creación inicial de diagramas, mientras que VPasCode ofrece una forma más controlada y orientada al código para refinar y mantener los diagramas.

Capa del Pipeline

La Pipeline es la capa de tránsito y gestión. Almacena los activos presentados, les asigna una referencia identificable, realiza un seguimiento de las revisiones y los pone a disposición de usuarios autorizados y herramientas conectadas.

Esta capa es particularmente valiosa porque mantiene la relación entre un diagrama publicado y su modelo de origen. Cuando el origen cambia, OpenDocs puede identificar que hay una revisión más reciente disponible.

Capa de documentación

Visual Paradigm OpenDocs es el destino para crear documentación de proyectos, manuales técnicos, especificaciones del sistema, wikis y bases de conocimiento.

Los activos gestionados por la Pipeline se pueden insertar en OpenDocs como elementos visuales en vivo o gestionados. Por lo tanto, la documentación puede cont tanto texto explicativo como modelos visuales vinculados que permanecen conectados a su origen.

3. ¿Por qué usar la Pipeline?

La documentación tradicional a menudo sigue este patrón:

1. Crear un diagrama.

2. Exportarlo como PNG, JPG, SVG o PDF.

3. Subirlo a una wiki o documento.

4. Insertar la imagen manualmente.

5. Modificar el diagrama original más tarde.

6. Exportarlo nuevamente.

7. Reemplazar la imagen antigua dondequiera que aparezca.

Esto genera varios problemas:

• Pueden existir múltiples copias del mismo diagrama.

• La documentación puede quedar obsoleta.

• Los equipos pueden no saber qué revisión es la autoritativa.

• Los archivos de origen y las imágenes exportadas pueden separarse.

• Los metadatos, las relaciones y la inteligencia del modelo pueden perderse.

• Actualizar diagramas en múltiples documentos consume tiempo administrativo.

La Pipeline reemplaza este proceso con una conexión gestionada entre el activo de origen y la documentación. El resultado es una fuente más confiablefuente única de verdadpara la información visual.

4. Conceptos fundamentales

Activo gestionado

Un activo gestionado es un artefacto visual almacenado a través de la Pipeline en lugar de subirse manualmente como una imagen ordinaria. Puede tener un nombre, origen, historial de revisiones y relación con uno o más documentos.

Los ejemplos incluyen:

• Diagramas de arquitectura del sistema

• Flujos de recorrido del usuario

• Modelos de bases de datos

• Diagramas de secuencia de API

• Modelos de procesos empresariales

• Hoja de ruta de productos

• Diagramas organizativos

• Libros digitales de pasar páginas

• Estanterías y colecciones de conocimientos

Revisión

Una revisión es una versión guardada de un activo. Puede crearse una nueva revisión cuando un usuario modifica un diagrama y confirma o publica la actualización.

El historial de revisiones ayuda a los equipos:

• Ver qué cambió

• Identificar quién realizó una actualización

• Revisar la secuencia de cambios

• Comparar los estados actuales y anteriores

• Restaurar una versión anterior cuando sea necesario

Documentación en vivo

La documentación en vivo contiene elementos visuales que permanecen conectados a activos fuente gestionados. Cuando un diagrama fuente cambia, el contenido correspondiente de OpenDocs puede indicar que hay una actualización disponible. Los autores pueden entonces decidir cuándo aplicar la revisión más reciente.

Fuente única de verdad

La Pipeline reduce la incertidumbre sobre qué diagrama debe utilizarse. En lugar de mantener copias independientes en archivos adjuntos de correo electrónico, unidades compartidas, presentaciones y wikis, los equipos pueden hacer referencia a un activo gestionado centralmente.

5. Flujo de trabajo estándar de Pipeline

Paso 1: Crear el activo visual

Comience con la herramienta más adecuada para la tarea.

Por ejemplo:

• Use Desktop para una arquitectura empresarial detallada.

• Use Online para el mapeo colaborativo de procesos.

• Use el chatbot de IA para generar un flujo de sistema inicial a partir de una descripción en lenguaje natural.

• Use VPasCode cuando desee una definición de diagrama basada en texto y similar al código.

Un prompt útil para la IA podría ser:

Cree un diagrama de secuencia para un proceso de pedido en línea que involucre a un cliente,
aplicación web, servicio de pago, servicio de inventario y base de datos de pedidos.
Muestre escenarios de pago exitoso, fallo de pago e inventario no disponible.

Si se usa VPasCode, el resultado puede refinarse mediante código de diagrama. Por ejemplo:

@startuml
título Flujo de pedido en línea

actor Cliente
participante "Aplicación web" como Web
participante "Servicio de pago" como Pago
participante "Servicio de inventario" como Inventario
database "Base de datos de pedidos" como DB

Cliente -> Web: Enviar pedido
Web -> Pago: Autorizar pago
Pago --> Web: Pago aprobado
Web -> Inventario: Reservar artículos
Inventario --> Web: Artículos reservados
Web -> DB: Crear pedido
DB --> Web: ID de pedido
Web --> Cliente: Mostrar confirmación

@enduml

VPasCode admite flujos de trabajo de diagramas como código, en los que las definiciones textuales pueden representarse como diagramas visuales y refinarse antes de su publicación.

Paso 2: Revisar y refinar el activo

Antes de comprometer un activo en la Pipeline, verifique:

• Título del diagrama

• Terminología y etiquetas

• Dirección de las relaciones

• Actores o sistemas faltantes

• Diseño y legibilidad

• Información sensible o restringida

• Si la representación visual coincide con el diseño actual del sistema

• Si la audiencia prevista puede comprenderlo

Los diagramas generados por IA deben revisarse cuidadosamente. La IA puede acelerar la creación de diagramas, pero los expertos del dominio deben validar la arquitectura, las relaciones, las suposiciones y la terminología.

Paso 3: Enviar o comprometer el activo en la Pipeline

Después de revisar el diagrama, envíelo a la Pipeline utilizando la acción de exportación, publicación, guardado o compromiso correspondiente en la aplicación de origen.

La Pipeline gestiona entonces el activo como un recurso en la nube reutilizable. Dependiendo del flujo de trabajo, puede almacenar el activo, asignarle una referencia identificable y registrar su revisión inicial.

En este punto, los equipos deben proporcionar metadatos útiles, como:

• Nombre claro del activo

• Nombre del proyecto o producto

• Tipo de activo

• Propietario

• Dominio empresarial o técnico

• Estado, como Borrador, Revisado o Aprobado

• Descripción

• Sistema o servicio relacionado

• Resumen de cambios

Un buen nombre es:

Plataforma de Pagos - Flujo de Autorización del Checkout

Un nombre débil es:

diagrama-final-v3-nuevo

Paso 4: Insertar el activo en OpenDocs

En OpenDocs:

1. Abra un documento existente o cree uno nuevo.

2. Navegue a la sección donde corresponde el elemento visual.

3. Utilice el comando de inserción de activos visuales o la opción de inserción de diagramas correspondiente.

4. Busque el activo gestionado por Pipeline.

5. Seleccione el activo y la revisión deseados.

6. Añada texto explicativo circundante.

Un diagrama rara vez debe aparecer sin contexto. Incluya:

• Propósito del diagrama

• Alcance

• Supuestos clave

• Actores o componentes importantes

• Explicación de flujos inusuales

• Fecha o estado de revisión

• Propietario o equipo responsable

Por ejemplo:

Este diagrama describe el flujo de autorización para pagos con tarjeta.
El servicio de pagos es responsable de la autorización, mientras que el servicio
de pedidos crea el pedido únicamente después de la aprobación del pago. Los pagos fallidos
se devuelven a la aplicación web sin crear un registro de pedido.

El activo se incrusta como un visual gestionado en lugar de como una captura de pantalla cargada de forma independiente.

Paso 5: Publicar o compartir la documentación

Una vez que el documento haya sido revisado, puede servir como:

• Una especificación de requisitos de software

• Una referencia de arquitectura

• Una guía de API

• Una wiki del proyecto

• Un recurso de incorporación

• Un manual de capacitación

• Una referencia de cumplimiento o auditoría

• Un manual de producto dirigido al cliente

El contenido de OpenDocs también puede distribuirse mediante formatos como libros giratorios o estanterías virtuales cuando los equipos necesitan un acceso estructurado y más amplio a colecciones de documentación.

Paso 6: Actualizar el activo de origen

Cuando el sistema cambie, actualice el diagrama en su herramienta de origen original.

Por ejemplo, si se agrega autenticación multifactorial a un flujo de inicio de sesión:

1. Abra el diagrama original en Desktop o VPasCode.

2. Agregue el servicio MFA y las interacciones relacionadas.

3. Revise el diseño actualizado.

4. Guarde o confirme la nueva revisión en la Pipeline.

5. Agregue una nota de cambio significativa.

Una nota de cambio útil podría ser:

Se agregó verificación OTP entre el servicio de autenticación y el servicio MFA.
Se actualizaron las rutas de error para códigos expirados y no válidos.

Paso 7: Revise la actualización en OpenDocs

Cuando esté disponible una revisión más reciente, el elemento visual vinculado en OpenDocs puede mostrar un indicador de actualización. El autor del documento puede entonces revisar el cambio y decidir si actualizar el elemento visual incrustado.

Este enfoque conserva el control editorial. La documentación no necesariamente tiene que cambiar inmediatamente cada vez que se edita un modelo de origen; un autor puede revisar la revisión primero y aplicarla cuando sea apropiado.

Paso 8: Revertir cuando sea necesario

Si una nueva revisión introduce un error o no está lista para su publicación, revise el historial del activo y restaure o seleccione una revisión anterior donde sea posible.

La reversión es útil cuando:

• Un diagrama se actualizó prematuramente.

• Se confirmó un diseño experimental.

• Un cambio introdujo relaciones incorrectas.

• La documentación debe reflejar temporalmente un estado aprobado anterior.

• Una auditoría requiere el examen de un diseño anterior.

6. Uso de la Pipeline con diferentes herramientas

Visual Paradigm Desktop

Desktop es adecuado para modelado complejo y trabajo a escala empresarial.

Un flujo de trabajo típico es:

1. Abra el proyecto en Desktop.

2. Cree o actualice el modelo.

3. Revise el modelo para verificar su corrección estructural.

4. Envíe el diagrama o el activo visual seleccionado a la Pipeline.

5. Los usuarios de OpenDocs insertan o actualizan el activo gestionado.

Este flujo de trabajo es útil para:

• Arquitectura empresarial

• Modelos UML grandes

• Ingeniería de bases de datos

• Bibliotecas de procesos BPMN

• Arquitectura de aplicaciones

• Ingeniería de sistemas

• Documentación de revisión de arquitectura

Visual Paradigm Online

La versión en línea es útil cuando los equipos necesitan colaboración basada en el navegador.

Un flujo de trabajo típico es:

1. Cree un diagrama en el espacio de trabajo en línea.

2. Invite a colaboradores a revisarlo o editarlo.

3. Finalice el diagrama.

4. Envíelo a través de la Pipeline.

5. Insértelo en OpenDocs.

Esto es especialmente efectivo para:

• Planificación de productos

• Talleres de procesos

• Recorridos de usuarios

• Colaboración en equipo

• Mapas de ruta

• Diseño de soluciones en etapas tempranas

Chatbot de diagramación con IA

El Chatbot con IA es útil para la ideación rápida y los primeros borradores.

Un flujo de trabajo práctico es:

1. Describa el sistema o el proceso en lenguaje natural.

2. Solicite un tipo de diagrama específico.

3. Revise el visual generado.

4. Corrija la terminología y las relaciones.

5. Envíe el resultado a través de la Pipeline.

6. Continúe refinándolo en VPasCode o Desktop si es necesario.

7. Publíquelo en OpenDocs.

Para obtener mejores resultados, especifique:

• Notación del diagrama

• Actores

• Componentes

• Relaciones

• Flujos principales y alternativos

• Condiciones de error

• Nivel de detalle requerido

• Público objetivo

Ejemplo de solicitud:

Cree un diagrama de contenedores C4 para una plataforma de suscripción.
Incluya el portal del cliente, la pasarela de API, el servicio de identidad,
el servicio de facturación, el servicio de notificaciones, la base de datos PostgreSQL
y el proveedor de pagos externo. Muestre los flujos de datos principales y
etiquete cada relación con su propósito.

Los visuales generados por IA deben tratarse como un diseño inicial o borrador hasta que sean revisados por un miembro calificado del equipo.

VPasCode

VPasCode es adecuado para usuarios que prefieren el Diagrama como Código.

Las ventajas incluyen:

• Definiciones de diagramas basadas en texto

• Revisión más fácil de los cambios estructurales

• Fuente de diagrama reutilizable

• Compatibilidad con flujos de trabajo orientados a código

• Iteración rápida

• Comparación de cambios más clara para definiciones textuales

Un flujo de trabajo común es:

1. Genere o escriba en PlantUML, Mermaid, Graphviz, Markmap u otro formato compatible.

2. Renderice el diagrama.

3. Sintaxis y diseño correctos.

4. Envíe la representación visual a la Pipeline.

5. Importe o refínelo en Desktop si se requiere un modelado más profundo.

6. Intégralo en OpenDocs.

VPasCode también puede actuar como un paso intermedio entre las ideas generadas por IA y el modelado formal en Desktop.

7. Casos de uso comunes

Documentación de arquitectura de software

Los arquitectos pueden publicar diagramas de componentes, despliegue, secuencia e infraestructura directamente en la documentación del sistema.

Cuando se agrega o elimina un servicio, el diagrama fuente se actualiza y la versión de OpenDocs puede actualizarse sin reemplazar manualmente los archivos de imagen.

Documentación de API

Los equipos pueden crear diagramas de secuencia para puntos de conexión como:

• POST /pedidos

• GET /clientes/{id}

• POST /pagos

• PUT /suscripciones

Cada sección de API puede incluir texto explicativo y un diagrama de interacción actual. Esto ayuda a los desarrolladores a comprender no solo los parámetros del punto de conexión, sino también los servicios, bases de datos y sistemas externos involucrados.

Requisitos del producto

Los gerentes de producto pueden crear flujos de procesos, recorridos de usuarios, mapas de historias y hojas de ruta, y luego integrarlos en documentos de requisitos del producto.

Esto mantiene la representación visual de una función alineada con los requisitos escritos.

Gestión de procesos empresariales

Los analistas de negocio pueden modelar procesos de estado actual y futuro, publicarlos en OpenDocs y mantener un historial de revisiones a medida que evolucionan los procedimientos.

Capacitación y incorporación

Los equipos pueden combinar diagramas, explicaciones escritas, libros de hojas giratorias y estanterías de libros para crear materiales de capacitación estructurados para nuevos empleados o clientes.

Cumplimiento y preparación para auditorías

La Pipeline puede apoyar la trazabilidad al preservar información de revisiones y notas de cambios contextuales. Los equipos pueden usarla para mostrar cómo una arquitectura, proceso o modelo de control ha cambiado con el tiempo.

La Pipeline no reemplaza el proceso formal de gobernanza de una organización, pero puede proporcionar evidencia útil para revisiones y seguimiento histórico.

Arquitectura de bases de datos y datos

Los diagramas de bases de datos y los modelos de flujo de datos pueden integrarse junto con descripciones de tablas, información de propiedad, clasificaciones de datos y notas de integración.

8. Modelo de gobernanza recomendado

Una implementación exitosa de la Pipeline requiere más que la integración de herramientas. Los equipos deben acordar cómo se nombran, revisan, aprueban y actualizan los activos.

Definir la propiedad

Asigne un propietario a cada activo importante.

Ejemplos:

• El equipo de arquitectura empresarial es propietario de los diagramas de arquitectura de la plataforma.

• El equipo de seguridad es propietario de los diagramas de límites de confianza.

• El equipo de producto es propietario de los mapas del viaje del cliente.

• El equipo de bases de datos es propietario de los modelos de datos lógicos y físicos.

Establecer estados del ciclo de vida

Los estados útiles incluyen:

• Borrador

• En revisión

• Aprobado

• Publicado

• Obsoleto

• Archivado

Utilizar una nomenclatura coherente

Un formato de nomenclatura estándar podría ser:

[Dominio] - [Sistema o Proceso] - [Tipo de Diagrama]

Ejemplos:

Identidad - Inicio de sesión y MFA - Diagrama de secuencia
Comercio - Finalizar compra - Diagrama de actividad
Pagos - Autorización - Diagrama de componentes

Exigir notas de cambios significativos

Cada actualización significativa debe explicar:

• Qué cambió

• Por qué cambió

• Quién lo solicitó

• Qué sistema o requisito se vio afectado

• Si los documentos relacionados necesitan revisión

Separar la experimentación de la publicación

Los diagramas generados por IA o exploratorios no deben convertirse automáticamente en documentación autoritativa. Utilice un proceso de revisión antes de marcar los activos como aprobados o publicarlos ampliamente.

Revise los activos incrustados regularmente

Programa revisiones según el riesgo:

• Arquitectura crítica: mensual o después de lanzamientos mayores

• Diagramas de API: cada vez que cambien los contratos

• Procesos de negocio: trimestralmente o después de cambios en las políticas

• Material de capacitación: al menos en cada ciclo de lanzamiento

• Diagramas de referencia de bajo riesgo: anualmente

9. Patrón práctico de documentación

Una página sólida de OpenDocs puede seguir esta estructura:

# Flujo de autorización de pago

## Propósito
Explica cómo la plataforma autoriza los pagos con tarjeta antes de crear un pedido.

## Alcance
Cubre la aplicación web, el servicio de pagos, el cribado de fraude,
el servicio de pedidos y el proveedor de pagos.

## Diagrama
[Activo visual gestionado por Pipeline]

## Flujo principal
1. El cliente envía los datos de pago.
2. La aplicación web envía una solicitud de autorización.
3. El servicio de pagos valida la solicitud.
4. El proveedor externo aprueba o rechaza el pago.
5. El servicio de pedidos crea un pedido tras la aprobación.

## Escenarios de fallo
- Datos de pago inválidos
- Tiempo de espera del proveedor agotado
- Rechazo del cribado de fraude
- Solicitud de autorización duplicada

## Responsabilidad
Equipo de la plataforma de pagos

## Historial de cambios
- Añadido paso de cribado de fraude
- Añadido manejo de tiempo de espera del proveedor
- Actualizada la secuencia de creación de pedidos

Este formato combina una explicación legible por humanos con una fuente visual gestionada.

10. Errores comunes a evitar

Tratar el Pipeline como almacenamiento de archivos ordinario

El beneficio principal no es simplemente almacenar una imagen en la nube. El valor proviene de mantener la relación con la fuente, el historial de revisiones y la conexión con la documentación.

Publicar sin revisar

Un diagrama puede ser técnicamente correcto pero aún así inadecuado para la audiencia. Verifica la legibilidad, la terminología, el alcance y los detalles sensibles antes de la publicación.

Crear activos duplicados

Evita enviar copias ligeramente diferentes del mismo diagrama al Pipeline con nombres poco claros. Actualiza el activo autoritativo existente cuando sea posible.

Usar notas de cambio vagas

«Diagrama actualizado» aporta poco valor. Describe el cambio arquitectónico o de proceso real.

Incrustar diagramas sin explicación

Una imagen visual debe ir acompañada de suficiente texto para que un lector entienda su propósito, límites y decisiones importantes.

Permitir que la salida de la IA se vuelva autoritativa automáticamente

La IA es efectiva para generar primeros borradores, pero la arquitectura, la seguridad, el cumplimiento y la lógica de negocio deben ser validados por expertos en la materia.

Ignorar los indicadores de actualización de documentos

Un diagrama gestionado puede volverse obsoleto si las revisiones disponibles nunca se revisan. Asigna la responsabilidad de verificar y aplicar las actualizaciones.

11. Medición de los beneficios

Los equipos pueden evaluar el Pipeline utilizando medidas prácticas como:

• Tiempo requerido para actualizar un diagrama en múltiples documentos

• Número de diagramas obsoletos encontrados durante las revisiones

• Número de activos duplicados

• Tiempo dedicado a exportar y volver a subir visuales

• Porcentaje de diagramas principales con un propietario designado

• Porcentaje de páginas de documentación vinculadas a activos aprobados

• Número de eventos de reversión o revisión de revisiones

• Tiempo requerido para incorporar a un nuevo miembro del equipo

• Número de defectos en la documentación causados por visuales desactualizados

El resultado más importante no es la cantidad de diagramas almacenados. Es la reducción de la brecha entre el diseño actual del sistema y la documentación utilizada para comprenderlo.

12. Plan de adopción recomendado

Fase 1: Comience con un solo flujo de trabajo

Elija un escenario de alto valor, como:

• Documentación de arquitectura de software

• Diagramas de secuencia de API

• Flujos de requisitos del producto

• Documentación de bases de datos

Fase 2: Defina estándares

Acuerde:

• Convenciones de nomenclatura

• Propiedad

• Notas de revisión

• Estados de revisión

• Permisos de publicación

• Responsabilidades de actualización

Fase 3: Convierta la documentación existente

Reemplace capturas de pantalla frecuentemente desactualizadas con activos gestionados por Pipeline. Comience con documentos que se actualizan con frecuencia o son utilizados por muchos equipos.

Fase 4: Agregue flujos de trabajo de IA y Diagrama como Código

Utilice el Chatbot de IA para la ideación y VPasCode para el refinamiento basado en texto. Utilice Desktop cuando el modelo requiera un análisis empresarial más profundo.

Fase 5: Establezca una revisión continua

Incluya las revisiones de activos de Pipeline en:

• Planificación de lanzamientos

• Comités de revisión de arquitectura

• Cierre de sprint o iteración

• Procedimientos de gestión de cambios

• Verificaciones de calidad de la documentación

Conclusión

La Pipeline de Visual Paradigm transforma la gestión de diagramas de una tarea de manejo de archivos en un flujo de trabajo de documentación conectado. Los equipos pueden crear visuales en Desktop, Online, el Chatbot de IA o VPasCode; comprometerlos en un repositorio centralizado; incrustarlos en OpenDocs; y actualizarlos mediante revisiones rastreadas.

Su beneficio más importante es la continuidad. El diagrama permanece conectado a la documentación, la documentación permanece más cerca del sistema actual, y los equipos dedican menos tiempo a exportar, recortar, subir, reemplazar y buscar la versión correcta.

El modelo operativo recomendado es:

Crear con cuidado, comprometer deliberadamente, documentar con contexto, revisar revisiones y publicar solo actualizaciones aprobadas.