Épingler et mettre à jour les versions du navigateur

Une automatisation reproductible traite navigateur, driver, framework, profil et application comme un ensemble testé. Une étiquette mutable ne prouve pas quel binaire a été utilisé. Épinglez les entrées, notez les versions résolues et comparez chaque mise à jour avec un rollback défini. Le guide de validation des releases couvre la vérification générale; le guide d’intégration des profils Selenium couvre la propriété du profil; cet article précise la propriété de l’update.

Contrat de release

Définissez route, compte synthétique, résultat visible, systèmes supportés et capacités nécessaires. Indiquez les familles navigateur/driver, la politique de patch et la preuve de promotion. Notez aussi les versions application et framework.

Utilisez digest, lockfile ou identifiant d’artefact. Résolvez-le au début du job. Une reprise conserve le même ensemble ou devient une nouvelle tentative candidate.

Matrice des versions

Entrée	Trace	Propriétaire	Preuve	Rollback
Binaire	artefact/version	plateforme	parcours propre	restaurer
Driver	famille compatible	automatisation	négociation	restaurer
Framework	lockfile/runtime	tests	fixture/assertion	lockfile précédent
État	schéma/baseline	scénario	chargement/expiration	baseline précédent
Application	identifiant build	application	résultat visible	redeploy connu

Un smoke test ne couvre que son parcours, pas tous les origins, extensions ou modes.

Épinglez et comparez le candidat

Un navigateur épinglé sans driver peut changer le protocole. Un système différent modifie certificats, polices et permissions. Notez les entrées matérielles et séparez artefacts immuables et données synthétiques.

Exécutez baseline et candidat avec la même entrée, une seule version à la fois. Comparez état visible, navigation, autorisations et nettoyage. Une alternative documentée est une variation; une capacité requise absente bloque.

Mises à jour candidates

Promouvez une mise à jour depuis une lane candidate avec le même scénario synthétique, la même image système et la même politique de proxy. Notez la référence demandée et l’identité résolue avant le lancement.

Tableau de décision

Observation	Catégorie	Décision	Suite
Contrat identique	compatible	promouvoir après revue	garder les reçus
Alternative documentée	variation	promouvoir si accepté	vérifier accessibilité
Négociation impossible	incompatible	bloquer	aligner ou restaurer
Parcours réussi, nettoyage échoué	infrastructure	retenir	garder les erreurs
Timeout après mutation	incertain	ne pas répéter aveuglément	consulter le statut

Fixture d’échec

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>Candidat</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('assertion fixture', error);
} finally {
  try {
    await context.close();
  } catch (error) {
    remember('fermeture contexte', error);
  }
  try {
    await rm(dir, { recursive: true, force: true });
  } catch (error) {
    remember('nettoyage artefact', error);
  }
  try {
    await browser.close();
  } catch (error) {
    remember('fermeture navigateur', error);
  }
}
if (failure) throw failure;

Le résultat attendu nomme le signal absent; il ne teste pas une autre origine. Une mutation expirée exige le statut du service.

Cadence de mise à jour

Un patch de sécurité peut être examiné plus vite qu’un changement majeur, mais chacun enregistre la version et exécute la fixture. Bloquez les dépendances flottantes et examinez leurs changements séparément.

Rollback et cadence

Le rollback restaure binaire, driver, framework, schéma et build. Répétez-le dans une lane jetable avec une baseline synthétique. Sans ancien binaire disponible, le release n’est pas prêt.

Un patch de sécurité peut être plus rapide qu’un changement majeur, mais chacun note la version et exécute la fixture. Bloquez les dépendances flottantes et examinez leurs mises à jour séparément.

Preuves et limites

Le reçu contient versions, image système, scénario, résultat visible, alternative et nettoyage. Il n’inclut ni cookies ni texte personnel. Le runner observe la frontière client et ne prouve pas la rétention serveur.

Capacité et limite BotBrowser

BotBrowser fournit une configuration contrôlée et des BrowserContexts isolés pour comparer des releases autorisés; voir la documentation d’isolement multi-compte. Il ne choisit pas les drivers, ne fixe pas les dépendances, ne certifie pas un build et ne garantit pas la parité entre systèmes.

BotBrowser prend en charge des entrées navigateur épinglées pour une comparaison contrôlée, mais ne garantit ni la compatibilité du driver, ni celle de l’application ou des systèmes.

Pour une release épinglée, BotBrowser peut garder la configuration navigateur stable pendant la comparaison, mais il ne décide pas de la compatibilité du driver ou du build.

Conservez le reçu baseline avec artefact, driver, lockfile, image et build.

Un patch peut modifier protocole, certificats, rendu ou politiques malgré son faible numéro.

Classez l’échec par frontière : lancement, permissions, résultat visible ou infrastructure.

Notez une décision explicite : promouvoir, retenir, rollback ou investiguer.

Répétez le rollback en vérifiant artefact, driver, schéma et parcours synthétique.

N’allongez pas les attentes pour cacher un drift de release.

Gardez route, données synthétiques, proxy et rétention constants.

Une exception de plateforme doit avoir lane, propriétaire et échéance.

Notez les dépendances que le runner ne peut pas épingler.

Conservez seulement métadonnées et artefacts synthétiques autorisés pendant la fenêtre.

Conservez les identifiants résolus pour reproduire le worker exact.

Comparez une seule entrée de release à la fois.

Séparez les artefacts candidats des artefacts de référence.

Une capacité manquante doit rester visible malgré une assertion verte.

Le statut du service est requis après un timeout qui a pu muter une donnée.

La fermeture du contexte ne prouve pas la suppression côté serveur.

Attribuez une échéance à toute exception de plateforme.

Réexécutez le parcours propre après une restauration.

Conservez les identifiants résolus pour reproduire le worker exact.

Comparez une seule entrée de release à la fois.

Séparez les artefacts candidats de la baseline.

Une capacité manquante reste visible malgré une assertion verte.

Consultez le service après un timeout qui a pu muter une donnée.

La fermeture du contexte ne prouve pas la suppression serveur.

Attribuez une échéance à chaque exception de plateforme.

Réexécutez le parcours propre après restauration.

Relisez le reçu avec le propriétaire du parcours.

Gardez la baseline immuable pendant la fenêtre.

Sources

• Playwright : bonnes pratiques
• OWASP : Web Security Testing Guide
• BotBrowser : isolement multi-compte