Migrating .NET applications to .NET Core (1)

This article introduces a process of application migration.

Recompile a software that runs on a certain operating system and hardware structure on another operating system and hardware structure (including some necessary modifications) in order to run on the new platform, this process is called application transplantation. In some cases, porting an application from one platform to another is as simple as recompiling and performing some verification testing. But there are cases where the transplant procedure is not that easy.

This chapter is a supplement to current project management in terms of application transplantation. It talks about how to use a formalized requirements management process, how to better communicate with software developers, and how to manage projects. Today's projects Managers are already very familiar with it, but software development and software porting are not exactly the same, and that's what this chapter is about.

This chapter focuses on the detailed process and technical risks of software migration, and lists some habits and methods to achieve consistent high-quality applications.

Software Program Business Process

Before starting a migration project, it is important to understand which business processes will be affected during the life cycle of the application. Those affected business processes must be modified to accommodate the migrated applications because of the need to support new platforms, new test environments, new tools, new documentation, and most importantly, the need to support new customers and Build customer relationships.

During the application life cycle, the three main areas that may impact the business process are development and testing, customer support, and application release:

Development and testing. In the development and testing department, development testers must be tested on Linux/Windows skills in the following areas: Application Programming Interface (API) differences, development tools, debugging capabilities, performance tools, and the requirements of the application to be ported Third party software.

Customer Support. In the customer support department, support personnel must be trained in the following areas: Linux/Windows system management, third-party software required for ported applications, installation and management methods, package management tools in Linux/Windows environments, debugging tools, and methods, and anything else required.

Application release. In the application publishing department, sales staff and technical consultants must be trained on overall Linux/Windows features and knowledge. Software release channel personnel must be trained to become trainers of Linux/Windows software programs. From the customer's perspective, they also hope to gain knowledge about Linux/Windows integration and be able to integrate Linux/Windows with their existing IT systems.

.NET Applications Migrating applications to the .NET Core platform means modifying business organization processes that may be affected by the newly ported applications. These three main aspects should be carefully considered before the actual migration begins and included throughout the entire migration project.

Porting process

Developers involved in a porting project can follow similar steps when porting any project. These steps include: investigation, analysis, porting and testing. Each step in the process is the foundation for the next step. If you do each step well, the subsequent steps will be easy to complete.

Investigation

“Investigation” This step is mainly for the project manager to summon transplant experts (more experienced in applications, and to compare the open source platform, target platform and third-party products used by the application) software developers) and experts in a certain field to determine the products, development and testing environments on which the application to be ported depends. Several key things to clarify during the investigation phase include: product/software dependencies, development environment components, compilation environment components, and test environment components.

Product/software dependencies. Determine the products that the application to be transplanted depends on, that is, determine which version of the database, middleware, third-party class library, etc. the application uses. Knowing the products and versions they depend on, porting experts can estimate whether these products and versions are available on the .NET Core platform.

Development environment components. Determining the development environment includes determining in which programming language the application to be ported will be written. Applications written in newer programming languages ​​(such as C#) are easier to port, but applications written in C/C++ require more time to analyze and port.

Compilation environment components. Determining the compilation environment includes determining whether the required compilation tools are available on Linux/Windows. Platform-specific compilation and linkage flags used on the source platform must be investigated to determine whether corresponding flags exist on Linux/Windows. Some compilation environments may depend on the original platform, which may require more effort to be ported to Linux.

Test environment components. Determining the test environment to use for the ported application introduces some issues that testers should be concerned about. Typically, porting engineers only do unit testing on the parts they port, and then hand the program over to the testing team for more complete verification and system testing. But who is the test group?

In most cases, the "investigation" step will also clarify some risks that may be encountered after the project starts. The risks that can be identified during the investigation phase are as follows:

The required database, middleware, and dependent third-party assemblies are not available on .NET Core.

The application includes some assembly routines that need to be converted into Linux assembly instructions.

The application uses an API or programming model unique to the source platform. This also includes assumptions about letter case and endianness when writing programs.

The application is written according to a certain version of .NET, and the implementation of this standard depends on the unique compiler on the original platform.

The test environment requires a complex client/server architecture.

The development environment requires third-party tools, which need to be ported to .NET Core.

Publishing or installing applications requires tools unique to the source platform.

The "investigation" step requires attention to every new information, which can be obtained by asking some questions, such as questions about documentation, packaging, performance tuning, etc.

Analysis

“Analysis” This step needs to be considered from two perspectives: project management and transplantation. From a project management perspective, analysis is about evaluating the various migration issues and risks identified in the previous step and how they will impact project migration. The "Analysis" step involves developing a project plan, including determining the scope and goals of the project, creating a work schedule, obtaining resources, and assigning project roles.

Determining the scope and goals of the project also defines the scope of responsibilities and responsibilities of the project manager and team members. Project scope refers to the series of work to be completed by the project. For example, a simple statement like "Module A of application ABC needs to be ported to platform B and tested on platform B" is a good example of defining the scope of a project.

After the project scope is defined, the specific tasks of the transplantation work can be defined, which generates a schedule with detailed classification of the work. The schedule can help determine what work needs to be done and whether it can be done sequentially or in parallel. Additionally, the schedule lists the resources required. A complete schedule can be obtained by defining the project tasks and required resources.

From the perspective of transplantation, the step of "analysis" is to analyze the structure of the application in detail. The porting engineer should determine the APIs and system calls used by the application, and evaluate the dynamic linking and loading, network, threads, etc. used by the application. This information is analyzed and fed back to the project manager, who then determines more detailed tasks and develops a more accurate plan.

Transplantation

“Transplantation” This step is when the transplantation engineers begin to perform the specific work assigned to them. Based on the work schedule derived from the previous step, the migration engineer may only be able to work serially. This is mainly because the program to be ported may be tightly coupled. That is to say, one module of the application is highly dependent on other modules, and these modules can only be transplanted after the transplantation of the dependent modules is completed. A typical example is the transplantation of compilation environment. If the original compilation environment is designed to compile the entire application at once, then the common configuration files that each module depends on must be modified before any migration work.

If the migration work is not related to each other, the migration can be carried out in parallel. The porting of loosely coupled modules can be split up and done simultaneously by different engineers. A typical example is the transplantation of shared libraries. Such shared libraries have no impact on each other, can be compiled independently, and are only used by other modules for compilation and linking. Determining what work can be done in parallel is important and should be done during the analysis phase.

                                                      The work of compiling code on .NET Core includes identifying and eliminating the code's dependencies on architecture, as well as non-standard programming habits, including checking the code and using portable data structures or coding standards. Experienced and quality-conscious porting engineers will correct compilation errors while checking the latter.

The porting work also includes porting the compilation environment to the Linux/Windows platform. This should be clarified during the investigation phase. Some compilation environments are portable, but some are not. Confirming that the compilation environment does not cause potential problems is an easily overlooked task that requires very careful investigation and analysis.

After the application transplantation is completed (that is, the compilation on .NET Core is completed), the transplantation engineer needs to perform unit testing on the transplanted application. Unit testing can be very simple. For example, you can simply run the program to see if runtime errors occur. If runtime errors occur, you need to correct these errors before delivering the application to the test team. In this case, the test team will conduct more complete testing of the program.

Testing

During the testing process, the designated tester will run some test cases on the transplanted application. These test cases have different testing purposes, ranging from just running the application. Simple tests to stress tests that test whether the application is robust enough on the .NET Core platform. Stress testing an application on the target platform can uncover problems beyond architectural dependencies and bad coding habits. Most applications, especially multi-threaded ones, tend to behave differently when stress tested on different platforms, in part because of different operating system implementations, especially different thread implementations. If problems are discovered during testing, the migration engineer should debug and resolve them.

Some applications also include transplanting a set of test tools to test the application. Migrating test tools is also a task that should be determined during the investigation and testing phase. In most cases, testers often need to receive some training on the application before they can test the application. Learning the application is a completely independent task from the porting work and can be done in parallel with the porting task.

After testing finds problems, you need to solve these problems and recompile the application; then retest the problem until the application passes all test cases.

Support

After the porting work is completed, the development phase is over and the support phase begins. A few porting engineers will remain on hand to help answer any ongoing questions customers may have. In addition, developers should also train customers on how to configure and run applications on Linux/Windows platforms. After the transplant, the support phase generally lasts 60 to 90 days. During this period, porting engineers trained technical support staff and sales staff on newly ported applications to .NET Core and answered their questions. After the training is completed, the transplant engineer's job is complete.

Define project scope and goals

Defining project scope is to clearly define the end point and boundaries of the project, as well as the responsibilities of the project manager and project members. A clearly defined project scope can ensure that all stakeholders of the project (people or organizations involved in the project or affected by the project, such as project team, architects, testers, customers or sponsors, cooperation departments, etc.) are clear about the goals of the project .

Clear project goals or requirements can allow people to better understand the project scope. During the analysis phase of the migration process, the client's goals and requirements are gathered, broken down into structures, and ultimately defined into project deliverables. The project goals and requirements are the starting point for defining the project scope. After all project goals are determined, the scope of the project becomes clearer.

One way to define the scope of a project is to list the goals that the project will and will not include. Gathering a list of requirements from customers is a great way to start. After the requirements are collected, the project manager and technical leader check the requirements list in detail. If you are in doubt about certain requirements, you should put them on the excluded list, at least initially. The customer then checks the list again and corrects any objections. Finally, know that everyone agrees that the list correctly represents all the goals that the project should contain.

It needs to be emphasized again that the list needs to be detailed enough to be able to list those that are included in the project and those that are not. Indeed, it is important to detail requirements that are beyond the scope of the project. Goals that do not provide enough information to define the project scope will increasingly become a point of contention as the project release date approaches. For example, how will the various parts of the migration work be delivered to the migration team---is it delivered in multiple iterations or in one go? Is each delivery delivered as a phase, or are there smaller pieces of work included in that phase? How many iterations are there in a complete project? This list not only defines the project itself, but also lists the desired outcomes for all relevant stakeholders of the project.

The following are some basic principles that need to be followed when creating a project goal list:

1. Define the project scope in as much detail as possible.

2. Confirm that all relevant project stakeholders agree on the project scope.

3. List the unresolved content in the "Not included/Not in scope" list until all are resolved.

Part of defining project goals is listing the project's acceptance and completion criteria. All project stakeholders must agree on the project completion criteria. Project completion may refer to the percentage of system tests that passed on the Linux/Windows platform, or passing a certain performance standard set by the system performance - that is, the project goal is to run a specific set of test cases Or performance analysis. Regardless of how the project completion criteria are defined, if possible, all project stakeholders must understand and agree to these criteria before migration begins. Any changes to the standard during the migration process must be negotiated and approved by all relevant stakeholders before replacing the existing standard.

The above is the content of migrating .NET applications to .NET Core (1). For more related content, please pay attention to the PHP Chinese website (www.php.cn)!