Migration d'applications .NET vers .NET Core (1)

Cet article présente un processus de migration d'application.

Recompiler un logiciel qui s'exécute sur un certain système d'exploitation et une certaine structure matérielle sur un autre système d'exploitation et une autre structure matérielle (y compris quelques modifications nécessaires) afin de fonctionner sur la nouvelle plateforme, ce processus est appelé transplantation d'application. Dans certains cas, porter une application d’une plate-forme à une autre est aussi simple que de recompiler et d’effectuer des tests de vérification. Mais il existe des cas où la procédure de transplantation n’est pas si simple.

Ce chapitre est un complément à la gestion de projet actuelle en matière de transplantation d'applications. Il explique comment utiliser un processus formalisé de gestion des exigences, comment mieux communiquer avec les développeurs de logiciels et comment gérer les projets d'aujourd'hui. Je le connais très bien, mais le développement et le portage de logiciels ne sont pas exactement les mêmes, et c'est le sujet de ce chapitre.

Ce chapitre se concentre sur le processus détaillé et les risques techniques de la migration de logiciels, et répertorie quelques habitudes et méthodes pour obtenir des applications cohérentes de haute qualité.

Processus métiers d'un logiciel

Avant de démarrer un projet de portage, il est important de comprendre quels processus métiers seront affectés au cours du cycle de vie de l'application. Les processus métier concernés doivent être modifiés pour s'adapter aux applications migrées en raison de la nécessité de prendre en charge de nouvelles plates-formes, de nouveaux environnements de test, de nouveaux outils, de nouvelle documentation et, plus important encore, de la nécessité de prendre en charge de nouveaux clients et d'établir des relations avec les clients.

Au cours du cycle de vie de l'application, les trois principaux domaines pouvant avoir un impact sur le processus métier sont le développement et les tests, le support client et la sortie de l'application :

Développement et tests. Dans le département de développement et de tests, les testeurs de développement doivent être testés sur leurs compétences Linux/Windows dans les domaines suivants : différences entre les interfaces de programmation d'applications (API), outils de développement, capacités de débogage, outils de performances et exigences de l'application à porter. logiciel.

Support client. Dans le service de support client, le personnel de support doit être formé dans les domaines suivants : gestion du système Linux/Windows, logiciels tiers requis pour les applications portées, méthodes d'installation et de gestion, outils de gestion de packages dans les environnements Linux/Windows, outils et méthodes de débogage. , et tout ce qui est nécessaire.

Sortie de l'application. Dans le service de publication d'applications, le personnel commercial et les consultants techniques doivent être formés aux fonctionnalités et connaissances globales de Linux/Windows. Le personnel du canal de publication de logiciels doit être formé pour devenir formateur de logiciels Linux/Windows. Du point de vue du client, ils espèrent également acquérir des connaissances sur l'intégration Linux/Windows et être en mesure d'intégrer Linux/Windows à leurs systèmes informatiques existants.

Le portage d'applications .NET vers la plateforme .NETCore implique la modification des processus organisationnels de l'entreprise qui peuvent être affectés par l'application nouvellement portée. Ces trois aspects principaux doivent être soigneusement examinés avant le début de la migration proprement dite et inclus tout au long du projet de migration.

Processus de portage

Les développeurs impliqués dans des projets de portage peuvent suivre des étapes similaires lors du portage de n'importe quel projet. Ces étapes comprennent : l’enquête, l’analyse, le portage et les tests. Chaque étape du processus constitue la base de l’étape suivante. Si vous effectuez bien chaque étape, les étapes suivantes seront faciles à réaliser.

Enquête

L'étape "Enquête" consiste principalement pour le chef de projet à convoquer des experts en transplantation (plus expérimentés dans les applications, et à comparer la plateforme open source, la plateforme cible et les produits tiers utilisés par l'application) développeurs de logiciels) et experts dans un certain domaine pour déterminer les produits, les environnements de développement et de test dont dépend l'application à porter. Plusieurs éléments clés à clarifier au cours de la phase d'enquête comprennent : les dépendances produit/logiciel, les composants de l'environnement de développement, les composants de l'environnement de compilation et les composants de l'environnement de test.

Dépendances produit/logiciel. Déterminez les produits dont dépend l'application à transplanter, c'est-à-dire déterminez la version de la base de données, du middleware, de la bibliothèque de classes tierce, etc. que l'application utilise. Connaissant les produits et les versions dont ils dépendent, les experts en portage peuvent estimer si ces produits et versions sont disponibles sur la plateforme .NET Core.

Composants de l'environnement de développement. La détermination de l'environnement de développement implique de déterminer dans quel langage de programmation l'application à porter sera écrite. Les applications écrites dans des langages de programmation plus récents (tels que C#) sont plus faciles à porter, mais les applications écrites en C/C prennent plus de temps à analyser et à porter.

Composants de l'environnement de compilation. La détermination de l'environnement de compilation consiste à déterminer si les outils de compilation requis sont disponibles sous Linux/Windows. Les indicateurs de compilation et de liaison spécifiques à la plate-forme utilisés sur la plate-forme source doivent être étudiés pour déterminer si les indicateurs correspondants existent sous Linux/Windows. Certains environnements de compilation peuvent dépendre de la plate-forme d'origine, ce qui peut nécessiter plus d'efforts pour être portés sous Linux.

Tester les composants de l'environnement. La détermination de l'environnement de test à utiliser pour l'application portée introduit certains problèmes dont les testeurs devraient se préoccuper. En règle générale, les ingénieurs de portage effectuent uniquement des tests unitaires sur les pièces qu'ils portent, puis confient le programme à l'équipe de test pour une vérification plus complète et des tests du système. Mais qui est le groupe test ?

Dans la plupart des cas, l'étape « enquête » permettra également de clarifier certains risques qui peuvent être rencontrés après le démarrage du projet. Les risques qui peuvent être identifiés lors de la phase d'enquête sont les suivants :

La base de données, le middleware et les assemblys tiers dépendants requis ne sont pas disponibles sur .NET Core.

L'application comprend certaines routines d'assemblage qui doivent être converties en instructions d'assemblage Linux.

L'application utilise une API ou un modèle de programmation spécifique à la plateforme source. Cela inclut également des hypothèses sur la casse des lettres et l'endianisme lors de l'écriture de programmes.

Les applications sont écrites selon une certaine version de .NET, et la mise en œuvre de cette norme repose sur le compilateur unique sur la plateforme d'origine.

L'environnement de test nécessite une architecture client/serveur complexe.

L'environnement de développement nécessite des outils tiers, qui doivent être portés sur .NET Core.

La publication ou l'installation d'applications nécessite des outils propres à la plateforme source.

L'étape « enquête » nécessite une attention particulière à chaque nouvelle information, qui peut être obtenue en posant quelques questions, telles que des questions sur la documentation, l'emballage, le réglage des performances, etc.

Analyse

L'étape « Analyse » doit être considérée sous deux angles : la gestion de projet et la transplantation. Du point de vue de la gestion de projet, l'analyse consiste à évaluer les différents problèmes et risques de migration identifiés à l'étape précédente et leur impact sur la migration du projet. L'étape « Analyse » consiste à élaborer un plan de projet, notamment à déterminer la portée et les objectifs du projet, à créer un calendrier de travail, à obtenir des ressources et à attribuer des rôles dans le projet.

La détermination de la portée et des objectifs du projet définit également l'étendue des responsabilités et des responsabilités du chef de projet et des membres de l'équipe. La portée du projet fait référence à la série de travaux à réaliser dans le cadre du projet. Par exemple, une simple déclaration telle que « Le module A de l'application ABC doit être porté sur la plate-forme B et testé sur la plate-forme B » est un bon exemple de définition de la portée d'un projet.

Une fois la portée du projet définie, les tâches spécifiques des travaux de transplantation peuvent être définies, ce qui génère un calendrier avec une classification détaillée des travaux. Le calendrier peut aider à déterminer quel travail doit être effectué et s'il peut être effectué de manière séquentielle ou en parallèle. De plus, le calendrier répertorie les ressources nécessaires. Un calendrier complet peut être obtenu en définissant les tâches du projet et les ressources requises.

Du point de vue de la transplantation, l'étape « analyse » consiste pour l'ingénieur de transplantation à analyser en détail la structure de l'application. L'ingénieur de portage doit déterminer les API et les appels système utilisés par l'application, et évaluer la liaison et le chargement dynamiques, le réseau, les threads, etc. utilisés par l'application. Ces informations sont analysées et renvoyées au chef de projet, qui détermine ensuite des tâches plus détaillées et élabore un plan plus précis.

Transplantation

« Transplantation » Cette étape est celle où les ingénieurs en transplantation commencent à effectuer le travail spécifique qui leur est assigné. Sur la base du planning de travail issu de l'étape précédente, l'ingénieur de migration ne pourra peut-être travailler qu'en série. Cela est principalement dû au fait que le programme à porter peut être étroitement couplé. En d'autres termes, un module de l'application dépend fortement d'autres modules. Ce n'est qu'une fois la transplantation de ces modules dépendants terminée que ces modules peuvent être transplantés. Un exemple typique est la transplantation d’un environnement de compilation. Si l'environnement de compilation d'origine est conçu pour compiler l'intégralité de l'application en une seule fois, alors les fichiers de configuration communs dont dépend chaque module doivent être modifiés avant tout travail de migration.

Si les travaux de migration ne sont pas liés les uns aux autres, la migration peut être effectuée en parallèle. Le portage de modules faiblement couplés peut être divisé et effectué simultanément par différents ingénieurs. Un exemple typique est la transplantation de bibliothèques partagées. Ces bibliothèques partagées n'ont aucun impact les unes sur les autres, peuvent être compilées indépendamment et ne sont utilisées par d'autres modules que pour la compilation et la liaison. Il est important de déterminer quel travail peut être effectué en parallèle et doit être effectué pendant la phase d’analyse.

Le travail de compilation de code sur .NET Core comprend l'identification et l'élimination des dépendances de code sur l'architecture, ainsi que des habitudes de programmation non standard, notamment la vérification du code et l'utilisation de structures de données portables ou de normes de codage. Des ingénieurs de portage expérimentés et soucieux de la qualité corrigeront les erreurs de compilation et vérifieront ces dernières en même temps.

Le travail de portage comprend également le portage de l'environnement de compilation vers la plateforme Linux/Windows. Cela devrait être clarifié au cours de la phase d’enquête. Certains environnements de compilation sont portables, mais d'autres ne le sont pas. Confirmer que l'environnement de compilation ne pose pas de problèmes potentiels est une tâche facilement négligée qui nécessite une enquête et une analyse très minutieuses.

Une fois l'application transplantée (c'est-à-dire compilée sur .NET Core), l'ingénieur de transplantation doit effectuer des tests unitaires sur l'application transplantée. Les tests unitaires peuvent être très simples. Par exemple, vous pouvez simplement exécuter le programme pour voir si des erreurs d'exécution se produisent, vous devez corriger ces erreurs avant de livrer l'application à l'équipe de test. Dans ce cas, l'équipe de test procédera à des tests plus complets du programme.

Tests

Au cours du processus de test, le testeur désigné exécutera certains cas de test sur l'application transplantée. Ces cas de test ont des objectifs de test différents, allant de la simple exécution de tests simples au stress. des tests qui testent si l'application est suffisamment robuste sur la plateforme .NET Core. Les tests de résistance d'une application sur la plate-forme cible peuvent révéler des problèmes au-delà des dépendances architecturales et des mauvaises habitudes de codage. La plupart des applications, en particulier celles multithread, ont tendance à se comporter différemment lorsqu'elles sont testées sous contrainte sur différentes plates-formes, en partie à cause des différentes implémentations du système d'exploitation, en particulier des différentes implémentations des threads. Si des problèmes sont découverts lors des tests, l'ingénieur de migration doit les déboguer et les résoudre.

Certains portages d'applications incluent également le portage d'un ensemble d'outils de test pour tester l'application. La migration des outils de test est également une tâche qui doit être déterminée lors de la phase d'investigation et de test. Dans la plupart des cas, les testeurs doivent souvent recevoir une formation sur l'application avant de pouvoir tester l'application. L'apprentissage de l'application est une tâche totalement indépendante du travail de portage et peut être effectué en parallèle avec la tâche de portage.

Une fois que les tests ont détecté des problèmes, vous devez résoudre ces problèmes et recompiler l'application ; puis retester le problème jusqu'à ce que l'application réussisse tous les cas de test.

Support

Une fois les travaux de portage terminés, la phase de développement est terminée et la phase de support commence. Quelques ingénieurs de portage resteront à votre disposition pour répondre à toutes les questions que les clients pourraient avoir. En outre, les développeurs doivent également former les clients sur la façon de configurer et d'exécuter des applications sur les plates-formes Linux/Windows. Après la greffe, la phase d'accompagnement dure généralement de 60 à 90 jours. Au cours de cette période, les ingénieurs de migration ont formé le personnel d'assistance technique et le personnel commercial sur les applications nouvellement portées vers .NET Core et ont répondu à leurs questions. Une fois la formation terminée, le travail de l’ingénieur transplanteur est terminé.

Définir la portée et les objectifs du projet

Définir la portée du projet consiste à définir clairement le point final et les limites du projet, ainsi que les responsabilités du chef de projet et des membres du projet. Une portée de projet clairement définie peut garantir que toutes les parties prenantes du projet (personnes ou organisations impliquées dans le projet ou affectées par le projet, telles que l'équipe de projet, les architectes, les testeurs, les clients ou les sponsors, les services de coopération, etc.) comprennent clairement le objectifs du projet.

Des objectifs ou exigences clairs du projet peuvent aider les gens à mieux comprendre la portée du projet. Au cours de la phase d'analyse du processus de migration, les objectifs et les exigences du client sont rassemblés, décomposés en structures et finalement définis en livrables du projet. Les objectifs et les exigences du projet constituent le point de départ pour définir la portée du projet. Une fois tous les objectifs du projet déterminés, la portée du projet devient plus claire.

Une façon de définir la portée d'un projet est de lister les objectifs qui seront et ne seront pas inclus dans le projet. Rassembler une liste d’exigences auprès des clients est une excellente façon de commencer. Une fois les exigences collectées, le chef de projet et le responsable technique vérifient la liste des exigences en détail. Si vous avez des doutes sur certaines exigences, vous devez les inscrire sur la liste des exclus, au moins dans un premier temps. Le client vérifie ensuite à nouveau la liste et corrige les éventuelles objections. Enfin, sachez que tout le monde s’accorde sur le fait que la liste représente correctement tous les objectifs que doit contenir le projet.

Encore une fois, la liste doit être suffisamment détaillée pour pouvoir lister ceux qui sont inclus dans le projet et ceux qui ne le sont pas. En effet, il est important de détailler les exigences qui dépassent le cadre du projet. Les objectifs qui ne fournissent pas suffisamment d’informations pour définir la portée du projet deviendront de plus en plus un point de discorde à mesure que la date de sortie du projet approche. Par exemple, comment les différentes parties du travail de migration seront-elles livrées à l'équipe de migration - est-elle livrée en plusieurs itérations ou en une seule fois ? Chaque livraison est-elle livrée en une phase, ou y a-t-il des travaux plus petits inclus dans cette phase ? Combien d’itérations y a-t-il dans un projet complet ? Cette liste définit non seulement le projet lui-même, mais répertorie également les résultats souhaités pour toutes les parties prenantes concernées du projet.

Voici quelques principes de base qui doivent être suivis lors de la création d'une liste d'objectifs de projet :

1 Définissez la portée du projet de manière aussi détaillée que possible.

2. Confirmez que toutes les parties prenantes concernées du projet sont d'accord sur la portée du projet.

3. Répertoriez le contenu non résolu dans la liste « Non inclus/Non inclus » jusqu'à ce qu'ils soient tous résolus.

Une partie de la définition des objectifs du projet consiste à décrire les critères d'acceptation et d'achèvement du projet. Toutes les parties prenantes du projet doivent s'entendre sur les critères de réalisation du projet. L'achèvement du projet peut faire référence au pourcentage de tests système réussis sur la plate-forme Linux/Windows, ou à la réussite d'une certaine norme de performance définie par les performances du système - c'est-à-dire que l'objectif du projet est d'exécuter un ensemble spécifique de cas de test ou d'analyse des performances. Quelle que soit la façon dont les critères d'achèvement du projet sont définis, si possible, toutes les parties prenantes du projet doivent comprendre et accepter ces critères avant le début de la migration. Toute modification apportée à la norme au cours du processus de migration doit être négociée et approuvée par toutes les parties prenantes concernées avant de remplacer la norme existante.

Ce qui précède est le contenu de la migration des applications .NET vers .NET Core (1). Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !