Fijación y actualización de versiones del navegador
Planifica actualizaciones de navegador y driver con versiones fijadas, evidencia de compatibilidad y rollback.
Quieres la documentación estructurada de Primeros pasos?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
Una automatización repetible trata navegador, driver, framework, perfil y aplicación como un conjunto probado. Una etiqueta mutable no demuestra qué binario usó el worker. Fija las entradas, registra las versiones resueltas y evalúa cada actualización como una comparación con rollback definido. La guía de validación de releases cubre comprobaciones generales; la integración de perfiles Selenium cubre la propiedad del perfil; aquí se delimita la propiedad de la actualización.
Contrato de release
Define la ruta, cuenta sintética, resultado visible, sistemas soportados y capacidades necesarias. Indica qué familias de navegador y driver son compatibles, cómo se evalúa un parche y qué evidencia permite promoverlo. Registra también la versión de aplicación y framework.
Usa referencias inmutables: digest, lockfile o identificador de artefacto. Resuelve una vez al comenzar el job. Un reintento conserva el mismo conjunto o se marca como nuevo candidato.
Matriz de versiones y propietarios
| Entrada | Registro | Propietario | Evidencia | Rollback |
|---|---|---|---|---|
| Binario | artefacto y versión | plataforma | journey limpio | restaurar binario |
| Driver | familia compatible | automatización | negociación | restaurar driver |
| Framework | lockfile y runtime | pruebas | fixture y aserción | restaurar lockfile |
| Estado | esquema y baseline | escenario | carga y expiración | baseline anterior |
| Aplicación | identificador de build | aplicación | resultado visible | redeploy conocido |
La evidencia de un smoke test solo cubre su journey. No certifica todos los orígenes, extensiones ni modos de dispositivo.
Fijar el conjunto y probar candidatos
Un pin de navegador sin driver puede cambiar el protocolo. Un sistema operativo distinto altera certificados, fuentes o permisos. Registra todas las entradas materiales y separa artefactos inmutables de datos sintéticos mutables.
Promueve primero en una lane de candidato. Ejecuta baseline y candidato con la misma entrada, cambia una versión cada vez y compara estado visible, navegación, permisos y limpieza. Un comportamiento alternativo documentado puede ser una variación soportada; una capacidad requerida ausente bloquea.
Actualización y cadencia
Un parche de seguridad puede tener una revisión más corta que un cambio mayor, pero ambos registran la versión resuelta y ejecutan la fixture. Las dependencias flotantes pueden cambiar esperas o protocolo; bloquea el grafo y revisa sus actualizaciones por separado.
Tabla de decisión de actualización
| Observación | Categoría | Decisión | Seguimiento |
|---|---|---|---|
| Contrato igual | compatible | promover con revisión | conservar recibos |
| Alternativa documentada | variación | promover si es aceptable | revisar accesibilidad |
| Driver no negocia | incompatible | bloquear | alinear o restaurar |
| Journey pasa, limpieza falla | infraestructura | detener | conservar errores |
| Timeout tras mutación | incierto | no repetir a ciegas | consultar estado |
Fixture de fallo
import os from 'node:os';
import path from 'node:path';
import { mkdtemp, rm } from 'node:fs/promises';
import { chromium } from 'playwright';
import { expect } from '@playwright/test';
const dir = await mkdtemp(path.join(os.tmpdir(), 'release-pin-'));
const browser = await chromium.launch({ headless: true });
const context = await browser.newContext({ baseURL: 'http://release.test' });
const page = await context.newPage();
await page.route('/fixtures/missing-readiness', route =>
route.fulfill({ status: 200, contentType: 'text/html', body: '<main><p>Candidato</p></main>' })
);
let failure;
const remember = (label, error) => {
const current = new Error(`${label}: ${error.message}`, { cause: error });
failure = failure ? new AggregateError([failure, current], `${failure.message}; ${label} failed`) : current;
};
try {
await page.goto('/fixtures/missing-readiness');
await expect(page.getByRole('status')).toHaveText('Ready', { timeout: 250 });
} catch (error) {
remember('aserción de readiness', error);
} finally {
try {
await context.close();
} catch (error) {
remember('cierre de contexto', error);
}
try {
await rm(dir, { recursive: true, force: true });
} catch (error) {
remember('limpieza de artefacto', error);
}
try {
await browser.close();
} catch (error) {
remember('cierre de navegador', error);
}
}
if (failure) throw failure;
El resultado esperado nombra la señal ausente. No se prueba otro origen ni se repite hasta que pase. Una mutación que agotó el tiempo requiere consultar el estado del servicio.
Cadencia de actualización
Un parche de seguridad puede tener una revisión más corta que un cambio mayor, pero ambos registran la versión resuelta y ejecutan la fixture.
Rollback y política de actualización
Rollback restaura el conjunto completo: binario, driver, framework, esquema y build. Ensáyalo en una lane desechable y conserva el baseline sintético. Si el binario anterior no está disponible, el release no está listo para rollback.
Un parche de seguridad puede tener una revisión más corta que un cambio mayor, pero ambos registran la versión resuelta y ejecutan la fixture. Las dependencias flotantes pueden cambiar esperas o protocolo; bloquea el grafo y revisa sus actualizaciones por separado.
Evidencia y límites
Un recibo contiene versiones, imagen del sistema, escenario, resultado visible, alternativa y limpieza. No contiene cookies, headers, texto personal ni respuestas completas. El runner observa el límite del cliente; no demuestra retención del servidor.
Capacidad y límite de BotBrowser
BotBrowser ofrece configuración controlada y BrowserContexts aislados para comparar releases autorizados desde un estado sintético conocido; consulta la documentación de aislamiento multi-cuenta. No elige drivers, fija dependencias, certifica builds ni garantiza paridad entre sistemas.
BotBrowser admite entradas de navegador fijadas para una comparación controlada, pero no garantiza compatibilidad del driver, de la aplicación ni entre sistemas.
Para un release fijado, BotBrowser puede mantener estable la configuración del navegador durante la comparación, pero no decide si el driver o el build son compatibles.
Conserva inmutable el recibo baseline con artefacto, driver, lockfile, imagen y build.
Un parche puede cambiar protocolo, certificados, renderizado o políticas aunque parezca pequeño.
Clasifica el fallo por frontera: lanzamiento, permisos, resultado visible o infraestructura.
Registra una decisión explícita de promover, detener, rollback o investigar.
Ensaya rollback verificando artefacto, driver, schema y journey sintético.
No aumentes esperas para ocultar drift de release.
Mantén ruta, datos sintéticos, proxy y retención constantes durante la comparación.
Una excepción de plataforma necesita lane, propietario y fecha de caducidad.
Registra dependencias que el runner no puede fijar.
Conserva metadatos y artefactos sintéticos aprobados durante la ventana de comparación.
Registra la referencia solicitada y la identidad resuelta: versión, digest, build del driver, identificador inmutable del lockfile y build de la aplicación.
Mantén el lane candidato separado del lane predeterminado para que un reintento no sustituya el baseline.
La decisión debe indicar condición observada, clasificación, propietario y siguiente acción.
Prueba que el worker nuevo puede iniciar hoy con el conjunto anterior antes de aprobar el candidato.
Una referencia antigua en el manifiesto no basta si el artefacto o el driver ya no están disponibles.
Trata un cambio de schema o build durante rollback como un nuevo conjunto de release.
Define qué comprobaciones adicionales requiere un cambio minor o major antes de iniciarlo.
Anota dependencias que el runner no puede fijar, como imágenes base o descubrimiento del driver.
Concede a cada override de emergencia propietario, motivo, hora de inicio y vencimiento.
Revisa el recibo con el propietario del journey y quien pueda aprobar rollback.
Separa artefactos candidatos y baseline.
Una capacidad ausente sigue visible aunque la aserción sea correcta.
Consulta el servicio tras un timeout que pudo mutar datos.
Cerrar el contexto no demuestra eliminación en el servidor.
Asigna vencimiento a cada excepción de plataforma.
Repite el journey limpio después de restaurar.
Revisa el recibo con el propietario del journey.
Mantén el baseline inmutable durante la ventana.
Fuentes
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.