Windchill+를 사용한 WBM 마이그레이션
마이그레이션에 WBM(Windchill Bulk Migrator) 모듈을 사용합니다. 이 항목에서는 다양한 WBM(Windchill Bulk Migrator) 활동에 대해 설명합니다.
필수조건
WBM 마이그레이션 시나리오에는 특수한 부분이 몇 가지 있으나 이 도움말 센터의 다른 섹션에서 개발된 개념을 바탕으로 일관되게 구축되었습니다.
• WBM 마이그레이션 시나리오는 마이그레이션 및 QA 환경과 관련된 고급 Windchill+ 시나리오입니다. 환경은 다음과 같습니다.
• WBM 마이그레이션은 Windchill+용으로 특수하게 구축된 자동화된 프레임워크를 활용합니다. 백엔드 액세스 권한은 필수가 아니며 마이그레이션 환경에서 부여됩니다.
• 각 마이그레이션이 고유합니다. 이 섹션에서는 WBM 마이그레이션 시나리오 대부분을 지원하기 위해 Windchill+에서 사용할 수 있는 서비스에 대해 설명합니다. 그러나 사용자는 고객 또는 파트너로서 복잡성에 따라 마이그레이션 프로젝트를 설계 및 계획하고 특정 요구 사항에 맞게 조정해야 합니다. 예를 들어 온프레미스에서 수행해야 하는 예행 횟수, 필수조건, 추가 필수 임무 등이 있습니다.
• 마이그레이션할 메타데이터를 구조화하려면 데이터베이스가 필요합니다. 여러 번 변환하지 않기 위해 온프레미스 준비 데이터베이스가 사용되는 것으로 가정합니다. Oracle 데이터베이스를 사용해야 합니다. Windchill 버전 요구 사항에 따라 Oracle 데이터베이스를 사용해야 합니다. 데이터베이스 구조는 Windchill WBM 준비 데이터베이스 요구 사항을 준수해야 합니다.
• WBM 준비 데이터베이스에 대해 온프레미스에 별도의 데이터베이스 스키마를 생성하는 것이 좋습니다.
• Windchill+는 혼합 모드를 지원하지 않으므로 Windchill은 변환 유틸리티를 사용하여 변경 관리 레거시 데이터 모델에서 새로운 유연한 데이터 모델로 전환했습니다. Windchill Bulk Migrator를 사용하여 대량 마이그레이션 프로세스를 수행하기 전에 소스 시스템을 '유동' 모드로 변환해야 합니다. 자세한 내용은 Removal of Legacy Links from Windchill 13.0.2.0을 참조하십시오.
마이그레이션 환경
마이그레이션 환경은 코드, 구성 및 데이터를 통합하는 규범적 프로세스가 발생하는 장소입니다. 마이그레이션용 빌드 패키지를 제출하는 것 외에도 WBM(Windchill Bulk Migrator)을 사용하여 준비 데이터를 제출합니다. 이 데이터는 평가를 위해 마이그레이션 준비 데이터베이스에 로드됩니다. 코드, 구성 및 데이터 이동 모두 Windchill+ 핵심 운영 프레임워크의 일부입니다. 예를 들어, 시스템 A에서 데이터를 생성하여 특정 위치에 저장하면 Windchill+가 자동으로 모든 것을 시스템 B로 마이그레이션합니다.
마이그레이션 후 빌드 패키지를 QA 환경에 제출한 다음 생산 환경에 제출합니다.
WBM 마이그레이션 활동
WBM 마이그레이션 활동과 관련된 다음 정보를 고려하겠습니다.
생산 운영 단계 이전
시스템은 통합 환경을 사용하여 모든 코드 변경을 통합하고 마이그레이션 로드 테스트를 시작하기 전에 빌드의 성숙도 레벨에 도달합니다. 빌드 배포 프로세스는 패키지 제출 및 수준 올리기 항목에 설명된 프로세스와 유사합니다.
다음 단계를 수행하십시오.
2. 통합 및 기능 인수 테스트(FAT) 주기를 완료합니다. 테스트 주기가 종료되면 임무가 완료되고 환경은 이전 상태로 되돌아갑니다.
 | 이 단계가 7일 이내에 완료되지 않으면 환경은 이전 상태로 되돌아갑니다. |
마이그레이션 환경 단계
마이그레이션 환경은 로드 테스트에 사용됩니다. 다음 단계를 수행하십시오.
1. AzCopy를 사용하여 준비 데이터베이스 덤프를 저장 영역에 업로드합니다.
자세한 내용은 다음 링크를 방문하십시오.
2. 준비 데이터베이스 덤프 가져오기를 요청하는 서비스 요청을 엽니다. 자세한 내용은 서비스 요청 열기를 참조하십시오.
3. 빌드를 배포합니다. 빌드 배포 프로세스는 패키지 제출 및 수준 올리기 항목에 설명된 프로세스와 유사합니다. 이 항목은 마이그레이션 환경에 빌드를 배포하는 데 적용됩니다.
| | 기본적으로 마이그레이션 환경의 경우 이 단계에서 생성된 백업은 30일 동안 보관됩니다. |
5. 서비스 요청을 열어 로드를 실행합니다.
6. 콘텐츠 마이그레이션의 경우 저장소 계정에서 콘텐츠 맵 파일을 검색하고 콘텐츠 복사 스크립트를 준비합니다. 그런 다음 최종 콘텐츠 전송을 실행하기 위해 스크립트가 첨부된 서비스 요청을 엽니다. 자세한 내용은 서비스 요청 열기를 참조하십시오.
7. 마이그레이션 테스트 주기를 완료합니다. 테스트 주기가 종료되면 서비스 요청을 통해 요청된 다음 작업 중 하나를 통해(선호하는 순서대로) 환경이 빈 상태로 되돌아갑니다.
◦ 생산 환경에서 재호스팅
◦ 재프로비저닝(초기 마이그레이션에만 사용되며 후속 데이터 마이그레이션에는 사용되지 않음)
QA 환경 단계
QA 환경은 UAT에 사용됩니다. 다음 단계를 수행하십시오.
1. 준비 데이터베이스로 가져온 최신 상태인 데이터에 대해 동일한 프로세스를 반복합니다.
◦ deploy_pipe : pipeline을 사용하여 빌드 및 매니페스트 파일을 제출합니다.
| | 기본적으로 QA 환경의 경우 이 단계에서 얻은 백업은 30일 동안 보관됩니다. |
2. QA 환경에서 로드 실행을 요청하는 서비스 요청을 엽니다. 자세한 내용은 서비스 요청 열기를 참조하십시오.
3. 콘텐츠 마이그레이션의 경우 저장소 계정에서 콘텐츠 맵 파일을 검색하고 콘텐츠 복사 스크립트를 준비합니다. 그런 다음 최종 콘텐츠 전송을 실행하기 위해 스크립트가 첨부된 서비스 요청을 엽니다. 콘텐츠 맵 파일 생성에 대한 자세한 내용은 WBM 단계를 참조하십시오.
4. UAT 테스트 주기를 완료합니다. 최대 30일 이내로 다음 중 하나를 결정해야 합니다.
◦ 테스트 주기가 성공적인 경우 - 임무가 승인되고 빌드만 생산 환경으로 수준이 올라갑니다.
◦ 테스트 주기가 성공적이지 않은 경우:
▪ 임무가 거부될 수 있으며 환경은 이전 상태로 되돌아갑니다.
▪ 임무가 승인될 수 있으며 빌드가 생산 환경으로 수준이 올라갑니다. 버그 수정을 위해 후속 빌드를 제출할 수 있습니다.
◦ 테스트 주기가 30일 이내에 완료되지 않으면 환경은 자동으로 이전 상태로 되돌아갑니다. 환경을 유지하려면 임무를 승인해야 합니다.
| | 또 다른 QA 전체 로드가 필요한 경우, 서비스 요청을 사용하여 요청된 다음 작업 중 하나를 통해(선호하는 순서대로) 환경이 빈 상태로 되돌아갑니다. • 생산 환경에서 재호스팅 • 재프로비저닝(초기 마이그레이션에만 사용되며 후속 데이터 마이그레이션에는 사용되지 않음) |
선택적으로 Go-Live를 위해 델타 로드가 계획된 경우 로드는 독립적으로 생산에 수행되어야 합니다. 서비스 요청을 열어 생산 환경에서 로드 실행을 요청하거나 반복합니다. 자세한 내용은 서비스 요청 열기를 참조하십시오.
생산 운영 단계
• 이 단계에서는 이전에 승인된 빌드가 이미 QA 및 생산 환경에 있습니다.
• 또한 이전 데이터 로드는 생산 환경에서 사용 가능할 수도 있습니다.
• Go-Live 컷오버 중에 필수 빌드 제출이 없는 경우(또는 Go-Live 필수 빌드를 미리 제출한 경우) 다음 단계를 수행하십시오.
1. 최신 준비 데이터베이스 덤프를 저장소 계정에 업로드합니다.
2. 최신 준비 데이터베이스 가져오기를 요청하는 서비스 요청을 엽니다.
3. 생산 환경에서 로드를 실행하는 서비스 요청을 엽니다.
4. 콘텐츠 마이그레이션의 경우, 스크립트를 생성한 후 최종 콘텐츠 전송을 위한 서비스 요청을 엽니다.
• 빌드 제출이 필요한 경우 QA 환경 단계 섹션에서 빌드 제출 및 수준 올리기에 대해 설명된 프로세스를 수행합니다. 그런 다음 QA 환경 단계 섹션에 설명된 대로 생산 활동 및 서비스 요청을 실행합니다.
• Go-Live가 확인되면 생산 환경을 QA 및 통합(및 후속 마이그레이션이 계획된 경우 마이그레이션)으로 재호스팅해야 합니다. 재호스팅 활동을 위해서는 서비스 요청을 열어야 합니다.
실행 단계
• 성공적인 Go-Live 이후에는 모든 환경이 생산 환경에서 재호스팅되므로 변경을 개발 환경에 전파하는 것이 좋습니다.
◦ 데이터 모델은 반드시 있어야 하며 개발 환경에서 이 부분에 대한 작업부터 시작해야 합니다.
◦ 최신 빌드를 재사용할 수 있습니다.
• 후속 마이그레이션이 있는 경우 생산 운영 이전 섹션에 설명된 프로세스를 반복해야 합니다.
| | 기존 데이터 손실을 방지하려면 프로젝트 설계 및 계획 단계에서 환경 새로 고침 활동을 신중하게 고려해야 합니다. |
최종 고려 사항
• 대규모 마이그레이션의 경우 Go-Live 컷오버 중 영향을 완화하려면 델타 로드를 허용하도록 마이그레이션 활동을 설계하는 것이 좋습니다.
• 모든 마이그레이션 프로젝트는 고유합니다. 마이그레이션 프로젝트가 성공하려면 강력한 계획, 범위 논의, 위험, 종속성 관리 등의 활동을 수행해야 합니다. 이러한 활동을 통해 적절한 마이그레이션 설계와 원활한 Go-Live 컷오버가 보장됩니다.
• 마이그레이션 테스트의 중요성이 과소평가되는 경우가 있습니다. 간단한 마이그레이션 프로젝트의 경우 세 가지 테스트 마이그레이션 주기부터 시작하는 것이 좋습니다. 복잡성이 증가함에 따라 더 많은 주기를 구현하도록 계획할 수 있습니다.