Despliegue y versión del navegador: mapa operativo

El despliegue de un navegador es un orden de revisión, no una lista de indicadores. Este hub conecta el grupo de despliegue y añade un registro de versión acotado con la decisión de capacidad, la elección de compilación, el resultado de validación y la ruta de reversión, empezando por Validación de versiones del navegador.

BotBrowser soporta ejecutar un perfil autorizado en contenedores y servidores de larga duración y puede mantener los valores visibles del navegador coherentes con ese perfil; no puede dimensionar tu infraestructura, garantizar una compilación de proveedor ni decidir si una versión es aceptable para tu producto, y no sustituye tus propias pruebas de capacidad y reversión.

Resumen

• Decide la capacidad por la concurrencia medida, no por el número más alto que una máquina sobrevivió una vez.
• Fija la compilación del navegador y la clase de perfil en el mismo registro que la versión.
• Valida en la clase de máquina que realmente ejecutará la carga.
• Publica con una ruta de reversión y la evidencia que hizo revisable la decisión.

Contenido

• Las cuatro superficies de despliegue
• Recorrer el grupo de despliegue
• Ejecutar una revisión de versión
• Registro y alcance de la versión
• Gestionar el primer fallo
• Conclusión práctica

Las cuatro superficies de despliegue

Un despliegue de navegador tiene cuatro superficies operativas. La capacidad cubre cuántos contextos soporta una máquina, cómo se reclama la memoria y qué límites se midieron en lugar de suponerse. La elección de compilación cubre el paquete que instalas: edición estándar o recortada, plataforma objetivo y la pila de controladores que hay detrás. La validación de versión cubre qué se comprobó antes de mover tráfico: el perfil carga, las páginas renderizan y las interacciones se comportan. La evidencia y la reversión cubren lo que queda tras la versión: el registro que explica la decisión y el camino de vuelta a la compilación anterior.

La capacidad también depende del presupuesto de contextos descrito en Planificación de capacidad de BrowserContext, así que lee ambos antes de publicar una cifra de concurrencia.

Estas superficies fallan de maneras distintas y en relojes distintos. Un límite de capacidad aparece bajo carga sostenida, a menudo horas después de la primera petición correcta. Una elección de compilación aparece como una biblioteca que falta o una ruta de renderizado que el contenedor no ofrece. Un hueco de validación aparece como una interacción que funcionaba en el laboratorio y falla en producción. Una ruta de reversión ausente convierte una versión mala y recuperable en una caída que dura tanto como el diagnóstico.

El papel de BotBrowser es mantener la identidad visible del navegador coherente con el perfil declarado en esos contextos. Esa coherencia hace atribuible una diferencia: si dos contenedores con el mismo perfil discrepan, la superficie de despliegue es la causa probable y no una variable sin control.

Recorrer el grupo de despliegue

• Validación de versiones del navegador fija qué perfiles, versiones y estados de reversión se comprueban antes de publicar.
• Automatización en Docker cubre una base de contenedor reproducible.
• Configurar Chrome sin interfaz en Ubuntu cubre los requisitos del servidor.
• Edición estándar o recortada en Linux x64 compara las dos ediciones empaquetadas.
• Mesa llvmpipe frente a SwiftShader cubre la elección de backend de renderizado en Linux.
• Escalar contextos de navegador cubre perfiles por contexto a escala.
• Planificación de capacidad de BrowserContext convierte mediciones de memoria en un presupuesto de contextos.
• Límites de recursos del contenedor trata CPU, memoria y disco juntos.
• Rendimiento de la automatización cubre el coste de ejecución de una carga.
• Captura de pantalla fiable cubre la salida que produce este tipo de despliegue.

El hub posee el orden y la forma del registro. Cada artículo enlazado posee el detalle de su superficie y el fallo que puede producir.

Ejecutar una revisión de versión

Escribe las entradas declaradas antes de medir nada: la clase de máquina, la compilación del navegador, la clase de perfil, la concurrencia esperada y la carga que piensas ejecutar. Después registra una fila por superficie en la misma revisión, para que una diferencia posterior tenga un punto de referencia.

{
  "runId": "deploy-review-20261019-01",
  "declared": {
    "hostClass": "8 vCPU / 16 GB",
    "browserBuild": "standard-linux-x64",
    "profileClass": "fresh-temporary",
    "expectedConcurrency": 24
  },
  "observed": {
    "capacity": "24-contexts-stable-30min",
    "build": "profile-loaded-renderer-recorded",
    "validation": "owned-fixture-passed",
    "rollback": "previous-build-redeployable"
  },
  "firstFailure": null,
  "testedOn": "2026-10-19"
}

El registro son datos, no un informe. Debe ser lo bastante corto para adjuntarlo a un hilo de incidente y lo bastante explícito para que otra persona repita las mismas cuatro filas en la misma clase de máquina. Rellénalo durante la revisión, no después: un registro escrito de memoria tiende a describir la configuración prevista y no la que la máquina ejecutó de verdad.

Elegir la compilación y el backend con criterio

de renderizado son decisiones separadas, y cada una cambia lo que el despliegue puede hacer. La edición estándar trae la pila de renderizado completa; la recortada reduce el paquete y su superficie de ataque y puede ser la elección correcta para una carga estrecha. Ninguna es universalmente más rápida en producción: el rendimiento depende de las páginas que cargas y de la ruta que siguen.

En Linux el backend gráfico decide si las páginas se renderizan por un rasterizador de software como llvmpipe o por una ruta con hardware seleccionada con --use-angle. La renderización por software está disponible en máquinas sin GPU, algo común en contenedores, y se comporta distinto en WebGL, canvas y fuentes. Registra qué backend usó el despliegue y mantenlo estable entre versiones. Un cambio de backend entre dos compilaciones idénticas en todo lo demás es un cambio de renderizado y pertenece a la nota de versión.

Compara las dos ediciones y los dos backends en la carga que realmente ejecutas, en la clase de máquina que realmente despliegas. Una comparación hecha en un portátil responde a otra pregunta. Cuando la comparación está reñida, prefiere la configuración con la reversión más simple: un redespliegue de dos minutos vale más que una pequeña diferencia de rendimiento.

Planificar la máquina antes de la primera petición

La mayoría de los despliegues de navegador fallan en la máquina mucho antes de fallar en el navegador. Un contenedor que arranca limpio puede quedarse sin memoria compartida, agotar descriptores de archivo o chocar con una cuota de disco durante una ráfaga de capturas. Revisar esos límites juntos convierte un éxito puntual en un despliegue repetible.

Define el límite de memoria del contenedor a partir del conjunto de trabajo medido de un contexto, multiplícalo por la concurrencia que realmente piensas ejecutar y añade el coste del proceso del navegador medido en la misma clase de máquina. No uses el mínimo anunciado por el proveedor como techo: es un piso para arrancar, no un número que refleje tu carga. Una tarea de conversión con búferes grandes y una tarea de capturas con muchas páginas abiertas dan cifras distintas en la misma máquina.

Da al navegador un área de memoria compartida escribible, por ejemplo --shm-size=1g, y confírmala con df -h /dev/shm dentro del contenedor. El tamaño por defecto de /dev/shm en muchos runtimes de contenedor es pequeño, y un navegador que no consigue memoria compartida suficiente acaba terminando procesos de renderizado bajo carga en vez de al arrancar. Fija el tamaño explícitamente, anota el valor en el registro y vuelve a comprobarlo cuando cambie la imagen base. Lo mismo vale para el almacenamiento temporal: el navegador escribe cachés y datos de sesión, y un sistema de archivos de solo lectura falla de formas que parecen errores de la aplicación.

Vigila también los descriptores de archivo y los límites de procesos. Cada contexto, cada worker y cada página grande pueden retener varios descriptores, y un límite generoso en el laboratorio se vuelve estrecho cuando el mismo contenedor lleva el doble de tráfico. Anota el límite que fijaste, no el que heredaste.

Registro y alcance de la versión

Una revisión de incidente hace cuatro preguntas: qué se desplegó, dónde, con qué perfil y qué cambió desde la última versión buena. Un registro que responda las cuatro ahorra la primera hora de investigación. No necesita ser elaborado; necesita la clase de máquina, la compilación, la clase de perfil, la concurrencia, la versión del fixture y el resultado de validación, en un solo lugar y con fecha.

Guarda el registro junto a docs/blog-release-batches.json y no en un hilo de chat. Al preparar la siguiente versión, comparar los dos registros muestra exactamente qué entradas cambiaron, y esa comparación suele ser la vía más rápida a la causa de una regresión. Un registro pegado en un ticket no se puede comparar con nada, mientras que dos archivos se comparan línea a línea.

Decide la ventana de retención con el responsable de producto, normalmente ligada a supportWindow. Un registro que explica una versión es útil durante su ventana de soporte, por ejemplo retentionDays: 90; conservarlo para siempre convierte el almacén en ruido. Basta una nota corta con la versión, el motivo y la fecha de retirada.

La revisión de versión es también el lugar donde se decide qué puede afirmar el despliegue. Si corre en una máquina compartida con vecinos ruidosos, la cifra de capacidad es un límite inferior y no una garantía, y el registro debe decirlo junto a hostClass. Si usa un volumen gestionado, el primer minuto de E/S no es representativo. Escribir esas restricciones en el registro evita que una queja de rendimiento posterior se convierta en una discusión sobre medición.

Trata la primera ventana de producción como parte de la validación, no como un trámite posterior. Observa las mismas cuatro filas que registraste: capacidad, compilación, validación y preparación de reversión. Una versión que pasa en el laboratorio y degrada en la primera hora no es una versión fallida, sino una versión cuya fila de capacidad se midió durante demasiado poco tiempo. La corrección es una medición más larga, no una máquina mayor, hasta que la curva diga otra cosa.

Cuando cambia la carga, repite la revisión en lugar de extrapolar. Un nuevo tipo de página, una subida mayor o una pestaña adicional cambian el conjunto de trabajo y el número de descriptores, y la cifra anterior ya no describe el despliegue. Extrapolar desde una carga parecida es cómo un contenedor que llevaba veinte contextos el trimestre pasado falla con doce en este.

Separa el registro de despliegue del registro de incidente aunque citen la misma versión. El de despliegue dice qué se pretendía y qué se midió; el de incidente dice qué ocurrió y qué se decidió. Mezclarlos hace que una decisión de versión parezca un juicio posterior al incidente y oculta que la versión se revisó antes.

Revisa el despliegue tras la primera semana tranquila, no solo después de un fallo. Un despliegue que se quedó dentro de su fila de capacidad merece el mismo registro que uno que necesitó reversión, porque el siguiente revisor necesita una base de comparación. Una historia hecha solo de incidentes no muestra cómo se ve una versión normal en esta clase de máquina, así que guarda las versiones tranquilas en la misma lista singleReleases.

Gestionar el primer fallo

Si el perfil no carga, detente: las filas siguientes describen un navegador que no ejecuta el perfil declarado. Si la página renderiza pero la interacción falla, revisa la versión del fixture y la pila de controladores antes que la máquina. Si la interacción pasa y la salida difiere, compara el backend de renderizado y la clase de perfil. Si todo pasa y la máquina sigue reportando presión, trátalo como hallazgo de capacidad y vuelve a medir con menos concurrencia antes de cambiar otra cosa.

Nombra la superficie responsable, conserva el registro y cambia una entrada declarada por reintento. Una revisión de despliegue que termina con un fallo nombrado es más útil que otra con una docena de observaciones sin dueño, y ese fallo nombrado también acorta la siguiente revisión.

Conclusión práctica

Un despliegue de navegador es revisable cuando su capacidad, su compilación, su validación y su reversión se registran juntos. Usa este hub para ordenar la revisión y el grupo para el detalle, y limita cada conclusión a la clase de máquina, la compilación y el perfil que la produjeron.

Fuentes

• MDN: intercambio de recursos de origen cruzado y notas de despliegue en contenedores
• W3C: pautas de accesibilidad para el contenido web
• WHATWG: estándar HTML, workers
• Documentación de BotBrowser: despliegue
• Documentación de BotBrowser: formatos de perfil