.NET 애플리케이션을 .NET Core로 마이그레이션(1)

이 글에서는 애플리케이션 마이그레이션 과정을 소개합니다.

특정 운영 체제 및 하드웨어 구조에서 실행되는 소프트웨어를 다른 운영 체제 및 하드웨어 구조에서 다시 컴파일합니다(일부 필요한 수정 포함). 새로운 플랫폼에서 실행하기 위한 이 프로세스를 애플리케이션 이식이라고 합니다. 어떤 경우에는 한 플랫폼에서 다른 플랫폼으로 애플리케이션을 포팅하는 것이 일부 확인 테스트를 다시 컴파일하고 수행하는 것만큼 간단합니다. 하지만 이식절차가 그리 쉽지 않은 경우도 있습니다.

이 장은 애플리케이션 이식에서 현재 프로젝트 관리에 대한 보충 자료입니다. 공식화된 요구 사항 관리 프로세스를 사용하는 방법, 소프트웨어 개발자와 더 효과적으로 소통하는 방법, 오늘날의 프로젝트 관리자는 이미 프로젝트를 관리하는 방법에 대해 설명합니다. 매우 익숙하지만 소프트웨어 개발과 소프트웨어 포팅은 완전히 동일하지는 않습니다. 이것이 바로 이 장의 내용입니다.

이 장에서는 소프트웨어 마이그레이션의 세부 프로세스와 기술적 위험에 중점을 두고 일관된 고품질 애플리케이션을 달성하기 위한 몇 가지 습관과 방법을 나열합니다.

소프트웨어 프로그램 비즈니스 프로세스

포팅 프로젝트를 시작하기 전에 애플리케이션 수명 주기 동안 어떤 비즈니스 프로세스가 영향을 받을지 이해하는 것이 중요합니다. 영향을 받는 비즈니스 프로세스는 새로운 플랫폼, 새로운 테스트 환경, 새로운 도구, 새로운 문서를 지원해야 하고 가장 중요한 것은 새로운 고객을 지원하고 고객 관계를 구축해야 하기 때문에 마이그레이션된 애플리케이션을 수용하도록 수정되어야 합니다.

애플리케이션 수명 주기 동안 비즈니스 프로세스에 영향을 미칠 수 있는 세 가지 주요 영역은 개발 및 테스트, 고객 지원, 애플리케이션 릴리스입니다.

개발 및 테스트. 개발 및 테스트 부서에서 개발 테스터는 다음 영역에서 Linux/Windows 기술을 테스트해야 합니다. API(응용 프로그래밍 인터페이스) 차이점, 개발 도구, 디버깅 기능, 성능 도구 및 이식할 응용 프로그램의 요구 사항 타사 소프트웨어.

고객 지원. 고객 지원 부서에서는 지원 담당자가 Linux/Windows 시스템 관리, 포팅된 애플리케이션에 필요한 타사 소프트웨어, 설치 및 관리 방법, Linux/Windows 환경의 패키지 관리 도구, 디버깅 도구 및 방법에 대한 교육을 받아야 합니다. 및 기타 필요한 사항.

앱 출시. 애플리케이션 게시 부서에서는 영업 직원과 기술 컨설턴트가 전반적인 Linux/Windows 기능 및 지식에 대한 교육을 받아야 합니다. 소프트웨어 릴리스 채널 직원은 Linux/Windows 소프트웨어 프로그램의 트레이너가 되도록 교육을 받아야 합니다. 고객의 관점에서 그들은 Linux/Windows 통합에 대한 지식을 얻고 Linux/Windows를 기존 IT 시스템과 통합할 수 있기를 바랍니다.

.NET 애플리케이션 애플리케이션을 .NETCore 플랫폼으로 포팅한다는 것은 새로 포팅된 애플리케이션의 영향을 받을 수 있는 비즈니스 조직 프로세스를 수정한다는 것을 의미합니다. 실제 마이그레이션을 시작하기 전에 이러한 세 가지 주요 측면을 신중하게 고려해야 하며 전체 마이그레이션 프로젝트 전반에 걸쳐 포함되어야 합니다.

포팅 프로세스

프로젝트 포팅에 관련된 개발자는 프로젝트 포팅 시 유사한 단계를 따를 수 있습니다. 이러한 단계에는 조사, 분석, 이식 및 테스트가 포함됩니다. 프로세스의 각 단계는 다음 단계의 기초입니다. 각 단계를 잘 수행하면 다음 단계도 쉽게 완료할 수 있습니다.

조사

"조사" 단계는 주로 프로젝트 관리자가 이식 전문가(응용 분야 경험이 더 많음)를 소환하고 사용된 오픈 소스 플랫폼, 대상 플랫폼 및 타사 제품을 비교하는 것입니다. 응용 프로그램) 소프트웨어 개발자) 및 특정 분야의 전문가가 포팅할 응용 프로그램이 의존하는 제품, 개발 및 테스트 환경을 결정합니다. 조사 단계에서 명확히 해야 할 몇 가지 주요 사항에는 제품/소프트웨어 종속성, 개발 환경 구성 요소, 컴파일 환경 구성 요소 및 테스트 환경 구성 요소가 포함됩니다.

제품/소프트웨어 종속성. 이식할 애플리케이션이 의존하는 제품, 즉 애플리케이션이 사용하는 데이터베이스, 미들웨어, 타사 클래스 라이브러리 등의 버전을 결정합니다. 포팅 전문가는 의존하는 제품과 버전을 알면 해당 제품과 버전을 .NET Core 플랫폼에서 사용할 수 있는지 여부를 추정할 수 있습니다.

개발 환경 구성요소. 개발 환경 결정에는 이식할 애플리케이션을 어떤 프로그래밍 언어로 작성할지 결정하는 것이 포함됩니다. 최신 프로그래밍 언어(예: C#)로 작성된 애플리케이션은 이식하기가 더 쉽지만 C/C++로 작성된 애플리케이션은 분석 및 이식에 더 많은 시간이 필요합니다.

컴파일 환경 구성요소. 컴파일 환경 결정에는 필요한 컴파일 도구가 Linux/Windows에서 사용 가능한지 여부 결정이 포함됩니다. 소스 플랫폼에서 사용되는 플랫폼별 컴파일 및 링크 플래그를 조사하여 해당 플래그가 Linux/Windows에 존재하는지 확인해야 합니다. 일부 컴파일 환경은 원래 플랫폼에 의존할 수 있으므로 Linux로 이식하려면 더 많은 노력이 필요할 수 있습니다.

테스트 환경 구성요소. 포팅된 애플리케이션에 사용할 테스트 환경을 결정하면 테스터가 주의해야 할 몇 가지 문제가 발생합니다. 일반적으로 포팅 엔지니어는 포팅하는 부품에 대해서만 단위 테스트를 수행한 다음 보다 완전한 검증 및 시스템 테스트를 위해 프로그램을 테스트 팀에 넘겨줍니다. 그런데 테스트 그룹은 누구입니까?

대부분의 경우 '조사' 단계에서는 프로젝트 시작 후 발생할 수 있는 일부 위험도 명확하게 밝혀집니다. 조사 단계에서 식별할 수 있는 위험은 다음과 같습니다.

필수 데이터베이스, 미들웨어 및 종속 타사 어셈블리는 .NET Core에서 사용할 수 없습니다.

애플리케이션에는 Linux 어셈블리 지침으로 변환해야 하는 일부 어셈블리 루틴이 포함되어 있습니다.

애플리케이션은 소스 플랫폼에 특정한 API 또는 프로그래밍 모델을 사용합니다. 여기에는 프로그램 작성 시 대소문자 및 엔디안에 대한 가정도 포함됩니다.

애플리케이션은 특정 버전의 .NET에 따라 작성되었으며 이 표준의 구현은 원래 플랫폼의 고유한 컴파일러에 의존합니다.

테스트 환경에는 복잡한 클라이언트/서버 아키텍처가 필요합니다.

개발 환경에는 .NET Core로 이식해야 하는 타사 도구가 필요합니다.

애플리케이션을 게시하거나 설치하려면 소스 플랫폼에 고유한 도구가 필요합니다.

"조사" 단계에서는 모든 새로운 정보에 주의를 기울여야 하며, 이는 문서, 패키징, 성능 튜닝 등에 대한 질문을 통해 얻을 수 있습니다.

분석

'분석' 단계는 프로젝트 관리와 이식이라는 두 가지 관점에서 고려해야 합니다. 프로젝트 관리 관점에서 분석은 이전 단계에서 식별된 다양한 마이그레이션 문제와 위험을 평가하고 이것이 프로젝트 마이그레이션에 미치는 영향을 평가하는 것입니다. "분석" 단계에는 프로젝트 범위 및 목표 결정, 작업 일정 작성, 자원 확보, 프로젝트 역할 할당 등 프로젝트 계획 개발이 포함됩니다.

프로젝트의 범위와 목표를 결정하면 프로젝트 관리자와 팀원의 책임 범위와 책임도 정의됩니다. 프로젝트 범위는 프로젝트가 완료해야 하는 일련의 작업을 나타냅니다. 예를 들어, "애플리케이션 ABC의 모듈 A를 플랫폼 B로 이식하고 플랫폼 B에서 테스트해야 합니다"와 같은 간단한 문은 프로젝트 범위를 정의하는 좋은 예입니다.

프로젝트 범위가 정의되면 이식 작업의 구체적인 작업을 정의할 수 있으며, 이를 통해 작업을 세부적으로 분류하여 일정을 생성할 수 있습니다. 일정은 수행해야 할 작업과 해당 작업을 순차적으로 수행할 수 있는지 아니면 병렬로 수행할 수 있는지 결정하는 데 도움이 될 수 있습니다. 또한 일정에는 필요한 리소스가 나열되어 있습니다. 프로젝트 작업과 필요한 자원을 정의하여 전체 일정을 얻을 수 있습니다.

이식의 관점에서 '분석' 단계는 이식 엔지니어가 애플리케이션의 구조를 자세히 분석하는 단계입니다. 포팅 엔지니어는 애플리케이션에서 사용하는 API와 시스템 호출을 결정하고 애플리케이션에서 사용하는 동적 연결 및 로딩, 네트워크, 스레드 등을 평가해야 합니다. 이 정보는 분석되어 프로젝트 관리자에게 피드백되며, 프로젝트 관리자는 보다 세부적인 작업을 결정하고 보다 정확한 계획을 개발합니다.

이식

“이식” 이 단계는 이식 엔지니어가 자신에게 할당된 특정 작업을 수행하기 시작하는 단계입니다. 이전 단계에서 도출된 작업 일정에 따라 마이그레이션 엔지니어는 순차적으로만 작업할 수 있습니다. 이는 주로 포팅하려는 프로그램이 긴밀하게 결합되어 있을 수 있기 때문입니다. 즉, 애플리케이션의 한 모듈은 다른 모듈에 대한 의존도가 높습니다. 해당 종속 모듈의 이식이 완료된 후에만 해당 모듈을 이식할 수 있습니다. 대표적인 예가 컴파일 환경의 이식이다. 원래 컴파일 환경이 전체 애플리케이션을 한 번에 컴파일하도록 설계된 경우 마이그레이션 작업 전에 각 모듈이 의존하는 공통 구성 파일을 수정해야 합니다.

마이그레이션 작업이 서로 관련되지 않은 경우 마이그레이션을 병렬로 수행할 수 있습니다. 느슨하게 결합된 모듈의 포팅은 여러 엔지니어가 분할하여 동시에 수행할 수 있습니다. 일반적인 예는 공유 라이브러리의 이식입니다. 이러한 공유 라이브러리는 서로 영향을 미치지 않으며 독립적으로 컴파일할 수 있으며 컴파일 및 링크를 위해 다른 모듈에서만 사용됩니다. 병렬로 수행할 수 있는 작업을 결정하는 것은 중요하며 분석 단계에서 수행되어야 합니다.

.NET Core에서 코드를 컴파일하는 작업에는 코드 검사, 이식 가능한 데이터 구조 또는 코딩 표준 사용을 포함한 비표준 프로그래밍 습관뿐만 아니라 아키텍처에 대한 코드 종속성을 식별하고 제거하는 작업이 포함됩니다. 경험이 풍부하고 품질에 민감한 포팅 엔지니어가 컴파일 오류를 확인하면서 컴파일 오류를 수정합니다.

포팅 작업에는 컴파일 환경을 Linux/Windows 플랫폼으로 포팅하는 것도 포함됩니다. 이는 조사 단계에서 명확히 밝혀져야 합니다. 일부 컴파일 환경은 이식 가능하지만 일부는 그렇지 않습니다. 컴파일 환경이 잠재적인 문제를 일으키지 않는지 확인하는 것은 매우 신중한 조사와 분석이 필요한 간과되기 쉬운 작업입니다.

애플리케이션을 이식한 후(즉, .NET Core에서 컴파일) 이식 엔지니어는 이식된 애플리케이션에 대해 단위 테스트를 수행해야 합니다. 단위 테스트는 매우 간단할 수 있습니다. 예를 들어, 런타임 오류가 발생하는지 확인하기 위해 간단히 프로그램을 실행할 수 있습니다. 런타임 오류가 발생하면 애플리케이션을 테스트 팀에 전달하기 전에 이러한 오류를 수정해야 합니다. 이 경우 테스트 팀은 프로그램에 대한 보다 완전한 테스트를 수행합니다.

테스트

테스트 과정에서 지정된 테스터는 단순 테스트부터 스트레스 테스트까지 다양한 테스트 목적을 가지고 이식된 애플리케이션에 대해 테스트를 수행합니다. 애플리케이션이 .NET Core 플랫폼에서 충분히 견고한지 테스트하는 테스트입니다. 대상 플랫폼에서 애플리케이션을 스트레스 테스트하면 아키텍처 종속성 및 잘못된 코딩 습관 이상의 문제를 발견할 수 있습니다. 대부분의 응용 프로그램, 특히 다중 스레드 응용 프로그램은 다른 플랫폼에서 스트레스 테스트를 수행할 때 부분적으로 운영 체제 구현, 특히 스레드 구현이 다르기 때문에 다르게 동작하는 경향이 있습니다. 테스트 중에 문제가 발견되면 마이그레이션 엔지니어가 문제를 디버깅하고 해결해야 합니다.

일부 애플리케이션 포팅에는 애플리케이션을 테스트하기 위한 테스트 도구 세트 포팅도 포함됩니다. 테스트 도구 마이그레이션은 조사 및 테스트 단계에서 결정해야 하는 작업이기도 합니다. 대부분의 경우 테스터는 애플리케이션을 테스트하기 전에 애플리케이션에 대한 교육을 받아야 하는 경우가 많습니다. 애플리케이션 학습은 포팅 작업과 완전히 독립적인 작업이며 포팅 작업과 병행하여 수행할 수 있습니다.

테스트에서 문제가 발견되면 해당 문제를 해결하고 애플리케이션을 다시 컴파일한 다음 애플리케이션이 모든 테스트 사례를 통과할 때까지 문제를 다시 테스트해야 합니다.

지원

포팅 작업이 완료되면 개발 단계가 끝나고 지원 단계가 시작됩니다. 고객이 가질 수 있는 관련 질문에 답변하기 위해 몇 명의 마이그레이션 엔지니어가 대기하고 있습니다. 또한 개발자는 고객에게 Linux/Windows 플랫폼에서 애플리케이션을 구성하고 실행하는 방법을 교육해야 합니다. 이식 후 지지 단계는 일반적으로 60~90일 동안 지속됩니다. 이 기간 동안 마이그레이션 엔지니어는 .NET Core로 새로 이식된 애플리케이션에 대해 기술 지원 직원과 영업 직원을 교육하고 질문에 답변했습니다. 교육이 완료되면 이식 엔지니어의 작업이 완료됩니다.

프로젝트 범위 및 목표 정의

프로젝트 범위 정의는 프로젝트의 종료점과 경계, 프로젝트 관리자와 프로젝트 구성원의 책임을 명확하게 정의하는 것입니다. 명확하게 정의된 프로젝트 범위는 프로젝트의 모든 이해관계자(프로젝트 팀, 설계자, 테스터, 고객 또는 스폰서, 협력 부서 등 프로젝트에 참여하거나 프로젝트의 영향을 받는 사람 또는 조직)가 프로젝트에 대해 명확히 알 수 있도록 보장할 수 있습니다. 프로젝트의 목표.

명확한 프로젝트 목표나 요구 사항은 사람들이 프로젝트 범위를 더 잘 이해하는 데 도움이 될 수 있습니다. 마이그레이션 프로세스의 분석 단계에서 고객의 목표와 요구 사항이 수집되어 구조로 분류되고 궁극적으로 프로젝트 결과물로 정의됩니다. 프로젝트 목표와 요구사항은 프로젝트 범위를 정의하는 출발점입니다. 모든 프로젝트 목표가 결정되면 프로젝트 범위가 더욱 명확해집니다.

프로젝트 범위를 정의하는 한 가지 방법은 프로젝트에 포함될 목표와 포함되지 않을 목표를 나열하는 것입니다. 고객의 요구 사항 목록을 수집하는 것은 시작하는 좋은 방법입니다. 요구사항이 수집된 후 프로젝트 관리자와 기술 리더는 요구사항 목록을 자세히 확인합니다. 특정 요구 사항이 의심스러우면 적어도 초기에는 해당 요구 사항을 제외 목록에 추가해야 합니다. 그런 다음 고객은 목록을 다시 확인하고 이의가 있는 경우 수정합니다. 마지막으로, 목록이 프로젝트에 포함되어야 하는 모든 목표를 정확하게 나타낸다는 점에 모두가 동의한다는 점을 알아두세요.

다시 한번 말씀드리지만, 프로젝트에 포함된 것과 포함되지 않은 것을 나열할 수 있을 정도로 목록이 상세해야 합니다. 실제로 프로젝트 범위를 벗어나는 요구 사항을 자세히 설명하는 것이 중요합니다. 프로젝트 범위를 정의하기에 충분한 정보를 제공하지 않는 목표는 프로젝트 출시일이 다가올수록 논쟁거리가 될 것입니다. 예를 들어, 마이그레이션 작업의 각 부분이 마이그레이션 팀에 어떻게 전달됩니까? 여러 번 반복하여 전달됩니까, 아니면 한 번에 전달됩니까? 각 전달은 하나의 단계로 전달됩니까, 아니면 해당 단계에 더 작은 작업이 포함되어 있습니까? 전체 프로젝트에는 몇 번의 반복이 있습니까? 이 목록은 프로젝트 자체를 정의할 뿐만 아니라 프로젝트의 모든 관련 이해관계자가 원하는 결과도 나열합니다.

프로젝트 목표 목록을 작성할 때 따라야 할 몇 가지 기본 원칙은 다음과 같습니다.

1. 프로젝트 범위를 최대한 자세히 정의합니다.

2. 모든 관련 프로젝트 이해관계자가 프로젝트 범위에 동의하는지 확인합니다.

3. 모두 해결될 때까지 해결되지 않은 콘텐츠를 '포함되지 않음/범위에 포함되지 않음' 목록에 나열합니다.

프로젝트 목표 정의의 일부는 프로젝트 승인 및 완료 기준을 간략하게 설명하는 것입니다. 모든 프로젝트 이해관계자는 프로젝트 완료 기준에 동의해야 합니다. 프로젝트 완료는 Linux/Windows 플랫폼에서 통과한 시스템 테스트의 비율을 의미하거나 시스템 성능에 의해 설정된 특정 성능 표준을 통과한 경우를 의미할 수 있습니다. 즉, 프로젝트 목표는 특정 테스트 사례 세트를 실행하거나 성능 분석을 수행하는 것입니다. 프로젝트 완료 기준이 어떻게 정의되었는지에 관계없이 가능하다면 모든 프로젝트 이해관계자는 마이그레이션을 시작하기 전에 이러한 기준을 이해하고 동의해야 합니다. 마이그레이션 프로세스 중 표준에 대한 모든 변경 사항은 기존 표준을 교체하기 전에 모든 관련 이해관계자의 협상과 승인을 받아야 합니다.

위 내용은 .NET 애플리케이션을 .NET Core로 마이그레이션하는 내용입니다(1). 더 많은 관련 내용은 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요!