요즘은 개발팀 대부분이 소프트웨어 형상 관리(Software Configuration Management) 도구를 사용하고 있지만, 제대로 활용하고 있는 곳은 드뭅니다. 프로젝트를 효율적으로 관리하고 싶으면, 형상 관리를 효율적으로 하는 방법을 알아 두어야 합니다. 제가 좋다고 느끼는 원칙과 방법을 아래에 적어 보겠습니다.
기본적으로, 하나의 형상 관리 저장소에 들어가야 할 자료는 해당 소프트웨어의 빌드에 필요한 모든 자료입니다. 소스 코드(.cpp, .h, .sln 등), 모델링 데이터 원본(.max 등), 이미지 데이터 원본(.psd등), 각종 기획 문서(.doc, .xls), DB 스키마 등 해당 소프트웨어를 빌드하고 유지보수할 때 필요한 모든 자료를 다 넣어야 합니다. 소스 코드를 제외한 데이터의 원본을 저장소에 넣지 않는 개발팀이 많은데, 이러면 나중에 데이터를 수정해야 할 때 원본이 없어서 수정을 못 하는 불상사가 생깁니다. 빌드에 필요한 각종 외부 소프트웨어는 버전 관리가 필요없고 용량을 많이 차지하므로 저장소에 넣지 말아야 합니다. 그런 소프트웨어는 다른 파일 공유 서버에 보관하고 링크만 저장소에 넣어 두는 게 좋습니다.
배포용 데이터가 모여 있는 폴더엔 소스를 넣지 말아야 합니다. 소스를 넣어 놓으면 사용자에게 공개할 우려가 있고, 나중에 배포할 때 불필요한 파일을 걸러 내는 작업을 해야 하는 번거로움도 생깁니다.
trunk(main line)엔 항상 배포 가능한 기능만 들어가 있어야 합니다. 아직 구현이 안 끝나서 배포할 수 없는 기능을 개발하고 있다면, 담당자들끼리 브랜치를 만들거나 공유 폴더 등을 이용해 파일을 관리해야 합니다. 그렇게 하지 않고 구현이 끝나지 않은 기능도 trunk에 올려 놓으면, 나중에 배포할 때 해당 기능을 걸러 내는 일을 해야 합니다. 그 작업은 실수할 가능성이 높으므로 좋지 않습니다.
브랜치는 소프트웨어 개발에서 필요악입니다. 브랜치가 적으면 적을수록 관리하기 좋지만, 그렇다고 브랜치 없이 개발을 진행하는 것은 거의 불가능합니다. 브랜치는 최소한 두 개는 있어야 합니다. 하나는 릴리즈된 버전용이고, 다른 하나는 릴리즈 준비 버전입니다. 주 개발 버전에서 기능 추가가 끝나면, 릴리즈 준비 버전 브랜치로 병합합니다. 릴리즈 준비 버전 브랜치에서 버그 수정이 끝나면, 배포하고 릴리즈 버전 브랜치로 병합합니다. 각 브랜치의 수정은 수정이 완료될 때마다 주 개발 버전으로 병합해야 합니다. 주기적으로 자동 병합하게 하는 것도 좋겠습니다.
빌드를 통해 만들어 낼 수 있는 파일은 저장소에 올리지 않는 게 저장소 용량을 아낄 수 있고 충돌이 생기지 않으므로 좋습니다. 하지만 예외적으로, 파일 패킹 등의 추가 과정을 거쳐야 최종 배포본을 얻을 수 있을 때엔 최종 결과물도 저장소에 올려 놓는 게 편합니다. 사내 QA 팀 등에 실제 사용자의 것과 최대한 비슷한 배포본을 빠르게 배포할 수 있기 때문입니다. 그런데 큰 파일을 올려 놓으면 저장소의 크기가 너무 커지는 게 아닌가 걱정할 수 있습니다. 하지만 서브버전 등의 소프트웨어는 파일의 변경 사항만 누적 기록하는 방식을 쓰므로, 파일 내용이 버전마다 많이 바뀌지 않는다면 크게 문제가 되지 않습니다.
빌드로 생성 가능한 실행 파일도 저장소에 넣지 않는 게 원래 원칙입니다. 하지만 시험용으로 배포할 때 실행 파일도 같이 받을 수 있게 하면, 실행 파일과 데이터의 버전이 안 맞을 우려도 없고 배포하기도 편해서 좋습니다. 따라서 로컬 빌드된 실행 파일이 위치할 폴더를 하나 만들고, 빌드 서버가 배포할 실행 파일을 커밋할 폴더는 따로 두는 게 좋습니다. 예를 들어, 빌드된 실행 파일이 위치할 폴더가 local_binary라면 빌드 서버가 배포할 실행 파일 폴더는 binary로 하면 됩니다. 데이터 참조는 "../data" 식으로 똑같이 참조할 테니 문제가 없습니다.
참고:
Chapter 4. Branching and Merging
High-level Best Practices in Software Configuration Management
Ned Batchelder: Subversion branching quick start
브랜치(Branch) 어떻게 활용하고 계신가요?
기본적으로, 하나의 형상 관리 저장소에 들어가야 할 자료는 해당 소프트웨어의 빌드에 필요한 모든 자료입니다. 소스 코드(.cpp, .h, .sln 등), 모델링 데이터 원본(.max 등), 이미지 데이터 원본(.psd등), 각종 기획 문서(.doc, .xls), DB 스키마 등 해당 소프트웨어를 빌드하고 유지보수할 때 필요한 모든 자료를 다 넣어야 합니다. 소스 코드를 제외한 데이터의 원본을 저장소에 넣지 않는 개발팀이 많은데, 이러면 나중에 데이터를 수정해야 할 때 원본이 없어서 수정을 못 하는 불상사가 생깁니다. 빌드에 필요한 각종 외부 소프트웨어는 버전 관리가 필요없고 용량을 많이 차지하므로 저장소에 넣지 말아야 합니다. 그런 소프트웨어는 다른 파일 공유 서버에 보관하고 링크만 저장소에 넣어 두는 게 좋습니다.
배포용 데이터가 모여 있는 폴더엔 소스를 넣지 말아야 합니다. 소스를 넣어 놓으면 사용자에게 공개할 우려가 있고, 나중에 배포할 때 불필요한 파일을 걸러 내는 작업을 해야 하는 번거로움도 생깁니다.
trunk(main line)엔 항상 배포 가능한 기능만 들어가 있어야 합니다. 아직 구현이 안 끝나서 배포할 수 없는 기능을 개발하고 있다면, 담당자들끼리 브랜치를 만들거나 공유 폴더 등을 이용해 파일을 관리해야 합니다. 그렇게 하지 않고 구현이 끝나지 않은 기능도 trunk에 올려 놓으면, 나중에 배포할 때 해당 기능을 걸러 내는 일을 해야 합니다. 그 작업은 실수할 가능성이 높으므로 좋지 않습니다.
브랜치는 소프트웨어 개발에서 필요악입니다. 브랜치가 적으면 적을수록 관리하기 좋지만, 그렇다고 브랜치 없이 개발을 진행하는 것은 거의 불가능합니다. 브랜치는 최소한 두 개는 있어야 합니다. 하나는 릴리즈된 버전용이고, 다른 하나는 릴리즈 준비 버전입니다. 주 개발 버전에서 기능 추가가 끝나면, 릴리즈 준비 버전 브랜치로 병합합니다. 릴리즈 준비 버전 브랜치에서 버그 수정이 끝나면, 배포하고 릴리즈 버전 브랜치로 병합합니다. 각 브랜치의 수정은 수정이 완료될 때마다 주 개발 버전으로 병합해야 합니다. 주기적으로 자동 병합하게 하는 것도 좋겠습니다.
빌드를 통해 만들어 낼 수 있는 파일은 저장소에 올리지 않는 게 저장소 용량을 아낄 수 있고 충돌이 생기지 않으므로 좋습니다. 하지만 예외적으로, 파일 패킹 등의 추가 과정을 거쳐야 최종 배포본을 얻을 수 있을 때엔 최종 결과물도 저장소에 올려 놓는 게 편합니다. 사내 QA 팀 등에 실제 사용자의 것과 최대한 비슷한 배포본을 빠르게 배포할 수 있기 때문입니다. 그런데 큰 파일을 올려 놓으면 저장소의 크기가 너무 커지는 게 아닌가 걱정할 수 있습니다. 하지만 서브버전 등의 소프트웨어는 파일의 변경 사항만 누적 기록하는 방식을 쓰므로, 파일 내용이 버전마다 많이 바뀌지 않는다면 크게 문제가 되지 않습니다.
빌드로 생성 가능한 실행 파일도 저장소에 넣지 않는 게 원래 원칙입니다. 하지만 시험용으로 배포할 때 실행 파일도 같이 받을 수 있게 하면, 실행 파일과 데이터의 버전이 안 맞을 우려도 없고 배포하기도 편해서 좋습니다. 따라서 로컬 빌드된 실행 파일이 위치할 폴더를 하나 만들고, 빌드 서버가 배포할 실행 파일을 커밋할 폴더는 따로 두는 게 좋습니다. 예를 들어, 빌드된 실행 파일이 위치할 폴더가 local_binary라면 빌드 서버가 배포할 실행 파일 폴더는 binary로 하면 됩니다. 데이터 참조는 "../data" 식으로 똑같이 참조할 테니 문제가 없습니다.
참고:
Chapter 4. Branching and Merging
High-level Best Practices in Software Configuration Management
Ned Batchelder: Subversion branching quick start
브랜치(Branch) 어떻게 활용하고 계신가요?
댓글을 달아 주세요