Orbit
Revertir una Implementacion
If a deployment breaks production, you can put an earlier build back in front of traffic in seconds without rebuilding anything. This guide covers how rollback works, how to pick the right…
Si un deployment rompe la producción, puede poner una compilación anterior frente al tráfico en segundos sin recompilar nada. Esta guía cubre cómo funciona la reversión, cómo elegir el deployment correcto, las reversiones automáticas que Orbit puede realizar por usted, y qué hacer después de haber revertido.
Cómo funciona la reversión
Orbit conserva el artefacto empaquetado de cada compilación exitosa. Una reversión no vuelve a ejecutar su instalación ni su comando de compilación: promociona un artefacto que ya existe y ya ha sido servido, por lo que se completa en segundos y no puede fallar por ninguna de las razones por las que una compilación puede fallar.
Esta es toda la razón para recurrirla primero. La reversión es más rápida y mucho más predecible que intentar corregir hacia adelante mientras su sitio está roto.
Reversión a un deployment anterior
- Abra su proyecto en Orbit.
- Abra la pestaña Deployments.
- Encuentre el último deployment que sepa que funcionaba bien.
- Haga clic en Roll back en esa fila y confirme.
La confirmación dice exactamente qué sucederá: el tráfico será servido desde la compilación anterior inmediatamente, y el deployment actual será reemplazado.
También puede revertir desde la página de detalle del deployment, donde el botón dice Rollback to el hash de commit corto.
El deployment restaurado recibe la insignia CURRENT. El deployment del que se revirtió permanece en el historial con el estado Rolled back.
La reversión no es destructiva y no necesita deshacerse. Nada se elimina, el historial no se reescribe, y su repositorio permanece intacto. Su próximo push exitoso a la rama de producción simplemente se convierte en la nueva versión activa de la manera normal.
Identificar el deployment correcto
Cada fila en la pestaña Deployments muestra el mensaje de commit y hash corto, la rama, el estado, cuándo se implementó, y quién lo envió. El activo lleva la insignia CURRENT.
Generalmente desea el deployment inmediatamente anterior al que causó el problema. Dos cosas le ayudan a estar seguro:
- Compare. Abra el deployment sospechoso y haga clic en Compare para compararlo con el anterior: tiempo de compilación, tamaño del artefacto, estado de caché, framework, y la diferencia de artefacto a nivel de archivo.
- Deployment notes. Cualquier deployment puede llevar una nota de hasta 500 caracteres. Agregar "hotfix for payment bug" o "feature flag X on" en el momento no cuesta nada y hace que el historial sea legible meses después, que es exactamente cuando lo necesita.
Revertir a un artefacto no revierte sus variables de entorno, reglas de redirección o encabezados de respuesta. Esos se leen en el momento de la solicitud o la compilación, no se cocinan en el artefacto. Si el incidente fue causado por un cambio de configuración en lugar de un cambio de código, revertir el código no lo arreglará. La página de detalle del deployment compara las variables que fueron inyectadas en tiempo de compilación con su configuración actual, que es la forma más rápida de distinguir los dos.
Reversión automática
Orbit puede hacer esto por usted antes de que ni siquiera lo haya notado. Las tres configuraciones están en Settings.
Auto-Rollback al fallar
Bajo Runtime, active Auto-rollback on failure. Si un deploy de producción falla, el último deployment sano es restaurado automáticamente y los visitantes no ven tiempo de inactividad. Staging tiene un toggle equivalente propio.
Health Check
Bajo Health check, establezca una Health check path, por ejemplo / o /api/health. Después de cada deploy de producción, Orbit obtiene esa ruta. Si no devuelve una respuesta 2xx dentro de 15 segundos, el deployment sano anterior es restaurado.
Smoke Tests
Bajo Smoke tests, enumere hasta 10 rutas separadas por comas, por ejemplo /,/blog,/api/health. Después de cada deploy exitoso, Orbit envía un GET a cada una y registra aprobación o fallo. Si alguno falla y la reversión automática está habilitada, el deployment anterior es restaurado. El resultado aparece en la página de deployment como Smoke tests passed o un número de fallos, y dice Triggered rollback cuando causó uno.
Un health check en una ruta que realmente ejercita su base de datos vale mucho más que uno en la página de inicio. Un deploy roto que aún sirve una página de inicio en caché pasará una verificación / y fallará una real.
Reversión versus Deploy Lock
Si no está listo para revertir pero desea evitar que algo nuevo se implemente mientras investiga, bloquee los deploys en su lugar:
- Abra el proyecto.
- Haga clic en Lock deploys.
- Agregue una razón, por ejemplo "investigating production issue".
Los deploys activados por push son entonces silenciosamente omitidos, y un banner lee Production deploys are locked con su razón. Los deploys manuales aún funcionan, lo cual es deliberado: el bloqueo evita deploys accidentales, no la corrección que está enviando. Haga clic en Unlock deploys para levantarlo.
Un bloqueo y una reversión funcionan bien juntos. Revierta primero para restaurar el servicio, luego bloquee para que el merge rutinario de nadie lo deshaga mientras está diagnosticando.
Promoción de staging a producción
Si ejecuta un entorno de staging, puede poner una compilación de staging probada en producción sin enviar nada.
- Abra la descripción general del proyecto y encuentre la sección Staging.
- Si staging está por delante de production, aparece Promote to production.
- Haga clic y confirme.
Lea la confirmación cuidadosamente, porque hay dos comportamientos de promoción diferentes en Orbit y no son intercambiables. Promocionar desde la descripción general del proyecto activa una fresh production build at the same commit, usando variables de entorno de producción y comandos de compilación de producción. El artefacto de staging no es reutilizado. Promocionar un deployment de staging específico desde su página de detalle indica claramente que la compilación de staging se pone en línea inmediatamente sin una recompilación. Si sus variables de entorno de staging y producción difieren, el primer camino producirá un artefacto diferente del que probó.
Orbit también puede promocionar por usted. Auto-promote staging en Settings promociona staging a producción después de un número de horas de staging sano con smoke tests pasando, verificado cada 15 minutos.
Después de una reversión
Corrija el problema subyacente en su repositorio e introduzca un nuevo commit. Esto activa una compilación normal que se convierte en la nueva versión activa. Si bloqueó deploys, desbloquéelos primero, o el push será omitido.
La pestaña Activity del proyecto registra la reversión junto con todo lo demás que sucedió, por lo que hay un rastro de auditoría de quién revirtió qué y cuándo.
Qué limita cuán lejos atrás puede ir
La reversión necesita que el artefacto aún exista. Dos configuraciones controlan eso:
- La ventana del historial de deployment de su plan: 7 días en Launch, 30 en Liftoff, 90 en Apex.
- La configuración Artifact retention del proyecto, que mantiene un número de artefactos exitosos por entorno, de 10 a 500, siendo por defecto 50.
El artefacto del deployment actualmente activo siempre se mantiene independientemente de ambos.
Si implementa muchas veces al día, el contador de artefactos es el límite que golpeará primero, no el contador de días. Cincuenta deployments pueden ser una sola semana. Aumente Artifact retention en lugar de descubrir el techo durante un incidente.