마이그레이션 개요
Azure DevOps Server에서 Azure DevOps Services로 전환하는 것은 클라우드 기반 협업, 확장성 및 향상된 기능을 활용하려는 조직에 필수적인 단계입니다. 이 개요에서는 온-프레미스 Azure DevOps Server에서 클라우드 기반 Azure DevOps Services로 중요한 데이터를 전송하는 옵션을 살펴봅니다.
온-프레미스 Azure DevOps Server와 클라우드 기반 Azure DevOps Services 간의 주요 차이점에 대한 자세한 내용은 Azure DevOps Services와 Azure DevOps Server 비교 - Azure DevOps를 참조 하세요.
선택한 마이그레이션 옵션에 관계없이 소스 코드 및 작업 항목과 같은 가장 중요한 자산을 결정하는 것이 좋습니다. 데이터 크기, 조직의 복잡성에 대해 생각하고 원활하고 성공적인 전환을 위해 실제 마이그레이션 전에 테스트 실행에 충분한 시간이 있는지 확인해야 합니다.
마이그레이션 접근 방식
Azure DevOps Services를 채택하기 위한 특정 동기에 따라 마이그레이션에 대한 각 접근 방식의 장단점을 평가하는 것이 중요합니다. 올바른 전략은 고유한 컨텍스트 및 요구 사항에 따라 달라집니다.
| 옵션 | 권장 시나리오 | 제한 사항 |
|---|---|---|
| 1: 수동 마이그레이션 | 더 작은 프로젝트 또는 특정 데이터 하위 집합에 사용합니다. | 모든 데이터를 완전 충실도로 마이그레이션할 수 있는 것은 아니며 제한이 적용됩니다. 이 마이그레이션은 XML 템플릿 마이그레이션을 지원하지 않으므로 프로세스 템플릿을 상속된 템플릿으로 다시 만들어야 합니다. |
| 2: Azure DevOps 데이터 마이그레이션 도구 | 다양한 데이터 형식 및 복잡한 구조를 사용하는 중대형 마이그레이션에 사용합니다. | 하나의 Azure DevOps Server 컬렉션을 수정 없이 하나의 새 Azure DevOps Services 조직으로 "리프트 앤 시프트"할 수 있습니다. 자세한 내용은 제한 사항 섹션을 참조하세요. |
| 3: API 기반 마이그레이션 | 고유한 마이그레이션 요구 사항 또는 자동화 요구 사항이 있는 조직에 대한 유연성과 사용자 지정을 제공합니다. | 낮은 충실도, 데이터 손실 및 ID 변경이 발생할 수 있습니다. 자세한 내용은 제한 사항 섹션을 참조하세요. |
옵션 1: 수동 마이그레이션
예를 들어 Microsoft의 Azure DevOps 팀이 Azure DevOps Server에서 Azure DevOps Services로 이동하기로 결정했을 때 TFVC(Team Foundation 버전 제어)에서 Git로 이동하기로 결정했습니다. 마이그레이션에는 많은 계획이 필요했지만 마이그레이션할 때 TFVC 원본의 "팁" 버전을 사용하여 새 Git 리포지토리를 만들고 Azure DevOps Server에서 기록을 남겼습니다. 또한 활성 작업 항목을 이동하고 모든 이전 버그, 완료된 사용자 스토리 및 작업 등을 남겼습니다.
수동 마이그레이션 프로세스
- 마이그레이션해야 하는 가장 중요한 자산(일반적으로 소스 코드, 작업 항목 또는 둘 다)을 식별합니다. Azure DevOps Server의 다른 자산(빌드 파이프라인, 테스트 계획 등)은 수동으로 마이그레이션하기가 더 어렵습니다.
- 전환에 적합한 시간을 식별합니다.
- 대상 조직을 준비합니다. 필요한 조직 및 팀 프로젝트를 만들고, 사용자를 프로비전하는 등의 작업을 수행합니다.
- 데이터를 마이그레이션합니다.
- 원본 Azure DevOps Server 배포를 읽기 전용으로 만드는 것이 좋습니다. 다음과 같은 방법으로 수행할 수 있습니다.
- 프로젝트 수준 사용 권한 조정: 프로젝트 설정에서 보안 역할을 수정하여 수행할 수 있는 모든 사용자 또는 그룹의 사용 권한을 프로젝트 수준에서 읽기 전용으로 설정합니다.
- 리포지토리 설정 수정: 각 리포지토리에 대해 설정을 변경하여 읽기 전용으로 설정할 수 있습니다. 여기에는 읽기 작업만 허용하도록 각 사용자 또는 그룹에 대한 사용 권한을 조정하는 작업이 포함됩니다.
- 기본 제공 보안 그룹 사용: 기본 제공 보안 그룹을 활용하여 사용 권한을 보다 효율적으로 관리합니다. "읽기 권한자"와 같은 그룹에 사용자를 할당하여 읽기 전용 액세스를 제공할 수 있습니다.
- 스크립팅 권한 변경: 많은 프로젝트 또는 리포지토리가 있는 경우 스크립팅해야 할 수 있습니다. Azure CLI DevOps 확장을 사용하여 모든 권한을 나열하고 필요에 따라 업데이트할 수 있습니다.
- 리포지토리 기능 사용 안 함: 빌드 및 끌어오기 요청을 포함하여 리포지토리에 대한 액세스를 사용하지 않도록 설정하지만 경고와 함께 리포지토리를 검색할 수 있도록 유지합니다. 리포지토리의 프로젝트 설정>리포지>토리로 이동하고 리포지토리 사용 안 함 옆에 있는 토글을 켜기로 이동합니다.
옵션 2: Azure DevOps 데이터 마이그레이션 도구
Azure DevOps 데이터 마이그레이션 도구는 Azure DevOps Server에서 Azure DevOps Services로 데이터를 쉽게 마이그레이션할 수 있도록 Microsoft에서 제공하는 유틸리티 집합입니다. 이러한 도구는 소스 코드, 작업 항목, 테스트 사례 및 기타 프로젝트 관련 데이터를 포함하여 다양한 아티팩트를 마이그레이션하는 간소화된 접근 방식을 제공합니다.
마이그레이션 프로세스를 시작하기 전에 도구는 미리 배포 분석을 수행하여 원본 환경의 준비 상태를 평가하고 마이그레이션에 영향을 줄 수 있는 잠재적인 문제 또는 종속성을 식별할 수 있습니다. 준비 상태를 평가하여 잠재적인 문제를 미리 계획하고 완화할 수 있습니다.
마이그레이션 도구 제한 사항
이 도구를 사용하면 다음과 같은 이유로 수정하지 않고 하나의 Azure DevOps Server 컬렉션을 하나의 새 Azure DevOps Service Organization로 "리프트 앤 시프트"할 수 있습니다.
- 데이터 무결성 및 일관성:
- 데이터를 마이그레이션할 때 무결성 및 일관성을 유지하는 것이 중요합니다. 마이그레이션 중에 수정을 허용하면 데이터 손상 또는 불일치가 발생할 수 있습니다.
- 이 도구는 전송 프로세스 중에 데이터가 그대로 유지되도록 하여 오류 위험을 최소화합니다.
- 원본 데이터 보존:
- 마이그레이션 도구는 대상 환경에서 원본 데이터를 충실하게 복제하는 것을 목표로 합니다.
- 수정하면 원래 데이터가 변경되어 마이그레이션된 데이터와 원본 데이터 간에 불일치가 발생할 수 있습니다.
- 예측 가능한 동작:
- 이 도구는 수정을 제한하여 마이그레이션 중에 예측 가능한 동작을 보장합니다.
- 사용자는 예기치 않은 변경 없이 일관된 결과를 사용할 수 있습니다.
- 변환이 아닌 마이그레이션 포커스:
- 마이그레이션 도구의 주요 목적은 데이터를 한 위치에서 다른 위치로 이동하는 것입니다.
- 데이터 변환(예: 값 수정)은 일반적으로 마이그레이션 후에 별도로 처리됩니다.
마이그레이션 전후에 필요하지 않은 데이터를 제거할 수 있습니다.
마이그레이션 도구 프로세스
- Azure DevOps Server를 가장 최근 두 릴리스 중 하나로 업데이트하는 것과 같은 필수 구성 요소를 완료합니다.
- Azure DevOps Services로 이동하려는 각 컬렉션의 유효성을 검사합니다.
- 마이그레이션 파일을 생성합니다.
- 마이그레이션 실행을 위해 모든 것을 준비합니다.
- 테스트 실행을 수행합니다.
- 마이그레이션을 수행합니다.
- 사용자와 데이터가 마이그레이션되었고 컬렉션이 예상대로 작동하는지 확인합니다.
옵션 3: API 기반 마이그레이션
어떤 이유로 데이터 마이그레이션 도구를 사용할 수 없지만 옵션 2보다 높은 충실도 마이그레이션을 원하는 경우 공용 API를 사용하여 데이터를 이동하는 다양한 도구 중에서 선택할 수 있습니다.
API 기반 마이그레이션 제한 사항
API 기반 마이그레이션 시 다음과 같은 제한 사항이 발생합니다.
- 낮은 충실도 마이그레이션:
- 제한 사항: API 기반 도구는 수동 복사보다 더 높은 충실도를 제공하지만 여전히 비교적 낮은 충실도입니다.
- 의미: 이러한 도구는 어느 정도 충실도를 제공하지만 데이터의 모든 측면을 유지하지는 않습니다.
- 예: TFVC 변경 집합의 원래 날짜(Team Foundation 버전 제어)는 유지되지 않습니다.
- 대부분의 작업 항목 수정 날짜도 변경된 날짜를 유지하지 않습니다.
- 데이터 손실 및 ID 변경 내용:
- 제한 사항: 마이그레이션하는 동안 도구는 작업 항목 변경, TFVC 변경 집합, 패키지 피드 및 파이프라인 아티팩트 재생을 수행합니다.
- 의미: 이 프로세스로 인해 데이터가 손실되고, 새 ID가 생성되고, 생성, 수정 및 종료 날짜가 변경될 수 있습니다.
- 예: 특정 날짜와 연결된 기록 컨텍스트가 손실되어 보고 및 추적 가능성에 영향을 미칠 수 있습니다.
API 기반 마이그레이션 프로세스
일반적으로 수동 복사 이외의 추가 충실도가 중요한 경우에만 이 방법을 사용하는 것이 좋습니다. 이 방법을 사용하기로 결정한 경우 하나 이상의 도구 경험이 있는 컨설턴트를 고용하고 최종 마이그레이션 전에 테스트 마이그레이션을 수행할 수 있습니다.
많은 조직에서는 작업의 하위 집합에 대해서만 매우 높은 충실도 마이그레이션이 필요합니다. 새 작업은 잠재적으로 Azure DevOps Services에서 직접 시작될 수 있습니다. 덜 엄격한 충실도 요구 사항이 있는 다른 작업은 다른 방법 중 하나를 사용하여 마이그레이션할 수 있습니다.
지원되는 프로세스 모델
Azure DevOps Services는 다음 프로세스 모델을 지원합니다.
기본적으로 호스트된 XML은 Azure DevOps Services에서 해제 됩니다. Azure DevOps Server에서 프로젝트를 사용자 지정한 경우에만 마이그레이션 중에 호스트된 XML 프로세스 모델을 켭니다. 프로젝트가 Hosted XML에 있으면 마이그레이션 후 상속된 XML로 업그레이드할 수 있습니다.
핵심 원칙
Azure DevOps Services로 마이그레이션할 때 다음 주요 원칙 및 제한 사항에 유의하세요.
- Azure DevOps Services는 영어 전용입니다. Azure DevOps Server는 여러 언어를 지원합니다. 그러나 현재 Azure DevOps Services는 영어만 지원합니다. 컬렉션에서 영어가 아닌 언어를 사용하거나 과거에 영어 이외의 언어를 사용했으며 업그레이드하는 동안 언어를 영어로 변환한 경우 데이터 마이그레이션 도구를 사용할 수 없습니다.
- 상속: Agile, 스크럼 또는 CMMI 프로세스 템플릿에서 만들어졌으며 사용자 지정되지 않은 프로젝트는 마이그레이션 후 상속 프로세스 모델에 있습니다.
- 호스트된 XML: 사용자 지정이 있는 모든 프로젝트는 Hosted XML 프로세스 모델을 사용합니다.
- 사용자 지정된 프로젝트당 프로세스: Azure DevOps Services는 프로젝트에서 프로세스를 공유할 수 있지만 데이터 마이그레이션 도구는 사용자 지정된 각 팀 프로젝트에 대해 호스트된 XML 프로세스를 만듭니다. 예를 들어 30개의 사용자 지정된 프로젝트가 있는 경우 관리할 호스트된 XML 프로세스가 30개 있습니다. 모든 프로젝트에 대해 호스트된 XML 프로세스를 추가로 사용자 지정하려면 각 호스트된 XML 프로세스를 별도로 업데이트해야 합니다.
- 프로세스 유효성 검사: 데이터 마이그레이션 도구의 프로세스 유효성 검사에서 각 프로젝트의 대상 프로세스 모델을 검색합니다. 마이그레이션하려면 호스트된 XML 프로젝트에 대한 프로세스 유효성 검사 오류를 수정해야 합니다. 상속 프로세스 모델을 활용하기 위해 프로젝트 프로세스를 프로세스 중 하나(Agile, 스크럼 또는 CMMI)와 일치하도록 업데이트하는 것이 좋습니다. 설명서의 프로세스 유효성 검사 유형에 대해 자세히 알아봅니다.