. NET application to. NET Core (i)

This article describes a process for applying migration.

The process of putting a software running on one operating system and hardware structure, recompiling on another operating system and hardware structure (including some necessary modifications) to run on a new platform is called application porting. In some cases, porting an application from one platform to another is straightforward, and requires only recompiling and some validation tests. But in some cases, porting the program is not that easy.

This chapter complements the current project management in terms of application porting, how to use the formalized requirements management process, how to better communicate with software developers, and how to manage the project, and today's project managers are very familiar with it, but after all, software development and software porting are not exactly the same, This is what this chapter is going to tell you.

This chapter focuses on the detailed process and technical risks of software porting, and lists some of the habits and methods that are consistent with achieving high-quality applications.

Software program Business Process

Before starting a porting project, it is important to understand that the business processes will be impacted during the life cycle of the application. The affected business processes have to be modified to accommodate the migrated applications because of the need to support new platforms, new test environments, new tools, new documents, and most importantly, the need to support new customers and build customer relationships.

In the life cycle of an application, the three main areas that may affect the business process are development and testing, customer support, and application publishing:

Development and testing. In the development and testing department, development testers must be tested for linux/windows skills in the following areas: differences in application programming interfaces (APIs), Development tools, debugging feature based, performance tools, and third-party software required for applications to be ported.

Customer Support. In customer support, support personnel must be trained in linux/windows system management, third-party software required for migrated applications, installation and management methods, package management tools in the Linux/windows environment, debugging tools and methods, and other content required.

Application Publishing. In the application publishing department, salespeople and technical advisors must be trained in the overall characteristics and knowledge of the linux/windows. For software distribution channel personnel, it must be trained to become Linux/windows software program trainers. From a customer's point of view, they also want to gain knowledge of linux/windows integration, together with the ability to integrate linux/windows with their existing IT systems.

. NET application porting application to the. Netcore platform also means modifying the business organization process that may be impacted by the newly ported application. These three major aspects should be carefully considered before the actual transplant begins, and will be included in the entire porting project process.

Porting process

Developers who are involved in porting projects can follow similar steps when porting any project. These steps include: investigation, analysis, porting, and testing. Each step in the process is the foundation of the latter step. Each step is done well, and the subsequent steps will be easy to complete.

Investigation

The "survey" step is primarily for the project manager to summon the transplant specialists (who are more experienced in the application and the software developers who are more knowledgeable about the open source platform, the target platform, and the third-party product used by the application) and the experts in a field to identify the product, development, and test environment on which the application is to be migrated. Several key elements to be identified during the investigation phase include: Product/software dependencies, development environment components, compiled environment components, and test environment components.

Product/software dependencies. Identify the product on which the application is to be migrated, that is, to determine the application that uses that version of the database, middleware, and third-party class libraries. Knowing what products and versions depend on, migration experts can estimate whether they have these products and versions on the. NET core platform.

Development environment components. Determine which programming language is used in the development environment, including determining which application to migrate. Applications written with newer programming languages, such as C #, are easier to migrate, but applications written in C + + languages take more time to parse and migrate.

Compile the environment component. Determining the compilation environment includes determining whether the required compilation tools are available on linux/windows. The compilation and link flags associated with the platform used on the source platform must be investigated to determine if a corresponding flag exists on the linux/windows. Some compilation environments may be dependent on the original platform, which may take more effort to migrate to Linux.

Test environment components. Determining the test environment used by the migrated application introduces some of the issues that testers should be concerned about. Typically, transplant engineers only do unit tests on the part of their transplant, and then give the program to the test team for more complete validation and system testing. But who is the test group?

In most cases, the "survey" step also clarifies some of the risks that may be encountered when a project starts. The risks that can be identified during the investigation phase are as follows:

Required databases, middleware, and dependent third-party assemblies are not available on. NET Core.

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

The application uses a source platform-specific API or programming model. This also includes assumptions about letter capitalization and byte ordering when writing programs.

Application is followed by the. NET, and the implementation of this standard depends on the compiler that is unique to the original platform.

A test environment requires a complex client/server architecture.

The development environment requires a third-party tool that needs to be ported to. NET Core.

Application publishing or installation requires a unique tool for the source platform.

The "survey" step requires attention to each new information that can be obtained by asking questions such as documentation, packaging, performance tuning, and so on.

Analysis

The "analysis" step needs to be considered from two perspectives: project management and porting. From a project management perspective, analysis is an assessment of the various migration issues and risks identified in the previous step, and how they affect the migration of the project. The "analysis" step is to develop a project plan that includes determining the scope and objectives of the project, creating a work schedule, acquiring resources, and assigning project roles.

Determining the scope and objectives of a project also defines the scope and responsibilities of the project manager and team members. Project scope refers to a series of work to be done by the project. For example, a simple statement such as "application ABC module a needs to be ported to platform B and tested on B" is a good example of defining the scope of the project.

After the scope of the project is defined, the specific tasks of the porting work can be defined, which results in a schedule for the detailed classification of the work. The schedule can help determine what needs to be done and whether the work is done sequentially or in parallel. In addition, the schedule lists the resources that are required. A complete schedule can be obtained by defining the project tasks and the required resources.

From the point of view of migration, the "analysis" step is that the transplant engineer analyzes the application structure in detail. The porting engineer determines the API and system calls used by the application, and evaluates the dynamic links and mounts, networks, threads, and so on used by the application. The analysis gets this information back to the project manager, where the project manager identifies more detailed tasks and develops more accurate plans.

Transplantation

The "porting" step is that the transplant engineer begins to perform the specific work assigned to them. Based on the work breakdown from the previous step, the transplant engineer may only work serially. This is mainly because the program to be ported may be tightly coupled. In other words, one module of an application is highly dependent on other modules, and only those modules that are dependent are migrated to begin porting. A typical example is the porting of the build environment. If the original compilation environment is designed to compile the entire application at once, then you must modify the common configuration file on which the modules depend before any porting work.

If the porting work is not related to each other, the migration can be done in parallel. The porting of loose-coupling modules can be separated to allow different engineers to perform simultaneously. A typical example is the porting of shared libraries, where shared libraries have no effect on each other and can be compiled independently of each other, and are only used by other modules to compile links. It is important to determine which work can be done in parallel, and this work should be done in the analysis phase.

The work of compiling code on. NET core involves identifying and eliminating the dependencies of the Code on the architecture, as well as non-standard programming practices, including examining the code and using portable data structures or coding standards. Experienced and quality-conscious transplant engineers will correct compilation errors while checking the latter.

Porting work also includes porting the build environment to the Linux/windows platform. The work should be clarified at the investigation stage. Some of the compilation environments are portable, but some are not. Verifying that the compilation environment does not cause potential problems is easily overlooked and requires very careful investigation and analysis.

After the application migration is completed (that is, compiled on. NET core), the porting engineer needs to unit-test the migrated application. Unit tests can be simple, such as simply running a program to see if a run-time error is generated, and if a run-time error is generated, these errors need to be modified before the application is delivered to the test group. How, the test group will test the program more thoroughly.

Test

During testing, the specified testers run a number of test cases against the migrated application, which have different testing purposes, from simple tests that simply run the application to testing the application's strong enough stress test on the. NET core platform. Stress testing the application on the target platform reveals issues that are beyond the architectural dependencies and bad coding habits. Most applications, especially multi-threaded programs, tend to behave differently when performing stress tests on different platforms, in part because of different operating system implementations, especially for different threads. If a problem is found during testing, the transplant engineer should debug and resolve the problem.

Some application porting also includes porting a set of test tools to test the application. The porting test tool is also a task that should be identified during the investigation and testing phases. In most cases, testers often need to undergo some training of the application in order to test the application. The learning application is a completely separate task from the porting effort and can be performed in parallel with the migration task.

After the test discovers the problem, you need to resolve these issues and recompile the application, and then re-test the problem until the application passes through all the test cases.

Support

When the migration is complete, the development phase is finished, and the support phase begins. Some transplant engineers will stay to help answer the questions that the customer may have been asked about. In addition, developers should also train customers on how to configure and run applications on the Linux/windows platform. At the end of the migration, the support phase typically lasts for 60-90 days. During this time, the porting engineer trained technical support and sales staff on the newly ported applications to. NET core, and answered questions they asked. After the training is completed, the transplant engineer's work is completed.

Define project scope and objectives

Defining the project scope is defining the end points and boundaries of the project, as well as the responsibilities of the project manager and project members. A well-defined project scope ensures that all stakeholders in the project (the people or organizations involved in the project or affected by the project, such as project teams, architects, testers, customers or sponsors, partner departments, etc.) are clear about the project's objectives.

Clear project objectives or requirements can give a better understanding of the scope of the project. During the analysis phase of the transplant process, the customer's goals and requirements are collected, then subdivided into individual structures and ultimately defined as deliverables for the project. The project's goals and requirements are the starting point for defining the scope of the project. The scope of the project becomes clearer after all the project objectives have been determined.

One way to define the scope of a project is to list the targets to be included and not included in the project. Collecting a list of requirements from a customer is a good way to start. After the requirements are collected, the project manager and technical leaders examine the requirements list in detail. If you have questions about certain requirements, you should include them in the list of targets that are not included, at least initially. The customer then checks the list again and corrects the objection. Finally, know that all people believe that the list has correctly stated all the goals that the project should contain.

Again, it needs to be emphasized that the list needs to be detailed enough to be able to list those that are to be included in the project, and those that do not. Indeed, it is also important to have detailed descriptions of the requirements beyond the scope of the project. The goal of defining the scope of the project that does not provide enough information will gradually become the focus of contention as the project's release date approaches. For example, how does the migration work to the transplant team---multiple iterations or one-time delivery? Is there a stage in each delivery, or is there some smaller work to be included in this phase? How many iterations are there in a complete project? The list not only defines the project itself, but also lists the results that all stakeholders of the project expect.

Here are some basic principles to follow when creating a project target list:

1. Define the scope of the project as detailed as possible.

2. Confirm that all relevant stakeholders in the project agree to the scope of the project.

3. The unresolved content is listed in the "not included/not in range" list until all is resolved.

Part of defining project objectives is to list the criteria for receiving and completing the project. All project stakeholders must agree on the completion criteria of the project. Project completion may refer to the number of system tests passed on the Linux/windows platform, or a performance criterion set by the performance of the system-that is, the project objective is to run a specific set of test cases or performance analyses. Regardless of the criteria for project completion, if possible, all stakeholders must understand and agree to these criteria before the transplant begins. Any changes to the standard in the transplant process prior to replacing the existing standards must be communicated and approved by all relevant stakeholders.

The above is. NET app to. NET Core (i), please follow topic.alibabacloud.com (www.php.cn) for more information!

