Orbit
Canalización de Implementación Orbit
The Pipeline tab is a single page that answers "what happens when we push". It shows every way a deploy can be triggered, every gate that can stop one, the state of each environment, and which build…
La pestaña Pipeline es una página única que responde a "qué sucede cuando hacemos push". Muestra cada forma en que se puede activar un deploy, cada puerta que puede detenerlo, el estado de cada entorno y qué características de compilación están activadas, todo leído desde la configuración real de tu proyecto.
Dónde vive el Pipeline
Abre Orbit, haz clic en el proyecto y elige Pipeline bajo el grupo Deployments en la tira de pestañas del proyecto. La página está etiquetada como Deployment pipeline.
Es un panel de solo lectura. Nada se configura aquí; cada sección se vincula al lugar donde realmente vive la configuración. Ese es su valor: una pantalla para entender el proyecto, en lugar de leer ocho tarjetas de configuración.
Alertas en la parte superior
Dos banners aparecen cuando corresponde:
- Deploy lock active, con un enlace Manage. Los deploys activados por push se están omitiendo.
- N deployments awaiting approval, con un enlace Review. Alguien necesita aprobar o rechazar los deploys.
Si alguno está mostrándose y te preguntas por qué un push no se ha deployado, tienes tu respuesta sin leer más.
Estadísticas de compilación
Un panel compacto muestra, durante las compilaciones recientes: tasa de éxito, tiempo promedio de compilación y cuántas fueron exitosas. Es una verificación de salud más que un análisis. Para la imagen completa, consulta Orbit Project Analytics y Orbit Build Insights.
Fuentes de activación
Esta sección enumera cada ruta hacia un deploy para este proyecto:
| Fuente | Qué muestra |
|---|---|
| Git push | El repositorio conectado, o No repo connected |
| Branch previews | Si se crean previsualizaciones automáticamente en cualquier rama |
| Git tag | El patrón de etiqueta, si uno está configurado |
| Manual deploy | Siempre disponible |
Lee esto siempre que te sorprenda un deployment. Si apareció una compilación y nadie hizo push, uno de estos es la explicación: una etiqueta, un deploy hook, o alguien presionando un botón.
Puertas y seguridad
La sección más grande es la lista de puertas, cada una mostrando su estado actual con un enlace Configure a la tarjeta de configuración relevante.
| Puerta | Qué hace |
|---|---|
| Approval gate | Los deploys de producción requieren aprobación explícita |
| Staging prerequisite | La producción espera a staging en el mismo commit |
| CI checks | Comprobaciones requeridas que deben pasar, o No checks required |
| Freeze window | Fines de semana bloqueados, horas personalizadas, o sin horario de congelación |
| Deploy lock | Activo, o sin bloqueo |
| Health check | La ruta revisada después del deploy, o Disabled |
| Auto-rollback | Revierte en fallo de health check |
| Skew protection | La ventana de retención para activos antiguos |
| Auto retry | Cuántas veces se reintentan los fallos de infraestructura |
La mayoría de estas puertas se aplican solo a deploys activados por push. Los deploys manuales desde el panel y los deploy hooks pasan directamente. La excepción se comporta de manera diferente, y el detalle de cada puerta se cubre en Deploying Your Project. Lee eso antes de confiar en una puerta como control.
Leyendo las puertas como una lista de verificación
Para un proyecto que importa, una línea de base sensata es:
- Health check: configurado, apuntando a una ruta que ejercita la aplicación en lugar de un shell en caché.
- Auto-rollback: activado. Sin un health check no tiene nada en qué actuar, así que los dos van juntos.
- Auto retry: uno o dos. Reencola compilaciones que fallaron por errores de infraestructura como un blip de red, y no reintenta errores de código, así que no te cuesta nada excepto tiempo ahorrado.
- Approval gate: activado para cualquier cosa donde un mal deploy es caro, desactivado donde te ralentiza más de lo que te protege.
Si la página muestra Health check Disabled y Auto-rollback activado, esa combinación no hace nada. Es una de las desonfiguraciones más fáciles de mantener durante meses sin notarlo, y esta página es donde lo detectas.
Flujo de entornos
La sección Environment flow dibuja cada entorno como una tarjeta con su estado actual: LIVE, BUILDING o PAUSED, la rama que rastrea, y el número de reintento si el deployment actual es un reintento.
Los badges en cada tarjeta muestran qué está habilitado para ese entorno:
- Smoke tests, solicitudes GET ejecutadas contra rutas elegidas después de cada deploy exitoso.
- Auto-promote, promocionando staging a producción después de un número de horas saludables.
- Canary, el porcentaje de tráfico en un deployment canary.
- Inherits prod vars, donde staging fusiona variables de entorno de producción con prioridad más baja.
- Scheduled rebuild, donde producción se reconstruye en un intervalo.
Cada tarjeta se vincula a los deployments de ese entorno. Si un entorno dice No deployments yet, existe en configuración pero nada se ha enviado a él.
Características activas
La última sección resume la configuración a nivel de compilación:
| Característica | Valores |
|---|---|
| Server mode | SSR habilitado o solo estático |
| Auto-create on push | Si los pushes de rama crean entornos |
| Health checks | Activado o desactivado |
| Build retry | Un máximo, o desactivado |
| Deploy groups | Agrupado con otros proyectos, o independiente |
| Build timeout | El límite por compilación |
| Preview expiry | Días antes de que las previsualizaciones se pausan, o nunca |
Server mode es el que atrapa a la gente. Un framework que renderiza en el servidor lo necesita activado; una exportación estática no. Si tu proyecto se compila bien y luego sirve una página en blanco o un 404 en cada ruta excepto la página de inicio, comprueba esto primero. Consulta Frameworks Orbit Supports.
Preview expiry es el de mantenimiento. Configurado para nunca, los entornos de preview se acumulan indefinidamente.
Usando la página Pipeline
Cuando incorpores a alguien. Envíalos aquí primero. Es una capacitación más rápida y precisa que cualquier documento, porque se genera desde la configuración en vivo.
Cuando un deploy no sucedió. Trabaja de arriba a abajo: banners, luego fuentes de activación, luego puertas. Uno de los tres lo explicará.
Antes de un release arriesgado. Verifica que la sección de puertas lea de la manera que crees. Es la diferencia entre creer que tienes auto-rollback y tenerlo.
Durante un incidente. El flujo de entornos te dice qué está activo dónde, y si algo está en construcción.
Solución de problemas
La página muestra No repo connected. El proyecto no tiene repositorio. Conecta uno: consulta Connecting a GitHub Repository.
Una puerta está activada pero los deploys aún se realizan. Es solo activado por push. Un deploy hook o un deploy manual del panel no se ve afectado.
Un entorno muestra PAUSED. Los entornos de preview se pausan automáticamente una vez pasada su expiración. Redeploy para traer uno de vuelta.
Auto-promote se muestra pero nada se promociona. Requiere el número configurado de horas saludables con smoke tests pasando, y se evalúa periódicamente en lugar de instantáneamente.
Dónde ir a continuación
- Deploying Your Project para lo que realmente bloquea cada puerta.
- Orbit Project Settings para cambiar cualquiera de esto.
- Rolling Back a Deployment cuando una puerta no te salvó.