Skip to main content

Command Palette

Search for a command to run...

Agentes en la nube

Rollouts

Rollouts supervisa cada pull request desde la revisión hasta producción. Redacta un plan de despliegue cuando se abre el pull request, contrasta el cambio con tu telemetría una vez implementado e informa de su estado en cada entorno.

Configura Rollouts en Automatizaciones.

Cómo funciona

Planes de despliegue

Cuando se abre un pull request, Rollouts analiza el diff y los sistemas a los que afecta, y luego redacta un plan de despliegue. El plan detalla los riesgos que Rollouts ha detectado, el efecto que debería tener el cambio, las señales que va a comprobar y cualquier carencia de instrumentación que dificulte verificar el cambio. En GitHub, GitLab.com y Bitbucket Cloud, Rollouts publica el plan como comentario en el pull request. En Origin, el plan aparece en la página del pull request.

Para cambiar el plan, menciona en un comentario del pull request el identificador que aparece en el comentario de Rollouts e indica qué debe vigilar o ignorar. Rollouts revisa el plan y responde. Solo las personas con acceso de escritura al repositorio pueden cambiar el plan.

Seguimiento de implementaciones

Rollouts se activa con los eventos de implementación del commit del cambio y ejecuta el plan sobre tus registros, métricas y trazas. Hace un seguimiento de cada entorno por separado, de modo que un cambio puede verificarse en staging y, aun así, marcarse en producción.

Rollouts comprueba cada implementación en cuanto se produce y vuelve a hacerlo a los 20 minutos, a la hora, al día y a los 3 días.

Si un cambio fusionado se publica sin una implementación registrada, selecciona Run checks en la página del cambio. El botón aparece a la derecha de las pestañas de entorno; mientras el cambio aún no tiene comprobaciones, aparece solo en esa fila. Elige el entorno y los servicios y, a continuación, inicia las comprobaciones. Rollouts considera que la versión del cambio está activa en ese entorno y la comprueba con el mismo calendario.

Regresiones

Cuando Rollouts detecta una regresión, identifica el cambio que considera responsable, abre un problema y avisa a su autor. Hace lo mismo cuando un cambio no provoca ninguna regresión, pero no funciona como se esperaba: la nueva ruta de código se ejecutó, pero no produjo el efecto previsto, generó errores o se comportó de forma incorrecta. En la página del problema, selecciona Fix issue para iniciar un agente en la nube que se encargue de él, o Close para cerrarlo. Al cerrarlo, se te pide un motivo (Fixed, Not a Real Issue, Expected, Duplicate u Other) y una nota, y ambos quedan registrados en el historial del problema. El agente se abre en un panel dentro de la página del problema. Una vez iniciada una solución, View fix reemplaza a Fix issue y vuelve a abrir ese agente. Rollouts no fusiona, revierte ni deshace cambios por su cuenta.

Hacer un seguimiento de los cambios

La página Rollouts enumera los pull request fusionados y los agrupa en Atención, Monitorización, Pendiente y Verificado. Míos muestra los cambios a los que estás suscrito y Equipo muestra todos los cambios del equipo. Los administradores de equipo acceden por defecto a Equipo, y el resto de usuarios, a Míos. Cada entorno en el que se implementa un cambio muestra su propio estado, como Implementando, Monitorización, Verificado, Implementación fallida o Problemas detectados.

Un cambio permanece en Atención mientras tenga un problema abierto o una implementación fallida. Cuando se cierran todos sus problemas, pasa a considerarse Verificado. Si se reabre un problema, el cambio vuelve a Atención.

Servicios

Selecciona Servicios en la parte superior de la página de Rollouts para ver todos los servicios que reporta tu pipeline de implementación. Para ocultar un servicio de esa lista, ábrelo y selecciona Archive. Sus implementaciones se conservan en el historial. El servicio pasa a Archived, donde puedes recuperarlo con Restore.

Configurar Rollouts

En Automatizaciones, abre la pestaña Team y selecciona Enable en la tarjeta de Rollouts, dentro de From Cursor. La configuración consta de cuatro pasos:

1

Acceso a los repositorios supervisados

Elige los repositorios que quieres supervisar. Cada pull request que se lanza desde estos repositorios recibe su propio seguimiento, vinculado a su autor. Rollouts supervisa repositorios en Origin, GitHub, GitLab.com y Bitbucket Cloud.

2

Enviar eventos de implementación a Rollouts

Indica a Rollouts cuándo empieza y termina cada implementación en producción. Crea una clave de API y guárdala como el secreto de CI CURSOR_API_KEY. Usa una clave de API de usuario, una clave de API de cuenta de servicio o una clave de API de administrador de equipo con el scope admin:*. Puedes hacerlo manualmente o con un agente. Si eliges un agente, un agente de configuración abre una pull request que añade las llamadas; después, fusiónala para completar la configuración.

3

Telemetría

Conecta tus herramientas de observabilidad, como Datadog, para que cada cambio se contraste con lo que ocurre en producción. Rollouts necesita al menos una herramienta conectada. Sin ella, los cambios se quedan pendientes y Rollouts no puede detectar problemas.

4

Notificaciones

Elige cómo se notifica a los autores de las pull requests sobre sus despliegues.

Enviar eventos de implementación

1

Intercambiar la clave de API por un token

Al inicio del job de implementación, intercambia el secreto CURSOR_API_KEY por un token. Todas las llamadas siguientes envían este token.

TOKEN=$(curl -s -X POST https://api2.cursor.sh/auth/exchange_user_api_key \  -H "Authorization: Bearer $CURSOR_API_KEY" -H "Content-Type: application/json" -d '{}' \  | jq -r .accessToken)
2

Crear cada entorno y servicio una sola vez

Ejecuta esto manualmente o como paso de arranque antes del job de implementación. Crea los registros a los que hacen referencia las llamadas siguientes, así que ejecútalo antes del primer informe.

curl -s -X POST https://api.cursor.com/factory.v1.DeploymentsService/CreateEnvironment -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -H "Connect-Protocol-Version: 1" \  -d '{"environmentId":"{env}","environment":{"displayName":"{env}"}}'curl -s -X POST https://api.cursor.com/factory.v1.DeploymentsService/CreateService -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -H "Connect-Protocol-Version: 1" \  -d '{"serviceId":"{service}","service":{"displayName":"{service}"}}'
3

Crear la implementación

Ejecuta esto justo antes de lanzar. deployVersion es el SHA del commit que se lanza.

DEPLOYMENT=$(curl -s -X POST https://api.cursor.com/factory.v1.DeploymentsService/CreateDeployment -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -H "Connect-Protocol-Version: 1" \  -d '{"deployment":{"deploySourceUri":"https://github.com/{owner}/{repo}","environment":"environments/{env}","service":"services/{service}","deployVersion":"'"$GIT_SHA"'"},"event":{"started":{},"actor":"'"$CI_JOB_URL"'"}}' \  | jq -r .deployment.name)
4

Añadir el evento de finalización

Ejecuta esto en cuanto se conozca el resultado. Un fallo al enviar el informe nunca debe hacer fallar la implementación.

curl -s -X POST https://api.cursor.com/factory.v1.DeploymentsService/AppendDeploymentEvent -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -H "Connect-Protocol-Version: 1" \  -d '{"name":"'"$DEPLOYMENT"'","event":{"completed":{"succeeded":{}},"actor":"'"$CI_JOB_URL"'"}}'# En caso de fallo:   "event":{"completed":{"failed":{"message":"<why>"}},"actor":...}# Si se cancela: "event":{"aborted":{},"actor":...}

Ajustes

Los ajustes de Rollouts tienen cuatro secciones:

  • Acceso al código. Los repositorios que Rollouts vigila (hasta 200) y qué cambios supervisar.
  • Eventos de implementación. Cómo informa tu pipeline de qué se implementa y dónde.
  • Fuentes de datos. Las conexiones MCP que Rollouts consulta para verificar los cambios implementados y detectar regresiones.
  • Notificaciones. Cómo te enteras de las implementaciones y regresiones de tus cambios.

El interruptor situado en la parte superior de Ajustes activa o desactiva Rollouts para tu equipo. Su etiqueta muestra Enabled o Disabled. Solo los administradores de equipo pueden activar o desactivar Rollouts y configurar los eventos de implementación. Los demás miembros ven estos controles, pero no pueden modificarlos.

Elige qué cambios supervisar

En Which changes to monitor, describe en lenguaje natural qué pull requests debe omitir Rollouts. De forma predeterminada, Rollouts omite los cambios que no pueden afectar a lo que se ejecuta en un entorno implementado: cambios que solo afectan a la documentación, correcciones de formato, lint o erratas que no alteran el comportamiento, y cambios que solo afectan a las pruebas. Borra el texto para supervisar todos los cambios en los repositorios observados.

Un pull request solo se omite cuando coincide claramente. Cuando Rollouts omite un pull request, explica el motivo en un comentario. Para supervisarlo de todos modos, menciona el identificador que se indica en el comentario.

Notificaciones

Activa Personal Slack Notifications para recibir avisos en Slack sobre tus cambios. Al principio, solo recibirás mensajes de Problemas detectados. Para recibir también avisos cuando una implementación se complete correctamente o falle, o cuando una comprobación no encuentre problemas, activa Deployment succeeded, Deployment failed o Check clear. En Deliver to, elige Direct message o Channel. Si eliges un canal, introduce el nombre o el ID de un canal público, invita a cada aplicación que aparece debajo del campo y guarda. No se admiten canales de Slack Connect.

Antes, un administrador de equipo debe añadir Rollouts a Slack. Solo los administradores de equipo pueden cambiar los valores predeterminados de notificación del equipo. Si se activa el valor predeterminado del equipo, los miembros recibirán un mensaje de Slack cuando una comprobación detecte problemas en su pull request, hasta que cambien sus propios ajustes. Las notificaciones de Slack no están disponibles en modo de privacidad.

Páginas relacionadas