« Ajouter une colonne » correspond à une migration d’une seule ligne. L’estimation ne concerne pas la colonne.

Les migrations de schéma s’effectuent selon deux cadences. L’une est celle du SQL — généralement rapide, généralement mécanique. L’autre est le cadran opérationnel : combien de temps la table est-elle verrouillée, comment le processus se comporte-t-il en cas d’écritures simultanées, comment revenir en arrière en cas d’échec, et quel est le plan d’urgence si l’opération dure plus longtemps que la fenêtre de déploiement ? L’équipe se prononce sur le code SQL, car c’est ce qui figure sur le ticket. Le travail s’effectue quant à lui selon le deuxième cadran.

Sur une petite table, les deux horloges sont identiques et l’histoire est vraiment insignifiante. Sur toute table qui compte, ce n’est pas le cas. L’estimation doit tenir compte du remblayage, de la stratégie de déploiement et de la procédure de retour en arrière, que quelqu’un doit avoir répétées avant que le déploiement ne s’approche ne serait-ce qu’un peu de l’environnement de production.

Ce qui se dit dans la salle

Backend : « Ce n’est qu’une instruction ALTER, la migration s’exécute en une seconde. »

SRE : « Sur le tableau des commandes ? Avec les verrous enclenchés ? À 15 h ? »

DBA : « Comment procédons-nous pour compléter les lignes existantes ? »

SRE : « Quelle est la procédure de restauration si le déploiement échoue à mi-parcours ? »

Point clé : « Le chemin de lecture tolère-t-il que la colonne soit nulle pendant une heure ? »

Questions qu’il convient de se poser avant de voter

  • Quelle est la taille de la table : des milliers, des millions ou des centaines de millions de lignes ?
  • Outil de migration en ligne ou commande ALTER sur place ?
  • Stratégie de remplissage : synchrone, par lots, double écriture ?
  • Quel est le rôle du chemin de lecture pendant la période de déploiement ?
  • Rétroactivité : évolution unidirectionnelle, ou peut-on revenir en arrière sur le schéma ?
  • Quelqu’un a-t-il suivi le guide d’intervention pour cette migration ?

Si la moitié de l’assemblée vote pour « le SQL » et l’autre moitié pour « le déploiement », vous n’avez pas un problème de chiffrage ; vous avez deux cas de figure présentés comme un seul. Séparez-les : la modification du schéma constitue un ticket, tandis que le plan de mise à jour rétrospective et de déploiement en constitue un autre.

Évaluez le déploiement et la restauration, et non l’opération ALTER. C’est lors de la deuxième étape que réside le risque.

Consultez la page « Estimation d’une migration de données » pour la variante inter-systèmes, ainsi que les autres exemples d’estimations concrets. Lancez une session gratuite de Planning Poker une fois que le déploiement a été esquissé.