Pour tout sur tout, 50 tasses de café suffisent.
En plus de la règle générale décrite ci-dessus, nous publions une brève note sur les points qui doivent être suivis de près afin que rien ne se brise dans la bataille et dans les processus. La note a été faite dans la poursuite de la sortie d'un service mobile qui a complètement migré vers .Net Core (le début a été posé ici ). Nous avons réussi à réaliser cette opération à l'insu du client, presque sans arrêter le processus de développement principal.
Vous trouverez ci-dessous un plan d'action prêt à l'emploi, il y aura une liste de tests très vaste, cette image sera là pour l'humeur:
Donc, par étapes:
1. Planifiez un long sprint avec de grandes fonctionnalités et / ou une régression
Avec la réécriture fondamentale du code, le service aura besoin de temps pour insister le plus longtemps possible afin d'avoir le temps de corriger tous les défauts de l'environnement de test.
2. Dans le sprint exact pour réécrire le code sur .Net Core
Pourquoi est-il important de ne pas démarrer cette entreprise à l'avance? Parce que vous devez tirer deux branches de code avec le nouveau et l'ancien .net, car à tout moment un oiseau d'urgence peut voler ou vous devrez effectuer une démonstration de nouvelles fonctionnalités, puis vous devrez apporter des modifications à l'ancienne branche stable. Afin de ressentir une inquiétude minimale à ce sujet, il est préférable de raccourcir le moment de l'état de transition.
Soit dit en passant, lorsque nous travaillons avec le code, nous sommes rapidement arrivés à la conclusion qu'il est plus pratique de conserver deux copies du référentiel localement. C'est plus facile et plus pratique que de changer deux branches massives.
- Si possible, réécrivez les interfaces WCF dans webapi dans les services utilisés
L'implémentation .Net Core du client WCF est encore loin d'être idéale. Malgré le fait que les anciennes plaies sont en quelque sorte corrigées, dans les nouvelles versions, vous devez toujours utiliser une solution de contournement ( 1 , 2 ).
Pour l'histoire: sur .Net Core 2.0, la version de travail stable de WCF est 4.4.2 du référentiel myget. Elle, par exemple, n'a aucun problème avec un délai d'attente précoce
Au début de la migration, nous avons utilisé la version de .Net Core 2.0. Pendant ce temps, Microsoft a publié .Net Core 2.1. Qui est intéressé à admirer les succès des gars de Redmond dans l'optimisation de la plate-forme, veuillez lire les progrès réalisés par le moteur de recherche Bing lors de la mise à niveau vers la nouvelle version (spoiler: latensi a chuté de 34%!)
Nous avons également mis à niveau vers .Net Core 2.1 et WCF 4.5.3. Et nous n'avons pas oublié de spécifier dans le Dockerfile une nouvelle image de base microsoft / dotnet: 2.1-aspnetcore-runtime. Quelle a été la surprise quand, au lieu de 1,4 Go, ils ont vu une taille d'image de 0,5 Go (nous parlons d'une image Windows, si soudainement).
3. Préparez-vous pour un test et une démonstration
Nous avons deux environnements à notre disposition. Nous avons laissé la démo avec l'ancienne version comme référence. Un nouveau service a été déployé dans l'environnement de test - une exécution sur les développeurs et les testeurs.
Il y avait une certaine confusion due au fait que les développeurs travaillent généralement avec le test, et les testeurs principalement avec une démo. S'il fallait rafraîchir l'ancien service, la situation était exactement le contraire de la normale. Par conséquent, une discussion et une feuille de triche sur où et quoi rechercher sont utiles.
Pour exécuter le service .Net Core dans IIS, vous devez installer le module fourni avec le runtime.
Commutateur AppPool vers CLR Runtime = aucun code managé.
En solution dans le web.config standard , il est important de ne pas oublier de définir le requestTimeout souhaité et de désactiver le module WebDAV, s'il existe des méthodes DELETE.
En outre, il existe deux options pour publier un service dans IIS:
- vous effectuez la synchronisation MSDeploy - cela signifie que vous avez également besoin du commutateur -enableRule: AppOffline
- vous publiez un fichier - cela signifie exactement avant la publication que vous devez placer le fichier app_offline.htm dans le répertoire de service, et après la publication le supprimer
Cela et un autre permettent d'arrêter un processus de travail et d'ouvrir des fichiers exécutables. Sinon, une erreur se produira lorsque les fichiers ne seront pas disponibles pour l'écrasement.
Nous avons refusé la journalisation via Nlog au profit de Serilog, et perdu la compression automatique des journaux - dans Serilog, il n'y a tout simplement pas une telle fonctionnalité. Dans ce cas, vous pouvez être enregistré à l'aide des outils Windows standard et installer la compression NTFS dans les propriétés du répertoire.
4. Test
Voici la liste de contrôle la plus réduite pour les endroits les plus fragiles:
- vérifier le retour des codes d'état Mauvaise demande, non autorisé, non modifié, introuvable - tout ce que l'API peut donner
- vérifier la journalisation des demandes pour tous les codes d'état
- faire un diagramme des dépendances externes; en règle générale, toutes les informations nécessaires se trouvent dans les paramètres des applications
- bannir les méthodes qui affectent leur travail
- vérifier la journalisation des demandes externes
- vérifier le fonctionnement des paramètres pour les paramètres de réglage des applications; essayez de les changer pour chaud
- vérifier la mise en cache http pour les codes d'état positifs et négatifs
- En-tête ETag
- contrôle du cache d'en-tête
- vérifier les longues demandes et les délais
- vérifier les demandes avec une réponse vide
- vérifier les méthodes DELETE (WebDAV est désactivé ou non)
- vérifier le travail avec du contenu brut
- télécharger et télécharger un / plusieurs fichiers
- télécharger des fichiers d'une taille supérieure à la limite
- disposition d'en-tête Content-Disposition
- vérifier tous les autres en-têtes; les mettre tous ensemble dans le code est assez facile
- vérifier l'exécution de code conditionnel lors du changement d'environnements
if (env.IsDevelopment()) - vérifier la déconnexion du client et du serveur
- comparer avec le swagger.json standard - aidera à détecter la différence dans les champs transmis
Notre application mobile utilise un générateur de code pour fonctionner avec l'API basée sur la description de swagger.json, il était donc important que la différence par rapport à la description d'origine soit minime. Dans la dernière version de Swashbuckle.AspNetCore, l'interface et le swagger.json généré ont beaucoup changé. J'ai dû revenir à la version minable de Swashbuckle.AspNetCore 1.2.0 et ajouter quelques filtres.
5. Préparez-vous à vous battre tout en buvant du café
Dans notre cas, l'environnement de combat se compose de deux nœuds: actif et passif.
Pour que le passage au nouveau service se fasse inaperçu, nous avons dupliqué le pool et le site sur chaque nœud, et écrit un script pour basculer la liaison entre l'ancien et le nouveau site.
Ainsi, en cas d'urgence, nous avons pu passer rapidement à l'ancienne version.
De plus, après le déploiement à la bataille, en une semaine, nous avons été convaincus de la viabilité du service et avons allumé un feu vert pour le lancement de l'application mobile. La vie sur le projet est revenue en toute sécurité à son cours précédent.
Sous-total
Maintenant, notre service est prêt à développer un conteneur docker à livrer au cluster. Nous sommes prêts pour le déploiement à la fois dans Kubernetes et Service Fabric.
Des préparatifs sont en cours pour la présentation de la nouvelle infrastructure au client. Nous parlerons de nos réalisations dans la prochaine série, gardez le doigt sur le pouls;)