.NET アプリケーションを .NET Core に移行する (1)

この記事では、アプリケーションの移行プロセスを紹介します。

特定のオペレーティング システムおよびハードウェア構造で実行されているソフトウェアを、新しいプラットフォームで実行できるように、別のオペレーティング システムおよびハードウェア構造で (必要な変更を含む) 再コンパイルします。このプロセスは、アプリケーションの移植と呼ばれます。場合によっては、アプリケーションをあるプラットフォームから別のプラットフォームに移植することは、再コンパイルして検証テストを実行するだけで簡単に行えます。しかし、移植手順がそれほど簡単ではない場合もあります。

この章は、アプリケーションの移植に関する現在のプロジェクト管理の補足です。今日のプロジェクト マネージャーは、正式な要件管理プロセスの使用方法、ソフトウェア開発者とのより適切なコミュニケーション方法、およびプロジェクトの管理方法についてすでに学習しています。しかし、結局のところ、ソフトウェア開発とソフトウェア移植はまったく同じではありません。それがこの章の内容です。

この章では、ソフトウェア移行の詳細なプロセスと技術的リスクに焦点を当て、一貫した高品質のアプリケーションを実現するためのいくつかの習慣と方法をリストします。

ソフトウェア プログラムのビジネス プロセス

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ソフトウェア プログラムのビジネス プロセスは、このアプリケーションのライフ サイクル中に影響を受けます。新しいプラットフォーム、新しいテスト環境、新しいツール、新しいドキュメントをサポートする必要があり、そして最も重要なことに、新しい顧客をサポートし、顧客関係を構築する必要があるため、影響を受けるビジネス プロセスは、移行されたアプリケーションに対応するように変更する必要があります。命 アプリケーションのライフサイクルでは、ビジネス プロセスの 3 つの主要な領域、つまり、

開発とテスト、カスタマー サポート、およびアプリケーション リリースが開発およびテストされます。開発およびテスト部門では、開発テスターは次の分野で Linux/Windows スキルをテストする必要があります: アプリケーション プログラミング インターフェイス (API) の違い、開発ツール、デバッグ機能、パフォーマンス ツール、移植するアプリケーションの要件 サードパーティソフトウェア。

カスタマーサポート。カスタマー サポート部門では、サポート担当者が次の分野のトレーニングを受ける必要があります: Linux/Windows システム管理、移植されたアプリケーションに必要なサードパーティ ソフトウェア、インストールと管理方法、Linux/Windows 環境でのパッケージ管理ツール、デバッグ ツールと方法、その他必要なもの。

アプリリリース。アプリケーション公開部門では、営業スタッフと技術コンサルタントは、Linux/Windows の全体的な機能と知識についてトレーニングを受ける必要があります。ソフトウェア リリース チャネルの担当者は、Linux/Windows ソフトウェア プログラムのトレーナーになるためのトレーニングを受ける必要があります。顧客の観点から見ると、Linux/Windows の統合に関する知識を得て、Linux/Windows を既存の IT システムと統合できるようになることも望んでいます。

.NET アプリケーション アプリケーションを .NETCore プラットフォームに移行するということは、新しく移植されたアプリケーションによって影響を受ける可能性のあるビジネス組織プロセスを変更することを意味します。これら 3 つの主要な側面は、実際の移行を開始する前に慎重に検討し、移行プロジェクト全体に含める必要があります。

移植プロセス 移 移植プロジェクトに参加している開発者は、移植時に同様の手順に従うことができます。これらの手順には、調査、分析、移植、テストが含まれます。プロセスの各ステップは次のステップの基礎となります。各ステップを適切に実行すると、その後のステップを簡単に完了できます。

調査

「調査」 このステップでは主に、プロジェクト マネージャーが移植専門家 (アプリケーションの経験があり、オープン ソース プラットフォーム、ターゲット プラットフォーム、アプリケーションで使用されるサードパーティ製品をよく理解しているソフトウェア開発者) を招集し、特定の専門家を招集します。分野の専門家が協力して、移植するアプリケーションが依存する製品、開発およびテスト環境を決定します。調査段階で明らかにすべき重要な事項には、製品/ソフトウェアの依存関係、開発環境コンポーネント、コンパイル環境コンポーネント、テスト環境コンポーネントなどがあります。

製品/ソフトウェアの依存関係。移植するアプリケーションが依存する製品を決定します。つまり、アプリケーションが使用するデータベース、ミドルウェア、サードパーティのクラス ライブラリなどのバージョンを決定します。依存する製品とバージョンがわかれば、移植専門家は、それらの製品とバージョンが .NET Core プラットフォームで利用できるかどうかを推定できます。

開発環境コンポーネント。開発環境の決定には、移植するアプリケーションをどのプログラミング言語で作成するかを決定することが含まれます。新しいプログラミング言語 (C# など) で書かれたアプリケーションは移植が簡単ですが、C/C++ で書かれたアプリケーションは分析と移植に時間がかかります。

コンパイル環境コンポーネント。コンパイル環境の決定には、必要なコンパイル ツールが Linux/Windows で利用できるかどうかの決定が含まれます。ソース プラットフォームで使用されるプラットフォーム固有のコンパイルおよびリンケージ フラグを調査して、対応するフラグが Linux/Windows に存在するかどうかを判断する必要があります。一部のコンパイル環境は元のプラットフォームに依存する場合があり、Linux に移植するにはさらに多くの労力が必要になる場合があります。

環境コンポーネントをテストします。移植されたアプリケーションに使用するテスト環境を決定すると、テスターが考慮すべきいくつかの問題が生じます。通常、移植エンジニアは移植する部分の単体テストのみを行い、その後、より完全な検証とシステム テストのためにプログラムをテスト チームに引き渡します。しかし、テストグループとは誰でしょうか?

ほとんどの場合、「調査」ステップでは、プロジェクト開始後に遭遇する可能性のあるいくつかのリスクも明らかにします。調査段階で特定できるリスクは次のとおりです。

必要なデータベース、ミドルウェア、依存するサードパーティ アセンブリが .NET Core では利用できません。

アプリケーションには、Linux アセンブリ命令に変換する必要があるアセンブリ ルーチンがいくつか含まれています。

アプリケーションは、ソース プラットフォームに固有の API またはプログラミング モデルを使用します。これには、プログラムを作成する際の文字の大文字とエンディアンに関する前提条件も含まれます。

アプリケーションは、.NET の特定のバージョンに従って作成され、この標準の実装は、元のプラットフォーム上の固有のコンパイラーに依存します。

テスト環境には、複雑なクライアント/サーバー アーキテクチャが必要です。

開発環境にはサードパーティのツールが必要であり、.NET Core に移植する必要があります。

アプリケーションの公開またはインストールには、ソース プラットフォームに固有のツールが必要です。

「調査」ステップでは、あらゆる新しい情報に注意を払う必要があります。これらの情報は、ドキュメント、パッケージ化、パフォーマンスのチューニングなどに関する質問など、いくつかの質問をすることで入手できます。

分析

「分析」 このステップは、プロジェクト管理と移植という 2 つの観点から検討する必要があります。プロジェクト管理の観点から見ると、分析とは、前のステップで特定されたさまざまな移行の問題とリスクを評価し、それらがプロジェクトの移行にどのような影響を与えるかを評価することです。 「分析」ステップには、プロジェクトの範囲と目標の決定、作業スケジュールの作成、リソースの取得、プロジェクトの役割の割り当てなど、プロジェクト計画の作成が含まれます。

プロジェクトの範囲と目標を決定すると、プロジェクトマネージャーとチームメンバーの責任の範囲と責任の範囲も定義されます。プロジェクトスコープとは、プロジェクトによって完了する一連の作業を指します。たとえば、「アプリケーション ABC のモジュール A をプラットフォーム B に移植し、プラットフォーム B でテストする必要がある」のような単純なステートメントは、プロジェクトの範囲を定義する良い例です。

プロジェクトの範囲が定義された後、移植作業の具体的なタスクを定義でき、作業を詳細に分類したスケジュールが生成されます。スケジュールは、どのような作業を実行する必要があるか、またそれを順次に実行できるか並行して実行できるかを判断するのに役立ちます。さらに、スケジュールには必要なリソースがリストされます。プロジェクトのタスクと必要なリソースを定義することで、完全なスケジュールを取得できます。移植の観点から見た「分析」のステップは、移植エンジニアがアプリケーションの構造を詳細に分析することです。移植エンジニアは、アプリケーションで使用される API とシステム コールを決定し、アプリケーションで使用される動的リンクと読み込み、ネットワーク、スレッドなどを評価する必要があります。この情報は分析されてプロジェクト マネージャーにフィードバックされ、プロジェクト マネージャーはより詳細なタスクを決定し、より正確な計画を作成します。植 Transplantation

「Transplantation」は移植のステップです。前のステップで得られた作業スケジュールに基づいて、移行エンジニアは連続的に作業することしかできない場合があります。これは主に、移植されるプログラムが密結合している可能性があるためです。言い換えれば、アプリケーションの 1 つのモジュールは他のモジュールに大きく依存しており、それらの依存モジュールの移植が完了した後でのみ、これらのモジュールを移植できます。代表的な例はコンパイル環境の移植です。元のコンパイル環境がアプリケーション全体を一度にコンパイルするように設計されている場合は、移行作業の前に、各モジュールが依存する共通構成ファイルを変更する必要があります。

ピギングは、互いに関連性がない場合には並行して実行されます。疎結合モジュールの移植は、複数のエンジニアが分割して同時に行うことができます。典型的な例は、共有ライブラリの移植です。このような共有ライブラリは相互に影響を与えず、独立してコンパイルでき、他のモジュールによってコンパイルとリンクのためにのみ使用されます。どのような作業を並行して実行できるかを決定することは重要であり、分析フェーズで行う必要があります。

.NET Core でコードをコンパイルする作業には、コードのアーキテクチャへの依存関係や、コードの検査や移植可能なデータ構造やコーディング標準の使用などの非標準的なプログラミング習慣の特定と削除が含まれます。経験豊富で品質を意識した移植エンジニアが、後者をチェックしながらコンパイル エラーを修正します。

移植作業には、Linux/Windows プラットフォームへのコンパイル環境の移植も含まれます。これは調査段階で明確にする必要があります。コンパイル環境には移植可能なものもありますが、そうでないものもあります。コンパイル環境が潜在的な問題を引き起こさないことを確認することは見落とされやすい作業であり、非常に慎重な調査と分析が必要です。

アプリケーションの移植が完了したら (つまり、.NET Core でのコンパイルが完了したら)、移植エンジニアは、移植されたアプリケーションに対して単体テストを実行する必要があります。たとえば、単体テストは非常に簡単で、プログラムを実行して実行時エラーが発生するかどうかを確認できます。実行時エラーが発生した場合は、アプリケーションをテスト チームに渡す前にそれらのエラーを修正する必要があります。この場合、テスト チームはプログラムのより完全なテストを実施します。

テスト

テスト プロセス中、指定されたテスターは、移植されたアプリケーションでいくつかのテスト ケースを実行します。これらのテスト ケースには、アプリケーションを実行するだけの単純なテストから、NET Core プラットフォームでのアプリケーションの堅牢なテストまで、さまざまなテスト目的があります。十分。ターゲット プラットフォームでアプリケーションのストレス テストを行うと、アーキテクチャの依存関係や悪いコーディング習慣を超えた問題を発見できる可能性があります。ほとんどのアプリケーション、特にマルチスレッドのアプリケーションは、異なるプラットフォームでストレス テストを行うと動作が異なる傾向があります。これは、オペレーティング システムの実装、特にスレッド実装の違いが原因の 1 つです。テスト中に問題が発見された場合、移行エンジニアはそれらをデバッグして解決する必要があります。一部のアプリケーションには、アプリケーションをテストするためのテスト ツールのセットの移植も含まれます。テスト ツールの移行も、調査とテストの段階で決定する必要があるタスクです。ほとんどの場合、テスターはアプリケーションをテストする前に、アプリケーションに関するトレーニングを受ける必要があります。アプリケーションの学習は、移植作業とは完全に独立したタスクであり、移植タスクと並行して行うことができます。問題をテストした後、これらの問題を解決してアプリケーションを再コンパイルし、アプリケーションがすべてのテスト ケースに合格するまで問題を再テストする必要があります。

サポート

移植作業が完了すると、開発フェーズが終了し、サポートフェーズが始まります。数人の移植エンジニアが常駐し、お客様の継続的な質問にお答えします。さらに、開発者は、Linux/Windows プラットフォーム上でアプリケーションを構成および実行する方法について顧客をトレーニングする必要もあります。移植後、サポート期間は通常 60 ～ 90 日間続きます。この期間中、移行エンジニアは、新しく .NET Core に移植されたアプリケーションについてテクニカル サポート スタッフと営業スタッフをトレーニングし、質問に答えました。研修終了後、移植技師の仕事は終了です。

プロジェクトのスコープと目標を定義する

プロジェクトのスコープを定義すると、プロジェクトのエンドポイントと境界、およびプロジェクトマネージャーとプロジェクトメンバーの責任を明確に定義します。明確に定義されたプロジェクトの範囲により、プロジェクトのすべての利害関係者 (プロジェクト チーム、アーキテクト、テスター、顧客またはスポンサー、協力部門など、プロジェクトに関与する、またはプロジェクトの影響を受ける人や組織) が、プロジェクトについて明確に理解できるようになります。プロジェクトの目標。

プロジェクトの目標や要件を明確にすると、プロジェクトの範囲をより深く理解できるようになります。移行プロセスの分析フェーズでは、クライアントの目標と要件が収集され、構造に分割され、最終的にプロジェクトの成果物として定義されます。プロジェクトの目標と要件は、プロジェクトの範囲を定義するための出発点です。プロジェクトの目標がすべて決定されると、プロジェクトの範囲がより明確になります。

プロジェクトの範囲を定義する 1 つの方法は、プロジェクトに含まれる目標と含まれない目標をリストすることです。顧客から要件のリストを収集することは、始めるのに最適な方法です。要件が収集された後、プロジェクトマネージャーと技術リーダーは要件リストを詳細に確認します。特定の要件に疑問がある場合は、少なくとも最初は除外リストに入れておく必要があります。その後、顧客はリストを再度確認し、異論があれば修正します。最後に、このリストがプロジェクトに含まれるべきすべての目標を正しく表していることに全員が同意していることを知っておいてください。

繰り返しになりますが、プロジェクトに含まれるものと含まれないものをリストできるように、リストは十分に詳細である必要があります。実際、プロジェクトの範囲を超えた要件を詳しく説明することが重要です。プロジェクトの範囲を定義するのに十分な情報が提供されていない目標は、プロジェクトのリリース日が近づくにつれて争点になります。たとえば、移行作業のさまざまな部分はどのようにして移行チームに提供されますか? 複数回の反復で提供されるのでしょうか、それとも一度に提供されるのでしょうか?各納品はフェーズとして納品されますか、それともそのフェーズには小さな作業が含まれますか?完全なプロジェクトには何回の反復が必要ですか?このリストには、プロジェクト自体を定義するだけでなく、プロジェクトのすべての関係者にとって望ましい結果もリストされます。

以下は、プロジェクト目標リストを作成する際に従う必要があるいくつかの基本原則です:

1. プロジェクトの範囲をできるだけ詳細に定義します。

2. プロジェクトの関係者全員がプロジェクトの範囲に同意していることを確認します。

3. すべてが解決されるまで、未解決のコンテンツを「含まれない/範囲外」リストにリストします。

プロジェクトの目標を定義する一環として、プロジェクトの承認と完了の基準を概説することが含まれます。プロジェクトの関係者全員がプロジェクトの完了基準に同意する必要があります。プロジェクトの完了とは、Linux/Windows プラットフォームで合格したシステム テストの割合、またはシステム パフォーマンスによって設定された特定のパフォーマンス標準に合格したことを指します。つまり、プロジェクトの目標は、特定のテスト ケースまたはパフォーマンス分析のセットを実行することです。プロジェクトの完了基準がどのように定義されているかに関係なく、可能であれば、移行を開始する前に、すべてのプロジェクト関係者がこれらの基準を理解し、同意する必要があります。移行プロセス中に標準に変更を加える場合は、既存の標準を置き換える前に、関連するすべての関係者によって交渉および承認される必要があります。

上記は .NET アプリケーションを .NET Core に移行する (1) の内容です。さらに関連する内容については、PHP 中国語 Web サイト (www.php.cn) に注目してください。