Estimation d'une migration de données

La migration en elle-même est la partie la plus simple. C’est lors de l’étape de rapprochement, que vous avez oubliée, que se cachent les difficultés.

Une migration de données (le transfert de données d’un système à un autre, ou d’un modèle à un autre au sein d’un même système) s’apparente à une transformation. Lecture à partir de la source, transformation, écriture dans la destination, basculement du trafic. L’équipe se prononce sur la transformation. Celle-ci constitue généralement la tâche la plus simple de l’itération. Les difficultés résident dans ce que la transformation ne perçoit pas : des enregistrements qui semblent corrects mais font référence à des données qui n’ont pas été transférées, des enregistrements qui semblent erronés mais qui sont en réalité corrects d’une manière que le cahier des charges n’a pas prise en compte, des cas limites qui n’ont survécu que parce que l’ancien système les tolérait, ce qui n’est pas le cas du nouveau.

Il s’agit d’un problème différent de celui de la migration de base de données. Une migration de schéma modifie la structure d’une base de données contenant déjà des données. Une migration de données transfère des données d’un système à un autre, et la question n’est pas « l’instruction ALTER sera-t-elle terminée à temps ? », mais « que faire des lignes qui ne correspondent à aucun des deux côtés ? ». L’essentiel du travail consiste en un rapprochement des données, l’élaboration d’une stratégie de basculement et la restauration. Le code de transformation est la partie que vous écrivez le plus rapidement et que vous terminez en dernier.

Ce qui se dit dans la salle

Backend : « C’est un script. Lecture, mise en correspondance, écriture. Deux jours maximum. »

Data eng : « Avez-vous vérifié à quel point la source est erronée ? »

SRE : « Quelle méthode de basculement allez-vous utiliser : le « big bang » ou la double écriture ? »

Chapeau : « Qui se charge de harmoniser les lignes qui ne sont pas correctement transférées ? »

Premier ministre : « À quelle date allons-nous mettre fin à l’ancien système ? »

C’est la question posée par le Premier ministre qui doit guider l’estimation. Si l’ancien système disparaît dans un mois, vous avez besoin d’une stratégie garantissant une exactitude à 100 % ; s’il continue de coexister avec le nouveau pendant deux trimestres, vous pouvez vous permettre de remettre la « longue traîne » à plus tard. L’estimation ne porte pas sur la transformation, mais sur la stratégie.

Questions qu’il convient de se poser avant de voter

• Quelle est la qualité des données sources : propres, erronées ou inconnue ?
• Stratégie de migration : « big bang », double écriture, lecture en mode « shadow », progressive ?
• Pendant combien de temps ces deux systèmes coexisteront-ils ? Y a-t-il une date butoir ?
• Qui se charge de résoudre les problèmes liés aux lignes qui ne sont pas correctement transférées, et à partir de quel seuil ?
• Quelle serait la procédure de restauration si le nouveau système recevait des données erronées après la migration ?
• Existe-t-il des consommateurs en aval (rapports, intégrations) qui doivent être migrés de manière synchronisée ?

Si l’équipe attribue une note de 5 et que quelqu’un s’exclame « Attendez, qu’en est-il des enregistrements du journal d’audit ? », ce n’est pas que vous ayez eu un problème d’estimation ; c’est que vous aviez deux stories présentées comme une seule. Séparez-les : la transformation constitue un ticket, tandis que le plan de rapprochement et de basculement en constitue un autre.

Votez sur la stratégie, pas sur la transformation. La transformation dure deux jours. La stratégie, c’est le trimestre.

Consultez la page « Estimation d’une migration de base de données » pour la variante de modification de schéma sur un seul système, ainsi que les autres « exemples d’estimations concrètes ». Lancez une session de Planning Poker gratuite une fois que la stratégie de basculement a été esquissée.