Estimation d'une migration de base de données

« 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 cycle 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 cycle.

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 la table des commandes ? Avec les verrous activés ? À 15 h ? »

DBA : « Comment procédons-nous pour remplir 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, 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 fenêtre de déploiement ?
• Rétroactivité : évolution unidirectionnelle, ou est-il possible de 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 », ce n’est pas un problème de chiffres ; ce sont deux cas de figure qui se font passer pour 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 section consacrée à l’estimation d’une migration de données pour la variante inter-systèmes, ainsi que les autres exemples d’estimation concrets. Lancez une session gratuite de « planning poker » une fois que le déploiement aura été esquissé.