Certes. Mais le problème de la méthode manuelle, c’est la partie manuelle. Il suffit d’un petit oubli et tout peut partir en vrille, et le gain espéré de quelques minutes peut s’avérer contre-productif.
Personnellement je ne m’y risquerai pas, d’autant qu’il y a plus d’enjeux ailleurs (par exemple, s’assurer qu’il n’y a pas de gros bug bloquant peu après le lancement).
Cela dit, rien n’empêche le jour J d’utiliser les 2 méthodes en parallèle, afin d’avoir la méthode industrielle en solution de repli au bout de 25". Mais bon, je préfère quand même la méthode indus car plus transparent, il y a tout le détail de ce qui s’est passé, davantage vérifiable entre autres.
Je viens de découvrir ce sujet, 25 minutes, c’est déjà très, très court.
Je pense que, de toute façon, pour la vraie migration, il faudra communiquer sur plusieurs heures d’arrêt de la Ğ1, car on doit se donner de la marge pour gérer d’éventuels problèmes de dernière minute.
Il faudra qu’on ait le temps de bien tout vérifier manuellement après le lancement du genesis et avant de communiquer aux utilisateurs que “c’est bon, ils peuvent y aller”.
Peut-être qu’on devra relancer le genesis plusieurs fois en cas de problèmes. Il est préférable que, le jour J, on ait au moins quelques forgerons en synchrone qui puissent configurer leur nœud forgeron en direct pour vérifier que tout se passe bien.
L’idéal serait d’intégrer, dans Cesium v1, un bout de code qui nous permette de déclencher un freeze de l’application une heure avant de lancer la copie des données de la Ğ1, afin de limiter au maximum la perte de transactions des utilisateurs.
Je préfère qu’on annonce un blocage de 6 heures pour être vraiment sûr et pouvoir tout faire correctement, tant que c’est une date connue à l’avance et que cela se fait en semaine, cela devrait bien être accepté (en semaine, car il y a des gmarchés presque tous les week-ends).
(par exemple, s’assurer qu’il n’y a pas de gros bug bloquant peu après le lancement).