strangler-fig-method

Remplace un composant en faisant grandir une nouvelle implémentation à côté de l’ancienne, derrière une façade qui route le trafic, tranche par tranche, jusqu’à ce que l’ancienne n’ait plus d’appelant et puisse être supprimée.

Quand l’utiliser

Précondition

Même filet de sécurité vert que Mikado (characterize-with-contracts) — ici rejoué contre l’ANCIENNE et la NOUVELLE implémentation ; une tranche ne cutover que si NEW est équivalente au contrat de OLD sur chaque test du harness.

Procédure (résumé)

  1. Façade — introduire (ou confirmer) un seam de routage ; sinon la façade est la tranche zéro (transparente, vérifiée contre OLD seul)
  2. Slice — partitionner le contrat en tranches indépendamment cutover-ables (défaut : une par endpoint)
  3. Build NEW — implémenter une tranche, rejouer les mêmes tests de caractérisation contre NEW (équivalence de contrat)
  4. Cutover gate (S4) — cutover seulement si tests NEW passent (mêmes assertions que OLD) ET harness complet vert
  5. Strangle — répéter ; quand OLD est injoignable, supprimer OLD + branche OLD de la façade (tranche finale)

Contrat de sortie

Invariants

Pourquoi cette forme

La façade contient le rayon d’explosion : chaque tranche cutover indépendamment, avec un rollback fin, et l’équivalence de contrat est vérifiée par les mêmes tests contre les deux implémentations.

« Gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled. » — Fowler, M., Bliki: StranglerFigApplication, 2004.

Customisation autorisée

Voir aussi