Migration von .NET-Anwendungen zu .NET Core (1)

In diesem Artikel wird ein Prozess der Anwendungsmigration vorgestellt.

Eine Software, die auf einem bestimmten Betriebssystem und einer bestimmten Hardwarestruktur läuft, auf einem anderen Betriebssystem und einer anderen Hardwarestruktur neu kompilieren (einschließlich einiger notwendiger Änderungen) Um auf der neuen Plattform laufen zu können, wird dieser Vorgang als Anwendungstransplantation bezeichnet. In manchen Fällen ist die Portierung einer Anwendung von einer Plattform auf eine andere so einfach wie eine Neukompilierung und die Durchführung einiger Verifizierungstests. Es gibt jedoch Fälle, in denen die Transplantation nicht so einfach ist.

Dieses Kapitel ist eine Ergänzung zum aktuellen Projektmanagement bei der Anwendungstransplantation. Es geht darum, wie man einen formalisierten Anforderungsmanagementprozess nutzt, wie man besser mit Softwareentwicklern kommuniziert und wie man Projekte von heute verwaltet Ich bin damit sehr vertraut, aber Softwareentwicklung und Softwareportierung sind nicht genau dasselbe, und darum geht es in diesem Kapitel.

Dieses Kapitel konzentriert sich auf den detaillierten Prozess und die technischen Risiken der Softwaremigration und listet einige Gewohnheiten und Methoden auf, um konsistent hochwertige Anwendungen zu erreichen.

Geschäftsprozesse von Softwareprogrammen

Bevor Sie mit einem Portierungsprojekt beginnen, ist es wichtig zu verstehen, welche Geschäftsprozesse während des Lebenszyklus der Anwendung betroffen sein werden. Diese betroffenen Geschäftsprozesse müssen geändert werden, um die migrierten Anwendungen zu berücksichtigen, da neue Plattformen, neue Testumgebungen, neue Tools und neue Dokumentation unterstützt werden müssen und vor allem neue Kunden unterstützt und Kundenbeziehungen aufgebaut werden müssen.

Während des Anwendungslebenszyklus sind die drei Hauptbereiche, die sich auf den Geschäftsprozess auswirken können, Entwicklung und Tests, Kundensupport und Anwendungsfreigabe:

Entwicklung und Tests. In der Entwicklungs- und Testabteilung müssen Entwicklungstester ihre Linux-/Windows-Kenntnisse in den folgenden Bereichen testen: Unterschiede in der Anwendungsprogrammierschnittstelle (API), Entwicklungstools, Debugging-Funktionen, Leistungstools und die Anforderungen der zu portierenden Anwendung von Drittanbietern Software.

Kundensupport. In der Kundensupportabteilung muss das Supportpersonal in den folgenden Bereichen geschult werden: Linux/Windows-Systemverwaltung, für portierte Anwendungen erforderliche Software von Drittanbietern, Installations- und Verwaltungsmethoden, Paketverwaltungstools in Linux/Windows-Umgebungen, Debugging-Tools und -Methoden , und alles andere, was benötigt wird.

App-Veröffentlichung. In der Anwendungsveröffentlichungsabteilung müssen Vertriebsmitarbeiter und technische Berater in den allgemeinen Linux/Windows-Funktionen und -Kenntnissen geschult werden. Das Personal des Software-Release-Channels muss zu Trainern für Linux-/Windows-Softwareprogramme ausgebildet werden. Aus Kundensicht erhoffen sie sich darüber hinaus Kenntnisse über die Linux/Windows-Integration und die Möglichkeit, Linux/Windows in ihre bestehenden IT-Systeme integrieren zu können.

.NET-Anwendung Portieren von Anwendungen auf die .NETCore-Plattform bedeutet, dass geschäftliche Organisationsprozesse geändert werden, die von der neu portierten Anwendung betroffen sein können. Diese drei Hauptaspekte sollten vor Beginn der eigentlichen Migration sorgfältig bedacht und in das gesamte Migrationsprojekt einbezogen werden.

Portierungsprozess

Entwickler, die an der Portierung von Projekten beteiligt sind, können bei der Portierung eines beliebigen Projekts ähnliche Schritte befolgen. Zu diesen Schritten gehören: Untersuchung, Analyse, Portierung und Tests. Jeder Schritt im Prozess ist die Grundlage für den nächsten Schritt. Wenn Sie jeden Schritt gut ausführen, sind die folgenden Schritte einfach durchzuführen.

Untersuchung

Der Schritt „Untersuchung“ dient hauptsächlich dazu, dass der Projektmanager Transplantationsexperten (mehr Erfahrung in Anwendungen) hinzuzieht und die verwendete Open-Source-Plattform, Zielplattform und Produkte von Drittanbietern vergleicht (durch die Anwendung erstellte Softwareentwickler) und Experten auf einem bestimmten Gebiet, um zu bestimmen, von welchen Produkten, Entwicklungs- und Testumgebungen die zu portierende Anwendung abhängt. Zu den wichtigsten Dingen, die während der Untersuchungsphase geklärt werden müssen, gehören: Produkt-/Softwareabhängigkeiten, Komponenten der Entwicklungsumgebung, Komponenten der Kompilierungsumgebung und Komponenten der Testumgebung.

Produkt-/Softwareabhängigkeiten. Bestimmen Sie die Produkte, von denen die zu übertragende Anwendung abhängt, dh bestimmen Sie, welche Version der Datenbank, Middleware, Klassenbibliothek eines Drittanbieters usw. die Anwendung verwendet. Da sie die Produkte und Versionen kennen, von denen sie abhängen, können Portierungsexperten abschätzen, ob diese Produkte und Versionen auf der .NET Core-Plattform verfügbar sind.

Komponenten der Entwicklungsumgebung. Zur Festlegung der Entwicklungsumgebung gehört auch die Festlegung, in welcher Programmiersprache die zu portierende Anwendung geschrieben werden soll. In neueren Programmiersprachen (z. B. C#) geschriebene Anwendungen lassen sich einfacher portieren, in C/C++ geschriebene Anwendungen erfordern jedoch mehr Zeit für die Analyse und Portierung.

Komponenten der Kompilierungsumgebung. Zur Bestimmung der Kompilierungsumgebung gehört auch die Feststellung, ob die erforderlichen Kompilierungstools unter Linux/Windows verfügbar sind. Plattformspezifische Kompilierungs- und Link-Flags, die auf der Quellplattform verwendet werden, müssen untersucht werden, um festzustellen, ob entsprechende Flags unter Linux/Windows vorhanden sind. Einige Kompilierungsumgebungen hängen möglicherweise von der ursprünglichen Plattform ab, was möglicherweise mehr Aufwand für die Portierung auf Linux erfordert.

Komponenten der Testumgebung. Die Bestimmung der Testumgebung, die für die portierte Anwendung verwendet werden soll, wirft einige Probleme auf, über die sich Tester Sorgen machen sollten. Normalerweise führen Portierungsingenieure nur Unit-Tests für die Teile durch, die sie portieren, und übergeben das Programm dann an das Testteam für eine umfassendere Verifizierung und Systemtests. Aber wer ist die Testgruppe?

In den meisten Fällen werden im Schritt „Untersuchung“ auch einige Risiken geklärt, die nach Projektstart auftreten können. Die Risiken, die während der Untersuchungsphase identifiziert werden können, sind folgende:

Die erforderliche Datenbank, Middleware und abhängige Drittanbieter-Assemblys sind auf .NET Core nicht verfügbar.

Die Anwendung enthält einige Assemblerroutinen, die in Linux-Assembleranweisungen konvertiert werden müssen.

Die Anwendung verwendet eine API oder ein Programmiermodell, das für die Quellplattform spezifisch ist. Dazu gehören auch Annahmen über Groß- und Kleinschreibung und Endianness beim Schreiben von Programmen.

Anwendungen werden gemäß einer bestimmten Version von .NET geschrieben, und die Implementierung dieses Standards basiert auf dem einzigartigen Compiler auf der Originalplattform.

Die Testumgebung erfordert eine komplexe Client/Server-Architektur.

Die Entwicklungsumgebung erfordert Tools von Drittanbietern und die Tools müssen auf .NET Core portiert werden.

Das Veröffentlichen oder Installieren von Anwendungen erfordert spezielle Tools für die Quellplattform.

Der Schritt „Untersuchung“ erfordert Aufmerksamkeit für alle neuen Informationen, die durch das Stellen einiger Fragen erhalten werden können, z. B. Fragen zu Dokumentation, Verpackung, Leistungsoptimierung usw.

Analyse

Der Schritt „Analyse“ muss aus zwei Perspektiven betrachtet werden: Projektmanagement und Transplantation. Aus Sicht des Projektmanagements geht es bei der Analyse darum, die verschiedenen Migrationsprobleme und -risiken zu bewerten, die im vorherigen Schritt identifiziert wurden, und wie sie sich auf die Projektmigration auswirken werden. Der Schritt „Analyse“ umfasst die Entwicklung eines Projektplans, einschließlich der Festlegung des Umfangs und der Ziele des Projekts, der Erstellung eines Arbeitsplans, der Beschaffung von Ressourcen und der Zuweisung von Projektrollen.

Durch die Festlegung des Umfangs und der Ziele des Projekts wird auch der Umfang der Verantwortlichkeiten und Verantwortlichkeiten des Projektmanagers und der Teammitglieder definiert. Der Projektumfang bezieht sich auf die Reihe von Arbeiten, die im Rahmen des Projekts abgeschlossen werden sollen. Beispielsweise ist eine einfache Aussage wie „Modul A der Anwendung ABC muss auf Plattform B portiert und auf Plattform B getestet werden“ ein gutes Beispiel für die Definition des Umfangs eines Projekts.

Nachdem der Projektumfang definiert ist, können die spezifischen Aufgaben der Transplantationsarbeiten definiert werden, wodurch ein Zeitplan mit detaillierter Klassifizierung der Arbeiten erstellt wird. Der Zeitplan kann dabei helfen, festzustellen, welche Arbeiten erledigt werden müssen und ob diese nacheinander oder parallel durchgeführt werden können. Darüber hinaus listet der Zeitplan die benötigten Ressourcen auf. Durch die Definition der Projektaufgaben und benötigten Ressourcen kann ein vollständiger Zeitplan erstellt werden.

Aus Sicht der Transplantation besteht der Schritt „Analyse“ darin, dass der Transplantationsingenieur die Struktur der Anwendung im Detail analysiert. Der Portierungsingenieur sollte die von der Anwendung verwendeten APIs und Systemaufrufe bestimmen und die von der Anwendung verwendeten dynamischen Verknüpfungen und Ladevorgänge, das Netzwerk, die Threads usw. bewerten. Diese Informationen werden analysiert und an den Projektmanager zurückgemeldet, der dann detailliertere Aufgaben festlegt und einen genaueren Plan entwickelt.

Transplantation

„Transplantation“ In diesem Schritt beginnen die Transplantationsingenieure mit der Ausführung der ihnen zugewiesenen spezifischen Arbeit. Basierend auf dem aus dem vorherigen Schritt abgeleiteten Arbeitsplan kann der Migrationsingenieur möglicherweise nur seriell arbeiten. Dies liegt hauptsächlich daran, dass das zu portierende Programm möglicherweise eng gekoppelt ist. Das heißt, ein Modul der Anwendung hängt stark von anderen Modulen ab und diese Module können erst transplantiert werden, nachdem die Transplantation dieser abhängigen Module abgeschlossen ist. Ein typisches Beispiel ist die Transplantation einer Kompilierungsumgebung. Wenn die ursprüngliche Kompilierungsumgebung darauf ausgelegt ist, die gesamte Anwendung auf einmal zu kompilieren, müssen die allgemeinen Konfigurationsdateien, von denen jedes Modul abhängt, vor jeglichen Migrationsarbeiten geändert werden.

Wenn die Migrationsarbeiten nicht miteinander in Zusammenhang stehen, kann die Migration parallel durchgeführt werden. Die Portierung lose gekoppelter Module kann aufgeteilt und gleichzeitig von verschiedenen Ingenieuren durchgeführt werden. Ein typisches Beispiel ist die Transplantation gemeinsam genutzter Bibliotheken, die keinen Einfluss aufeinander haben, unabhängig voneinander kompiliert werden können und nur zum Kompilieren und Verknüpfen durch andere Module verwendet werden. Es ist wichtig zu bestimmen, welche Arbeiten parallel durchgeführt werden können und sollte während der Analysephase erfolgen.

Die Arbeit beim Kompilieren von Code auf .NET Core umfasst das Identifizieren und Beseitigen von Codeabhängigkeiten von der Architektur sowie von nicht standardmäßigen Programmiergewohnheiten, einschließlich der Überprüfung von Code und der Verwendung portabler Datenstrukturen oder Codierungsstandards. Erfahrene und qualitätsbewusste Portierungsingenieure korrigieren Kompilierungsfehler und überprüfen diese gleichzeitig.

Zu den Portierungsarbeiten gehört auch die Portierung der Kompilierungsumgebung auf die Linux/Windows-Plattform. Dies sollte in der Untersuchungsphase geklärt werden. Einige Kompilierungsumgebungen sind portierbar, andere jedoch nicht. Die Bestätigung, dass die Kompilierungsumgebung keine potenziellen Probleme verursacht, ist eine leicht zu übersehende Aufgabe, die eine sehr sorgfältige Untersuchung und Analyse erfordert.

Nachdem die Anwendung transplantiert (d. h. auf .NET Core kompiliert) wurde, muss der Transplantationsingenieur einen Komponententest für die transplantierte Anwendung durchführen. Unit-Tests können sehr einfach sein. Sie können beispielsweise einfach das Programm ausführen, um zu sehen, ob Laufzeitfehler auftreten. Diese Fehler müssen Sie beheben, bevor Sie die Anwendung an das Testteam übermitteln. In diesem Fall führt das Testteam umfassendere Tests des Programms durch.

Testen

Während des Testprozesses führt der designierte Tester einige Testfälle für die transplantierte Anwendung aus. Diese Testfälle dienen unterschiedlichen Testzwecken, von der einfachen Ausführung der Anwendung bis hin zu Stresstests Tests, die testen, ob die Anwendung auf der .NET Core-Plattform robust genug ist. Durch Stresstests einer Anwendung auf der Zielplattform können Probleme aufgedeckt werden, die über Architekturabhängigkeiten und schlechte Programmiergewohnheiten hinausgehen. Die meisten Anwendungen, insbesondere solche mit mehreren Threads, neigen dazu, sich bei Belastungstests auf verschiedenen Plattformen unterschiedlich zu verhalten, was teilweise auf unterschiedliche Betriebssystemimplementierungen, insbesondere unterschiedliche Thread-Implementierungen, zurückzuführen ist. Wenn beim Testen Probleme entdeckt werden, sollte der Migrationsingenieur diese debuggen und beheben.

Einige Anwendungsportierungen umfassen auch die Portierung einer Reihe von Testtools zum Testen der Anwendung. Auch die Migration von Testtools ist eine Aufgabe, die während der Untersuchungs- und Testphase festgelegt werden sollte. In den meisten Fällen müssen Tester eine Schulung zur Anwendung absolvieren, bevor sie die Anwendung testen können. Das Erlernen der Anwendung ist eine von der Portierungsarbeit völlig unabhängige Aufgabe und kann parallel zur Portierungsaufgabe durchgeführt werden.

Nachdem beim Testen Probleme gefunden wurden, müssen Sie diese Probleme lösen und die Anwendung neu kompilieren. Anschließend müssen Sie das Problem erneut testen, bis die Anwendung alle Testfälle besteht.

Support

Nach Abschluss der Portierungsarbeiten ist die Entwicklungsphase beendet und die Supportphase beginnt. Einige Portierungstechniker stehen Ihnen weiterhin zur Verfügung, um bei der Beantwortung laufender Fragen der Kunden behilflich zu sein. Darüber hinaus sollten Entwickler Kunden auch in der Konfiguration und Ausführung von Anwendungen auf Linux-/Windows-Plattformen schulen. Nach der Transplantation dauert die Unterstützungsphase in der Regel 60 bis 90 Tage. Während dieser Zeit schulten Migrationsingenieure Mitarbeiter des technischen Supports und Vertriebsmitarbeiter in neu portierten Anwendungen auf .NET Core und beantworteten ihre Fragen. Nach Abschluss der Ausbildung ist die Arbeit des Transplantationsingenieurs abgeschlossen.

Projektumfang und -ziele definieren

Projektumfang definieren bedeutet, den Endpunkt und die Grenzen des Projekts sowie die Verantwortlichkeiten des Projektmanagers und der Projektmitglieder klar zu definieren. Durch einen klar definierten Projektumfang kann sichergestellt werden, dass sich alle Stakeholder des Projekts (am Projekt beteiligte oder vom Projekt betroffene Personen oder Organisationen, wie Projektteam, Architekten, Tester, Kunden oder Sponsoren, Kooperationsabteilungen etc.) darüber im Klaren sind Ziele des Projekts.

Klare Projektziele oder -anforderungen können den Menschen helfen, den Umfang des Projekts besser zu verstehen. In der Analysephase des Migrationsprozesses werden die Ziele und Anforderungen des Kunden erfasst, in Strukturen heruntergebrochen und schließlich in Projektergebnisse definiert. Die Projektziele und -anforderungen sind der Ausgangspunkt für die Definition des Projektumfangs. Nachdem alle Projektziele festgelegt sind, wird der Umfang des Projekts klarer.

Eine Möglichkeit, den Umfang eines Projekts zu definieren, besteht darin, die Ziele aufzulisten, die in das Projekt aufgenommen werden und die nicht. Das Zusammentragen einer Liste mit den Anforderungen der Kunden ist ein guter Anfang. Nachdem die Anforderungen erfasst wurden, überprüfen der Projektmanager und der technische Leiter die Anforderungsliste im Detail. Wenn Sie Zweifel an bestimmten Anforderungen haben, sollten Sie diese zumindest zunächst auf die Ausschlussliste setzen. Anschließend prüft der Kunde die Liste noch einmal und behebt etwaige Einwände. Schließlich sollten Sie sich darüber im Klaren sein, dass sich alle darin einig sind, dass die Liste alle Ziele, die das Projekt enthalten sollte, korrekt darstellt.

Auch hier muss die Liste detailliert genug sein, um diejenigen auflisten zu können, die im Projekt enthalten sind, und diejenigen, die nicht darin enthalten sind. Tatsächlich ist es wichtig, Anforderungen detailliert darzustellen, die über den Rahmen des Projekts hinausgehen. Ziele, die nicht genügend Informationen zur Definition des Projektumfangs liefern, werden zu einem Streitpunkt, je näher das Veröffentlichungsdatum des Projekts rückt. Wie werden beispielsweise die verschiedenen Teile der Migrationsarbeit an das Migrationsteam geliefert – erfolgt die Bereitstellung in mehreren Iterationen oder auf einmal? Wird jede Lieferung als Phase geliefert oder sind in dieser Phase kleinere Arbeitsschritte enthalten? Wie viele Iterationen gibt es in einem vollständigen Projekt? Diese Liste definiert nicht nur das Projekt selbst, sondern listet auch die gewünschten Ergebnisse für alle relevanten Stakeholder des Projekts auf.

Die folgenden Grundprinzipien müssen beim Erstellen einer Projektzielliste befolgt werden:

1. Definieren Sie den Projektumfang so detailliert wie möglich.

2. Bestätigen Sie, dass sich alle relevanten Projektbeteiligten über den Projektumfang einig sind.

3. Listen Sie ungelöste Inhalte in der Liste „Nicht enthalten/Nicht im Umfang“ auf, bis alle gelöst sind.

Ein Teil der Definition von Projektzielen besteht darin, die Kriterien für die Annahme und den Abschluss des Projekts festzulegen. Alle Projektbeteiligten müssen sich auf die Projektabschlusskriterien einigen. Der Projektabschluss kann sich auf den Prozentsatz der Systemtests beziehen, die auf der Linux/Windows-Plattform bestanden wurden, oder auf das Bestehen eines bestimmten durch die Systemleistung festgelegten Leistungsstandards. Das heißt, das Projektziel besteht darin, einen bestimmten Satz von Testfällen oder Leistungsanalysen auszuführen. Unabhängig davon, wie die Projektabschlusskriterien definiert sind, müssen nach Möglichkeit alle Projektbeteiligten diese Kriterien verstehen und ihnen zustimmen, bevor mit der Migration begonnen wird. Alle Änderungen am Standard während des Migrationsprozesses müssen von allen relevanten Stakeholdern ausgehandelt und genehmigt werden, bevor der bestehende Standard ersetzt wird.

Das Obige ist der Inhalt der Migration von .NET-Anwendungen zu .NET Core (1). Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)!