요즘은 개발팀 대부분이 소프트웨어 형상 관리(Software Configuration Management) 도구를 사용하고 있지만, 제대로 활용하고 있는 곳은 드뭅니다. 프로젝트를 효율적으로 관리하고 싶으면, 형상 관리를 효율적으로 하는 방법을 알아 두어야 합니다. 제가 좋다고 느끼는 원칙과 방법을 아래에 적어 보겠습니다.
기본적으로, 하나의 형상 관리 저장소에 들어가야 할 자료는 해당 소프트웨어의 빌드에 필요한 모든 자료입니다. 소스 코드(.cpp, .h, .sln 등), 모델링 데이터 원본(.max 등), 이미지 데이터 원본(.jpg, .png, .psd등), 각종 기획 문서(.doc, .xls 등), 소스 코드가 없는 라이브러리 파일(.dll, .lib 등), DB 스키마 등 해당 소프트웨어를 빌드하고 유지보수할 때 필요한 모든 자료를 다 넣어야 합니다. 소스 코드를 제외한 데이터의 원본을 저장소에 넣지 않는 개발팀이 많은데, 이러면 나중에 데이터를 수정해야 할 때 원본이 없어서 수정을 못 하는 불상사가 생깁니다. 하지만, 빌드에 필요한 각종 외부 소프트웨어는 버전 관리가 필요없고 용량만 많이 차지하므로 저장소에 넣지 말아야 합니다. 그런 소프트웨어는 다른 파일 공유 서버에 보관하고 링크만 저장소에 넣어 두는 게 좋습니다.
배포용 데이터가 모여 있는 폴더엔 원본을 넣지 말아야 합니다. 원본을 넣어 놓으면 사용자에게 공개할 우려가 있고, 나중에 배포할 때 불필요한 파일을 걸러 내는 작업을 해야 하는 번거로움도 생깁니다.
브랜치(branch)는 소프트웨어 개발에서 필요악입니다. 브랜치에서의 작업이 적으면 적을수록 관리하기 좋습니다. 게임 개발에서는 텍스트 파일이 아닌 이진 파일을 병합해야 하는 일이 자주 발생하는데, 이진 파일을 병합하는 것은 어렵습니다. 그러므로, 게임 개발 시엔 브랜치 사용을 더더욱 최소화해야 합니다. 하지만 그렇다고 브랜치 없이 개발을 진행하는 것은 거의 불가능합니다.
기본적으로, 하나의 형상 관리 저장소에 들어가야 할 자료는 해당 소프트웨어의 빌드에 필요한 모든 자료입니다. 소스 코드(.cpp, .h, .sln 등), 모델링 데이터 원본(.max 등), 이미지 데이터 원본(.jpg, .png, .psd등), 각종 기획 문서(.doc, .xls 등), 소스 코드가 없는 라이브러리 파일(.dll, .lib 등), DB 스키마 등 해당 소프트웨어를 빌드하고 유지보수할 때 필요한 모든 자료를 다 넣어야 합니다. 소스 코드를 제외한 데이터의 원본을 저장소에 넣지 않는 개발팀이 많은데, 이러면 나중에 데이터를 수정해야 할 때 원본이 없어서 수정을 못 하는 불상사가 생깁니다. 하지만, 빌드에 필요한 각종 외부 소프트웨어는 버전 관리가 필요없고 용량만 많이 차지하므로 저장소에 넣지 말아야 합니다. 그런 소프트웨어는 다른 파일 공유 서버에 보관하고 링크만 저장소에 넣어 두는 게 좋습니다.
배포용 데이터가 모여 있는 폴더엔 원본을 넣지 말아야 합니다. 원본을 넣어 놓으면 사용자에게 공개할 우려가 있고, 나중에 배포할 때 불필요한 파일을 걸러 내는 작업을 해야 하는 번거로움도 생깁니다.
브랜치(branch)는 소프트웨어 개발에서 필요악입니다. 브랜치에서의 작업이 적으면 적을수록 관리하기 좋습니다. 게임 개발에서는 텍스트 파일이 아닌 이진 파일을 병합해야 하는 일이 자주 발생하는데, 이진 파일을 병합하는 것은 어렵습니다. 그러므로, 게임 개발 시엔 브랜치 사용을 더더욱 최소화해야 합니다. 하지만 그렇다고 브랜치 없이 개발을 진행하는 것은 거의 불가능합니다.
브랜치는 최소한 하나는 있어야 합니다. 그건 배포용 브랜치입니다. 배포용 브랜치는 QA를 진행하고 거기서 발생한 문제를 수정하기 위해서 필요합니다. Trunk(주 개발 버전)에서 기능 추가가 끝나면, 배포용 브랜치로 병합합니다. 배포용 브랜치에서 QA를 통과하면 실제로 배포합니다. 각 브랜치의 수정은 수정이 완료될 때마다 주 개발 버전으로 병합해야 합니다. 주기적으로 자동 병합하게 하는 것도 좋겠습니다. 참고로, 게임은 두 가지 버전을 동시에 관리할 일이 거의 없으므로, 1.0이나 2.0 등으로 배포용 branch의 이름을 정하지 말고 release라고 간단히 정하면 됩니다.
브랜치와 트렁크 간의 동기화는 별도로 작업하지 말고 병합 기능을 활용해야 합니다. 병합 기능을 활용하면 실수를 줄일 수 있고 서로 다른 부분도 쉽게 파악이 가능합니다.
빌드를 통해 만들어 낼 수 있는 파일은 저장소에 올리지 않는 게, 저장소 용량을 아낄 수 있고 충돌이 생기지 않으므로 좋습니다. 하지만 예외적으로, 파일 패킹 등의 추가 과정을 거쳐야 최종 배포본을 얻을 수 있을 때엔 최종 결과물도 저장소에 올려 놓는 게 편합니다. 사내 QA 팀 등에 실제 사용자의 것과 최대한 비슷한 배포본을 빠르게 배포할 수 있기 때문입니다. 그런데 큰 파일을 올려 놓으면 저장소의 크기가 너무 커지는 게 아닌가 걱정할 수 있습니다. 하지만 서브버전 등의 소프트웨어는 파일의 변경 사항만 누적 기록하는 방식을 쓰므로, 파일 내용이 버전마다 많이 바뀌지 않는다면 크게 문제가 되지 않습니다.
빌드로 생성 가능한 실행 파일도 저장소에 넣지 않는 게 원래 원칙입니다. 하지만 시험용으로 배포할 때 실행 파일도 같이 받을 수 있게 하면, 실행 파일과 데이터의 버전이 안 맞을 우려도 없고 배포하기도 편해서 좋습니다. 따라서 로컬 빌드된 실행 파일이 위치할 폴더를 하나 만들고, 빌드 서버가 배포할 실행 파일을 커밋할 폴더는 따로 두는 게 좋습니다. 예를 들어, 빌드된 실행 파일이 위치할 폴더가 local_binary라면 빌드 서버가 배포할 실행 파일 폴더는 binary로 하면 됩니다. 데이터 참조는 "../data" 식으로 똑같이 참조할 테니 문제가 없습니다.
빌드를 통해 만들어 낼 수 있는 파일은 저장소에 올리지 않는 게, 저장소 용량을 아낄 수 있고 충돌이 생기지 않으므로 좋습니다. 하지만 예외적으로, 파일 패킹 등의 추가 과정을 거쳐야 최종 배포본을 얻을 수 있을 때엔 최종 결과물도 저장소에 올려 놓는 게 편합니다. 사내 QA 팀 등에 실제 사용자의 것과 최대한 비슷한 배포본을 빠르게 배포할 수 있기 때문입니다. 그런데 큰 파일을 올려 놓으면 저장소의 크기가 너무 커지는 게 아닌가 걱정할 수 있습니다. 하지만 서브버전 등의 소프트웨어는 파일의 변경 사항만 누적 기록하는 방식을 쓰므로, 파일 내용이 버전마다 많이 바뀌지 않는다면 크게 문제가 되지 않습니다.
빌드로 생성 가능한 실행 파일도 저장소에 넣지 않는 게 원래 원칙입니다. 하지만 시험용으로 배포할 때 실행 파일도 같이 받을 수 있게 하면, 실행 파일과 데이터의 버전이 안 맞을 우려도 없고 배포하기도 편해서 좋습니다. 따라서 로컬 빌드된 실행 파일이 위치할 폴더를 하나 만들고, 빌드 서버가 배포할 실행 파일을 커밋할 폴더는 따로 두는 게 좋습니다. 예를 들어, 빌드된 실행 파일이 위치할 폴더가 local_binary라면 빌드 서버가 배포할 실행 파일 폴더는 binary로 하면 됩니다. 데이터 참조는 "../data" 식으로 똑같이 참조할 테니 문제가 없습니다.
배포할 버전은 branch에 tag를 달아서 나중에 쉽게 얻을 수 있도록 해 둬야 합니다. 버전 이름은 배포 제품 용도, 날짜, 그리고 SVN 리비전을 조합해 만들어 두면 찾기 쉽습니다. 예를 들어, 오픈 베타 테스트용 버전이고 2001년 1월 1일에 SVN 리비전 3420으로 만들었다면, Korea.OBT.2001.1.2.3420처럼 하면 됩니다.
참고:
참고:
댓글을 달아 주세요