A step-by-step guide to migrating from Perforce to Git
이전 글에서 설명한 것과 같이 SCM에서는 이제는 거의 모든 유형의 디지털 개발에 Git을 선택합니다. 하지만 수년 간의 귀중한 기록이 Perforce에 저장되어 있다면 전환에 따른 장단점에 대해 고민하게 될 것입니다. 이 글에서는 이러한 고민을 정면으로 마주하고 데이터를 Git으로 마이그레이션하는 방법을 설명해 드리겠습니다. Perforce에서 Git으로 마이그레이션하는 프로세스를 8단계로 나눠 보았습니다.
1단계: Perforce 데이터 이동
Perforce에서 Git으로 데이터를 이동하는 일반적인 방법은 두 가지가 있습니다. 그 방법을 알아보기 전에 Perforce와 Git이 소프트웨어 프로젝트를 처리하는 방식의 근본적인 차이점을 고려해야 합니다.
Perforce 서버는 각각 자체 브랜칭 모델을 가진 수십 또는 수백 개의 개별 소프트웨어 프로젝트를 수용할 수 있습니다. 개발자는 작업 중인 복사본에 어떤 파일을 넣을지 Perforce 서버에 알려주는 “보기”를 정의합니다. 반면 Git 리포지토리는 보통 하나의 소프트웨어 프로젝트와 그 브랜치 및 태그를 보관합니다(대규모 모놀리식 Git 리포지토리도 있기는 함). 일반적으로 리포지토리를 복제하고 하위 모듈이나 하위 트리를 체크아웃할 수 있습니다.
데이터를 이동하는 문제에는 Perforce에서 데이터를 추출하는 방법과 이를 동등한 Git 리포지토리 세트로 변환하는 방법이라는 두 가지 부분이 있습니다.
Perforce 데이터 이동 옵션 1: Git Fusion 사용
Perforce에 데이터의 전체 기록을 보존하고 싶은 경우 Perforce의 자체적인 Git Fusion 도구를 사용하여 Perforce 서버의 일부(단일 프로젝트)를 Git 리포지토리로 추출하면 됩니다. 기본적으로 다음과 같이 합니다.
관련 자료
전체 Git 리포지토리를 이동하는 방법
솔루션 보기
Bitbucket Cloud에서 Git에 대해 알아보기
- Git Fusion을 설치합니다
- 브랜칭 구조를 포함하여 데이터의 올바른 보기를 설정합니다
- Git 클라이언트를 사용하여 Git Fusion에서 복제합니다
- 리포지토리를 Bitbucket으로 푸시합니다
Hands-on example *In order to work through this example you’ll need a Perforce server with Git Fusion already operational.* Let’s say that you have a Perforce project living in the repository path //depot/acme/… (in Perforce depot view syntax). It has three branches: - //depot/acme/main/… - //depot/acme/r1.0/… - //depot/acme/r1.1/… Keep in mind that with Perforce you see branches as additional directories in the tree. Your first step is to configure Git Fusion so that it understands the branching relationship in Perforce. To do this, you create a repo configuration file: [@repo] description = Acme project charset = utf8 [main] git-branch-name = main view = //depot/acme/main/… … [r1.0] git-branch-name = r1.0 view = //depot/acme/r1.0/… … [r1.1] git-branch-name = r1.1 view = //depot/acme/r1.1/… … Submit this file to Perforce under the path //.git-fusion/repos/acme/p4gf_config Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards. Next, clone from Git Fusion: git clone https:///acme cd acme git remote add bitbucket git push –u --all bitbucket git push --tags Bitbucket That’s it! You should now see the imported history in Bitbucket.이렇게 해서 항상 Perforce 데이터의 100% 믿을 수 있는 복사본이 만들어지는 것은 아닙니다. 부분 병합과 같은 일부 Perforce 작업의 경우 Git에는 상응하는 것이 없습니다. 하지만 대체로 이 방법을 사용하면 별다른 노력 없이도 대부분의 기록을 가져올 수 있습니다.
레거시 SCM에서 지난 10년간의 브랜칭 기록을 보존한다고 해서 같은 워크플로를 계속 사용해야 한다는 뜻은 아닙니다. 특히, Git Flow와 같은 기능 브랜치 워크플로를 실용적인 첫 단계로 채택하는 것을 고려해야 합니다.
장단점
- 설정 작업과 런타임이 가장 많이 필요
- 가장 많은 기록을 보존(레거시 Perforce 서버 사용을 중단할 수 있음)
- 기록에 레거시 브랜칭 모델을 유지
Perforce 데이터 이동 옵션 2: 다시 시작
다른 옵션은 다시 시작하는 것입니다. 복잡한 기록은 모두 잊어버리세요. Perforce에서 프로젝트에 해당하는 각 브랜치의 헤드(끝)를 추출하고 비어 있는 새로운 Git 리포지토리에 가져오면 됩니다. (원하는 데이터의 올바른 '보기'로 Perforce 작업 영역을 정의하게 됩니다.)
가장 간단하고 빠른 기법으로, Perforce 기록이 얼마나 복잡했는지 상관없이 새 Git 리포지토리는 간결합니다. 기록이 축적되는 일 없이 새로운 Git 기반 워크플로를 시작할 수 있습니다.
가장 큰 단점은 어떤 이유로든 코드 기록을 살펴봐야 할 경우를 대비하여 이전의 Perforce 서버를 읽기 전용 모드로 유지하는 것이 좋다는 것입니다. 라이선스 비용은 들지 않지만 이전 서버를 한동안 가동해야 할 것입니다.
**Hands-on example** Go into your Perforce workspace (the directory where the main branch of your project data is checked out) and run: p4 sync This fetches the latest revision of your files. Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards. Next, create a new Git repo in your workspace and push to Bitbucket: git init . git remote add origin git push –u --all origin git push --tags origin You should now see the latest snapshot of your code as the first commit in your new Bitbucket project.장단점
- 빠르고 간단함
- 브랜칭 모델 및 워크플로 재설계
- 읽기 전용 액세스를 위해 레거시 Perforce 서버를 사용
2단계: 사용자 및 권한
데이터를 이동한 후 다음 작업은 새 Bitbucket 프로젝트에 사용자와 권한을 매핑하는 것입니다. 사용자 디렉터리에 LDAP를 사용하면 이 단계에서 시간을 절약할 수 있습니다. 그렇지 않으면 p4 users –o 명령을 사용하여 Perforce에서 사용자 계정 집합을 쉽게 추출한 다음 한 번에 하나의 프로젝트씩 Bitbucket에 입력할 수 있습니다.
Perforce 권한은 세분화되고 복잡하며 개별 파일에 대한 액세스가 제외될 가능성이 있기 때문에 Perforce 권한을 동등한 Bitbucket 권한으로 변환하는 것은 어려울 수 있습니다. 이렇게 복잡한 권한 체계는 Perforce 서버가 느려지는 이유 중 하나에 해당합니다. 액세스를 시도할 때마다 서버가 복잡한 데이터 구조에서 값비싼 컴퓨팅을 하게 될 수 있습니다.
대부분의 경우 프로젝트 리더에게 일반 프로젝트, 리포지토리 및 브랜치 수준 권한을 사용하여 Bitbucket에서 더 간단한 권한 집합을 정의하도록 요청하는 것이 더 빠릅니다. Git에서는 새로운 워크플로 옵션을 많이 제공하므로 결국 권한 설정을 다시 검토하는 것이 좋습니다. 예를 들어, Perforce에서는 브랜치 만들기가 제한되어 있는 반면 Bitbucket에서는 main 브랜치에 대한 푸시 액세스만 제한하면 될 수도 있습니다.
3단계: 바이너리 파일
Perforce에 대용량 바이너리 블랍을 저장했다면 Git에서 어떻게 관리할지 신중하게 생각해 보세요. Git LFS를 사용해 보거나 일반 아티팩트 관리 시스템을 대신 사용할 수도 있습니다. 어떤 경우에도 대규모 블랍을 맹목적으로 Git 리포지토리에 푸시하는 것은 좋지 않습니다.
4단계: 복잡한 종속성
A Perforce working copy may actually map in read-only copies of data from several modules. In Git, this is done either using submodules, subtrees, or by leveraging CI/CD or artifact management systems. There’s no easy answer here, but some data import tools can model a submodule relationship between Git repos. For a more in depth look on how to use submodules or subtrees, you can read about each here: https://www.atlassian.com/git/tutorials/git-subtree.
5단계: 마이그레이션 중에 팀을 구조화하는 방법
Perforce 서버에는 10개 팀에서 만든 100개의 프로젝트가 있습니다. 마이그레이션 전략과 도구 세트가 마련되어 있으므로 유지 관리 시간을 정하고 시작하세요!
사실... 아직 아닙니다.
SCM 도구를 전환하는 것은 데이터뿐만 아니라 개발자에 관한 것이기도 하다는 점을 기억하세요. 사용자, 프로세스 및 일정을 고려해야 하므로 하루 만에 이 모든 것을 무리하게 완료하려고 하지 마세요. 너무 위험합니다.
실제 마이그레이션 단계 중의 프로젝트 계획을 고려해야 합니다. (새 Jira 워크플로를 사용해 보기에 좋은 시기일 수 있습니다...) 살펴볼 수 있는 몇 가지 옵션은 다음과 같습니다.
- 팀별 및 프로젝트별로 마이그레이션합니다. 스프린트 또는 프로그램 증분 초기에 적응할 시간이 있을 때 프로젝트와 팀을 시작하는 것을 목표로 합니다.
- 점진적으로 마이그레이션합니다. 주말에 모든 데이터를 가져오되 시간이 지남에 따라 팀이 Git으로 천천히 전환을 완료하도록 하세요. 가져오기 도구를 다시 실행하여 주기적으로 델타를 픽업합니다. 더 복잡하긴 하지만 팀 간에 종속성이 있고 얼리 어답터가 CI/CD 파이프라인에 피드하기 위해 적어도 Git의 최신 스냅샷을 필요로 하는 경우 나쁘지 않은 전략입니다.
- 일정 기간 동안 두 시스템을 동시에 사용합니다. 걱정이 된다면 어려울 수 있지만, 데이터 변환기에 혼란을 주는 복잡한 작업을 수행하지 않는 한 Git Fusion을 사용하여 양방향으로 데이터를 교환하는 것은 기술적으로 가능합니다.
마지막으로 팀에 동기 부여, 이유, 변경 방법에 대한 일련의 단계 전달과 같은 변경 사항을 소통하는 데 투자하세요. 전체 소프트웨어 개발 수명 주기에 경험이 있는 엔지니어로 구성된 "얼리 어답터" 팀을 선별하고 다른 팀의 모델로 삼습니다. 어려움을 겪는 팀원을 도와줄 Git 챔피언을 찾으세요. 작고 이해하기 쉬우며 반복적인 변경으로 이 프로세스를 성공적으로 해낼 수 있습니다.
Step 6: Mirrors and clusters
Perforce에는 데이터를 원격 사이트에 미러링하여 지연 시간의 영향을 줄이는 간단하지만 효과적인 시스템이 있습니다. 읽기 전용 클러스터링을 위해 로컬 미러링 집합을 실행하는 더 복잡한 시스템도 있습니다. Git에서는 지연 시간이 그렇게 큰 문제가 되지는 아니지만 전 세계적으로 작업하는 경우 클러스터링과 미러링에 대해 Bitbucket Data Center를 고려하면 전 세계 팀의 복제 시간을 크게 단축할 수 있습니다.
Step 7: ALM tools
좋은 소식은 Perforce에서 Git으로 마이그레이션하면 선택할 수 있는 ALM 도구 스택이 많다는 것입니다. 거의 모든 개발자와 ALM 도구가 Git을 사용하며 Bitbucket은 당연히 Jira 및 Bamboo와 뛰어나게 통합됩니다. Git으로 전환하면 기능 브랜치 워크플로를 활용하는 계획 브랜치와 같은 Bamboo 기능을 살펴볼 수 있습니다.
8단계: 성공의 정의
그렇다면 Perforce에서 Git으로 마이그레이션하는 동안 성공은 정확히 어떻게 측정해야 할까요? 많은 마이그레이션 프로젝트에서 데이터 전송의 충실도에 지나치게 집중하는 경향이 있습니다. 하지만 충실도는 여러 가지 이유로 유용한 메트릭이 아닙니다. Git에서는 Perforce와 같은 중앙 집중식 SCM 시스템에서 일어난 것과 정확히 같은 비트 단위로 완벽한 기록을 얻을 수 없을 것입니다.
더 실용적인 방법은 검증에 CI/CD를 사용하는 것입니다. CI/CD 파이프라인을 Perforce에서 Git으로 전환한 후에도 모든 테스트를 통과합니까? 그리고 여전히 소프트웨어를 배포할 수 있습니까? 이전의 중요한 빌드가 여전히 CI/CD 파이프라인을 통과한다면 성공이라고 말할 수 있습니다!
마무리
Perforce에서 Git으로의 마이그레이션이 이루어지고 있는 이유와 실질적인 방법을 알아보았습니다. 다음 단계는 Git 솔루션을 선택하는 것입니다. 게임 개발 목적으로 Perforce에서 전환하는 경우 게임 개발자가 Bitbucket을 좋아하는 이유를 확인하세요.
이 문서 공유
다음 토픽
여러분께 도움을 드릴 자료를 추천합니다.
이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.
Bitbucket 블로그
DevOps 학습 경로
