Une nouvelle version de votre framework apporte toujours son lot de fonctionnalité, de corrections de bugs et d’amélioration de performance intéressantes. Malheureusement une migration ne se passe pas toujours comme prévu, voici donc 5 prérequis afin de bien vous préparer avant de vous lancer dans votre migration.
1 – Crée une branche
Ca parait évident, mais la plupart des personnes l’oubli.
Une migration peu posée des problèmes, et il faut donc que vous puissiez revenir en arrière. Pour cela rien de plus simple que de créer une branche 🙂
2 – Vérifier la compatibilité avec votre code existant
La plus part des framework moderne font de gestion sémentique de version, le numéro de version se présente sur le format « x.y.z« .
Le numéro x représente les versions majeures, lorsqu’il monte cela signifie qu’il y a des changement rétro-incompatibles ( on appelle ca des breaking change )
Le numéro y représente les versions majeurs, lorsqu’il monte cela signifie qu’il y a des ajout de fonctionnalité et/ou correction de bugs rétro compatibles
Le numéro z représente les versions de correction de bug, lorsqu’il monte cela signifie qu’il y a des corrections de bug est qu’elle sont rétro-compatibles
Si votre migration concerne une version majeure, il vous faut alors regarder les CHANGELOG du framework, et vérifier que les breaking changes n’aient pas d’impact sur votre code ( la plupart du temps du code qui était dépréciée ).
3 – Vérifier la compatibilité avec les librairies externes
Si vous utilisez des librairies externes, vérifier que vos librairies supportent la nouvelle version que vous allez utiliser sinon vous allez avoir de mauvaise surprise.
4 – Vérifier la liste des issues
Malgré le fait que le numéro de version soit stable, cela ne l’empêche pas d’avoir des bugs qui peuvent être bloquant pour votre projet, vérifier toujours la liste des issues, pour vérifier que l’une des fonctionnalités que vous utilisez ne soit pas bogué. Faites le aussi pour vos librairies externes, il serait bête qu’après des heures de migration vous vous rendiez compte que votre librairie externe ne soit plus utilisable.
5 – Ne pas faire la migration tout de suite
S’il s’agit d’une mise à jour de version majeure, ne surtout pas faire la migration tout de suite, attendez quelques semaines que les gens tests le framework dans une situation « réelle » avec des librairies externe et des cas d’usage spécifiques.
Sachez que les frameworks sont dans la plus part du temps en « compétition » avec d’autres framework, et que malheureusement la première choses que regarde les développeurs lorsqu’il compare deux frameworks entre eux, ce sont les performances de chargement ( taille du build ), et les performances en cours d’exécution (runtime). Du coup les tickets qui sont privilégiés sont souvent les corrections de bugs liés aux performances.
cf : https://github.com/angular/angular/issues/5689#issuecomment-619716578 et https://medium.com/@jeffbcross/jeffs-letter-to-the-angular-team-and-community-5367934a16c9