Revisión y automatización

Entornos persistentes y revisión de CI

Cree entornos persistentes compartidos con el asistente de cuatro pasos, configure perfiles de área de trabajo de CI, revise los eventos de fusión en las cinco pestañas de CI y promueva candidatos validados desde Console.

Administradores de clientesOperadores de plataforma

Última actualización 18 de junio de 2026

Los entornos persistentes y la revisión de CI son flujos de trabajo propiedad de Console para la validación compartida. Úselos cuando un cliente necesite un entorno de ejecución de QA, UAT, demostración, staging o revisión de cliente de larga duración y quiera que los cambios pasen la revisión de código y QA antes de ser promovidos.

Estos flujos de trabajo son diferentes de las áreas de trabajo personales de los desarrolladores. Un entorno persistente es un entorno de ejecución compartido del cliente con políticas, facturación, soporte e historial de eventos. Un perfil de área de trabajo de CI es un perfil de entorno de ejecución de revisión o QA, propiedad de una ruta, que Console utiliza cuando un evento de fusión necesita verificaciones de navegador, base de datos, inteligencia de código o entorno de destino.

Ambas superficies viven en el panel izquierdo de Console. Entornos posee los entornos de ejecución compartidos y sus candidatos; CI y revisión posee las rutas, los eventos de fusión, las ejecuciones y la transferencia al proveedor. Ambas se enlazan entre sí, de modo que puede moverse entre un entorno y su historial de revisión sin perder el contexto.

Antes de empezar

• Necesita un rol de administrador de cliente u operador de plataforma para crear entornos y perfiles de CI.
• El repositorio y la rama que planea validar deben ser accesibles a través de un proveedor de Git conectado. Consulte Configuración del administrador de cliente para la conexión del proveedor y Copias de seguridad y fuentes de restauración para las semillas de base de datos.
• Decida si la ruta es solo de rama de origen o apunta a un entorno persistente, porque esa elección cambia qué verificaciones se ejecutan.

Crear un entorno persistente

Abra Entornos y seleccione Crear entorno. Console abre un asistente de cuatro pasos con un riel de pasos en la parte superior: Origen, Entorno de ejecución, Política y Revisión. Un panel de lanzamiento en vivo a la derecha muestra las selecciones actuales y enumera los elementos requeridos que aún están bloqueando.

1. Origen. Elija el alcance del cliente, nombre el entorno y confirme la URL del repositorio y la rama de origen. Console verifica el acceso del proveedor aquí. Cuando un cambio depende de más de un repositorio, habilite la pila de repositorios para que un repositorio de entorno de ejecución y un repositorio de producto se descarguen en orden.
2. Entorno de ejecución. Elija el perfil de entorno persistente, la familia de plantillas, el destino del área de trabajo y el tamaño del entorno de ejecución. El perfil establece las suposiciones de versión de WebCentral, incluido el paquete esperado de Java, Gradle, Tomcat y licencia para el área de trabajo de respaldo.
3. Política. Establezca la fuente de semilla (copia de seguridad de base de datos), la exposición y el motor de migración de base de datos. Elija el motor de migración que coincida con el destino: Flyway, ARCHIBUS DUW o migraciones deshabilitadas.
4. Revisión. Confirme el plan de lanzamiento. La cuadrícula de revisión resume el perfil, el modo de repositorio, el tamaño y la copia de seguridad de base de datos. Cuando todo lo requerido está presente, seleccione Crear entorno.

Cuando comienza la creación, Console crea el registro del entorno e inicia el área de trabajo de respaldo cuando el destino seleccionado lo admite. La tarjeta del entorno muestra entonces el área de trabajo persistente, las versiones candidata y actual, el estado de actualización del entorno, los accesos directos del entorno de ejecución y el historial de eventos.

Los entornos persistentes están pensados para permanecer encendidos más tiempo que las áreas de trabajo de desarrollo personales. Elija el tamaño del entorno de ejecución y el plazo de facturación de manera deliberada, y use el historial de eventos para confirmar cuándo están listos el área de trabajo de respaldo, la ruta de Tomcat, la semilla de base de datos y el estado de promoción.

Use el perfil de versión de WebCentral que coincida con el repositorio o WAR de origen, especialmente para versiones más antiguas de WebCentral que necesitan Tomcat 8.5 o Tomcat 9 en lugar del valor predeterminado actual. Consulte Preajustes de área de trabajo para ver cómo esos perfiles se asignan a la configuración del entorno de ejecución.

Abrir los accesos directos del entorno de ejecución del entorno

Después de que exista el área de trabajo persistente, use las acciones de la tarjeta del entorno:

No pegue registros sin procesar en los tickets de soporte. En su lugar, comparta el estado visible, el ID de ejecución, el nombre del área de trabajo, la marca de tiempo y el texto del error saneado.

Actualizar un entorno de ejecución en dos etapas

Cuando una versión candidata está lista para aterrizar en el entorno de ejecución persistente, Console usa una actualización deliberada de dos etapas para que un entorno compartido nunca se reinicie por accidente.

1. Solicitar actualización del entorno. Esto aprueba la actualización para el área de trabajo persistente y la marca como solicitada. Console muestra que la actualización está lista para comenzar pero aún no ha tocado el entorno en ejecución.
2. Iniciar actualización del entorno. Esto inicia la actualización del área de trabajo persistente y espera el resultado del entorno de ejecución. Console mueve el estado a en ejecución, luego a aplicado una vez que el entorno de ejecución persistente está en la versión promovida.

La tarjeta del entorno muestra el estado de actualización actual y una breve descripción para cada etapa, además de filas de evidencia del entorno de ejecución para que pueda confirmar qué cambió.

Crear un perfil de área de trabajo de CI

Abra CI y revisión y seleccione Crear perfil de CI (es Crear CI/perfil en la barra de acciones superior). Console abre un asistente de cuatro pasos con la misma forma de riel de pasos: Origen, Entorno de ejecución, Política y Revisión, que se muestran en el área de trabajo como Ruta de origen, Entorno de ejecución del área de trabajo, Política de ejecución y Revisar y crear.

1. Ruta de origen. Elija el cliente, el proveedor, el repositorio, la rama y un entorno de destino opcional. Seleccionar un entorno de destino es lo que activa la verificación de destino más tarde. Aplique un perfil de pila de repositorios cuando el cambio necesite un repositorio de entorno de ejecución más un repositorio de producto o de dependencia.
2. Entorno de ejecución del área de trabajo. Elija la forma del área de trabajo: revisión, QA, revisión más QA, o QA de destino. Seleccione la plantilla de CI, el destino del área de trabajo y el tamaño.
3. Política de ejecución. Establezca la retención, los artefactos, qué etapas se ejecutan, el alcance de QA y el motor de migración de base de datos. Seleccione el perfil de versión de WebCentral y la copia de seguridad de base de datos. La revisión generalmente usa razonamiento alto; QA generalmente usa razonamiento bajo después de que las verificaciones deterministas hayan recopilado evidencia.
4. Revisar y crear. Confirme el perfil de la ruta en la cuadrícula de revisión y luego seleccione Crear perfil de CI.

Guardar un perfil de área de trabajo de CI no crea un área de trabajo de desarrollador personal. Crea los metadatos de la ruta que Console usa cuando un evento de fusión o una ejecución de prueba necesita un área de trabajo de revisión o QA. Las ejecuciones ligeras aún pueden usar el ejecutor de Console sin un área de trabajo cuando no se requieren herramientas de navegador, base de datos e inteligencia de código.

Si la ruta no tiene un entorno de destino persistente, Console aún puede ejecutar QA de rama de origen. La revisión de código comienza desde un evento de fusión de Console, una solicitud de extracción del proveedor o un diff explícito para que los revisores vean el conjunto de cambios real y la puerta de fusión. La verificación del entorno de destino se omite porque no hay configuración de entorno con la que validar.

Las cinco pestañas de CI y revisión

El área de trabajo de CI y revisión está organizada en cinco pestañas sobre el panel principal, cada una con un recuento en vivo:

Sobre las pestañas, una franja de flujo de trabajo muestra la canalización de etapas para el evento de fusión seleccionado: Entrada, Revisión, QA, QA de destino y Fusión. Cada etapa muestra su propio estado, como abierta, en espera, omitida o esperando verificaciones.

Solo rama de origen frente a entorno de destino

Las rutas solo de rama de origen ejecutan la revisión de código y QA del ejecutor sin un entorno persistente seleccionado. En ese modo, Console omite intencionalmente la verificación del entorno de destino, y la etapa QA de destino se muestra como omitida.

Las rutas con un entorno persistente seleccionado agregan una verificación del entorno de destino. Después de que la revisión de código y el QA del ejecutor pasen, Console valida el candidato contra los valores predeterminados del entorno seleccionado antes de que la fusión o la promoción puedan continuar.

La verificación del entorno de destino usa los valores predeterminados del entorno que importan después de la promoción, incluidos el tipo de base de datos, la copia de seguridad de base de datos, el motor de migración, el destino del área de trabajo, la plantilla, la cadena de herramientas, los parámetros del área de trabajo y la anulación de licencia cuando está configurada.

Cuando una ruta usa una versión más antigua de WebCentral, mantenga el mismo perfil de versión en el entorno persistente, el perfil de QA de origen y el perfil de QA de destino. Eso hace que la evidencia de revisión, las pruebas de humo del navegador y la verificación final de promoción se ejecuten con las mismas suposiciones del entorno de ejecución.

Configurar la transferencia al proveedor

Abra la pestaña Transferencia al proveedor y cargue una ruta para registrar o verificar la conexión del proveedor administrado. Console posee la capa de revisión; la conexión del proveedor le permite publicar comentarios de revisión y QA, enviar retroalimentación de estado y recibir eventos de fusión.

Desde esta pestaña puede:

• Guardar una conexión administrada. Registre la aplicación del proveedor, el enlace de servicio o una referencia de credencial aprobada como token://..., k8s://secret/key, o una referencia de OpenBao/Vault. Console también puede aceptar un token de proveedor de un solo uso o una contraseña de aplicación y almacenarlo en el almacenamiento de tokens de Console, un Kubernetes Secret o OpenBao/Vault. Después de guardar, Console muestra solo una vista previa de la credencial.
• Rotar la credencial. Use Rotar credencial cuando un token caduque o sea reemplazado. Ejecute una verificación de conexión después.
• Revocar la credencial. Use Revocar credencial para conservar el registro de conexión pero detener la publicación hasta que se agregue una nueva referencia de credencial.
• Instalar o reconciliar un webhook. Use Instalar webhook para que las actualizaciones de eventos de fusión lleguen a Console, Reconciliar webhook para reparar un enlace desviado y Eliminar webhook para detener los eventos. Guarde o seleccione una ruta antes de instalar el webhook.
• Verificar la conexión. Use Verificar conexión para confirmar el estado de salud antes de depender de la ruta para la revisión, el estado o la publicación de comentarios.

Un panel de preparación recorre los metadatos de la ruta, el servicio del proveedor, el objetivo de instalación, la fuente de la credencial, las acciones permitidas, el registro de Console y la salud del proveedor, para que pueda ver qué paso aún falta.

No coloque tokens de proveedor, cargas útiles de credenciales sin procesar ni secretos de implementación privados en los nombres de rutas, descripciones, notas de QA o instrucciones de rutas.

Revisar un evento de fusión

Los eventos de fusión son la unidad de revisión normal en Console. Un evento de fusión puede provenir de un webhook del proveedor, una transferencia de área de trabajo o un registro manual en Console.

1. Abra CI y revisión.
2. Elija el evento de fusión en la pestaña Eventos de fusión.
3. Abra Revisión en Console para ver la rama de origen, la rama de destino, el enlace del proveedor, los elementos de característica, la lista de revisores y los cambios apilados.
4. Asigne revisores o agregue un revisor personalizado, y actualice las notas del revisor.
5. Seleccione Iniciar revisión y QA cuando la ruta esté lista.
6. Observe la franja de flujo de trabajo: Entrada, Revisión, QA, QA de destino y Fusión.

Cuando se detectan cambios apilados, Console muestra la vista previa de pila acotada y el contexto por archivo que puede mostrar de forma segura. Use los enlaces del proveedor solo para contexto secundario.

La revisión de Archibot y el QA del ejecutor pueden ejecutarse por separado o juntos. La revisión se centra en el código, el contexto de diff apilado, las pruebas faltantes, las rutas de riesgo y el impacto en la documentación. El QA se centra en la evidencia de ejecución, como las pruebas de humo del navegador, las verificaciones de base de datos, los comandos de prueba seleccionados, la validación de la cadena de herramientas y los registros del área de trabajo. Consulte Bots de Console para ver cómo se configuran los bots de revisión y QA de Archibot.

Si una ejecución necesita detenerse, use Cancelar ejecución en la ejecución en la pestaña Evidencia y registros. Console marca la ejecución como cancelada.

Fusionar y promover

Console mantiene la fusión humana como valor predeterminado.

Antes de que Fusionar en Console esté disponible:

• Debe registrarse la aprobación de un revisor.
• La etapa de revisión de código solicitada debe pasar.
• La etapa de QA del ejecutor solicitada debe pasar.
• Si se selecciona un entorno de destino, la verificación del entorno de destino debe pasar.

Después de que se complete la fusión, el candidato validado puede convertirse en un candidato de promoción para el entorno persistente seleccionado. Use Promover candidato desde Entornos solo cuando la última ejecución de CI y la verificación del entorno de destino coincidan con la versión candidata. Una vez promovido, use la actualización de entorno de dos etapas descrita anteriormente para aterrizarlo en el entorno de ejecución en funcionamiento.

Registros, evidencia y Shared Drive

CI y revisión y Entornos mantienen el historial de eventos en Console. Use la línea de tiempo de ejecución en la pestaña Evidencia y registros para ver los cambios de etapa, los nombres de trabajos, el estado del entorno de destino y las líneas de registro saneadas.

Use Guardar en Shared Drive cuando soporte necesite que la evidencia sobreviva a la ventana normal de retención del registro de ejecución. La cuenta necesita una unidad con permiso de escritura para esto. Mantenga la evidencia de larga duración saneada y aprobada por el cliente. Consulte Archibot del área de trabajo y Shared Drive para ver cómo funciona el acceso a unidades con alcance.

Los revisores deberían poder responder tres preguntas desde Console antes de fusionar:

• ¿Qué cambió, incluidos los diffs apilados?
• ¿Qué verificaciones de revisión, QA y destino se ejecutaron?
• ¿Dónde está la evidencia saneada si la ejecución necesita revisión de soporte más adelante?

No comparta:

• Claves de API, tokens de proveedor, secretos de webhook, cookies o enlaces de invitación.
• Kubernetes Secrets, variables de entorno de pod, kubeconfigs o tokens de Coder.
• URL de base de datos sin procesar, contenidos de copia de seguridad sin procesar o archivos de licencia.
• Transcripciones privadas o volcados de datos de clientes.

Bloqueadores comunes

Transferencia a soporte

Para soporte, incluya:

• La cuenta del cliente y el nombre del entorno.
• El ID del evento de fusión o el ID de la ejecución de CI.
• La rama de origen, la rama de destino y el número de solicitud de fusión del proveedor cuando sea visible.
• La etapa que está bloqueada.
• El error de Console saneado o el resumen del registro.

No incluya credenciales sin procesar, registros completos con secretos, datos privados de base de datos ni enlaces de un solo uso. Consulte Transferencia a soporte para la lista completa de verificación de evidencia.