ftp는 일반 파일 전송용 프로토콜이다 보니...
소스 관리 용도로는 부족한 점이 많을 것 같고요.
복잡하지 않은 방법으로 소스를 관리할 경우에는 SVN이 좋을 것 같고요.
좀 더 안정적인 방법으로 소스를 관리할 경우라면 Git이 좋을 것 같아 보이네요.
Git은 SVN의 단점을 보완해서 나왔고, 분산 개념이 적용된 형상 관리 솔루션이죠.
단지, 명령어도 많고 SVN 보다 복잡하다는 단점이 있긴 하지만~
글쓴이: krondor / 작성시간: 월, 2009/09/14 - 3:16오후
개발버전과 배포(운영)버전이 서로 차이가 나게되는 파일들 있잖습니까?
예를 들어서 DB접속정보나 특정 디렉토리 위치, 웹 컨테이너등에 따른 설정정보 등등..
(*.properties, *.res, *.xml, *.ini등등)
이런 파일들의 버전관리 정책은 다들 어떻게 하고 계신지 궁금합니다.
중요한 정보들이 담긴 파일들인 만큼 버전관리에서 뺀다는 건 무리이고..
버전관리에 포함시키자니...
개발팀에서 다운로드 받을 때 운영버전의 환경설정파일들을 내려받게 되거나,
심지어는 잘 모르는 개발자가 운영버전의 환경설정파일들을 내려받은 후 내용을 바꿔....
(상상만 해도 끔찍한 재앙이죠. -..-)
물론 버전관리로부터 Export받은 소스를 운영용에 맞도록 가공하는 스크립트를 짤 수는 있습니다만...
손바닥만한 프로그램/웹소스들을 위해서 일일이 그런걸 짜 놓는건 배보다 배꼽이 더 커지는 삽질이고요.
이런 문제를 어떻게 처리하고 계신지 궁금합니다.
혹시 사용자 권한을 설정해서 따라 버전관리(SubVersion) 프로젝트의
일부 파일만 다운로드 받도록 할 수 있을까요?
아니면 서브버전 프로젝트의 일부 파일만 다운로드 되도록 필터링 할 수
있는
요령이나 기능이 있는 지 궁금합니다.
깃허브 대신 svn을 사용하여 형상관리
SVN 이란?(정의) SVN 사용 이유
SVN은
SubVersion의 줄임말로 형상관리/소스 관리 툴
SVN의 사용목적
여러명이서 작업하는 프로젝트의 경우 버전관리나 각자 만든 소스의 통합과 같은 문제를 해결하기 위해
저장소를 만들어 그곳에 소스를 저장해 소스 중복이나 여러 문제를 해결하기 위한 Software이다
하나의 서버에서 소스를 쉽고 유용하게 관리할 수 있게 도와주는 툴
프로젝트 소스는 SVN 서버의 Trunk라는 곳에 위치 -> 자신의 Local에 Trunk의 소스를 다운 받아(update) 수정 및 추가 후
다시 업로드(commit)하는 방식
자신만의 소스를 다른 개발자들과 떨어져서 작업하려면 Branch(원 소스의
나뭇가지)를 만들어 작업 후 자기자신만 접근하여 개발하며
완성되면 Merge 기능을 사용하여 Trunk와 소스를 합치면 된다
A가 자신이 수정한 소스나 폴더를 Commit하면 B는 해당 소스를 Update받으면 최신의 소스를 받아올 수 있다
버전관리의 목적
작업 이력 관리
문제 파악
예전 버전의 파일 복원
수정한 부분 검증
협업 지원
버전관리 툴 용어
Repository
: 프로젝트 파일 및 변경 정보가 저장되는 장소
Import
: 빈 Repository에 맨 처음 파일들을 채우는 것
Export
: 버전 관리 파일들을 뺀 순수 파일만 빼내는 것
Checkout
: 저장소에서 최신 버전의 소스코드를 최초로 받아오는 것 / Repository에서 프로젝트 관련 파일들을 받아온다
Update
: 로컬 저장소에 있는 파일들을 저장소의 최신 버전으로 받아 오기
Commit
: 로컬 저장소의 변경된 내용을 서버로 전송 / Checkout한 파일의 수정사항을 갱신
Revert
: 로컬 저장소의 내용을 이전 상태로 돌림
Add
: 버전관리 대상으로 파일 등록
Trunk
: 개발 소스를 commit 했을 때 개발 소스가 모이는 곳 / 프로젝트에서 가장 중심이 되는 디렉토리, 소스와 파일 포함
Branch
: trunk에서 분리/복사한 소스로 버전별 배포판을 만들거나
trunk와 별도로 운영환경을 위한 안정화된 소스 관리 목적으로 사용
Tag
: 특정 시점의 상태 보존 목적으로 사용 장기적으로 1.0, 1.1 등 버전 별로 소스 코드를 따로 저장
특정 시점에서 프로젝트의 스냅샷을 찍어두는 것
출처: //na27.tistory.com/211 [na27]
- 소스 형상 관리를 하다보면 이런 경우가 많다.
현재 운영되고 있는 시스템인데 현업으로부터 빈번한 수정사항이 나와서 소스변경이 잦다.
가끔 개선사항으로 일정 기간이 소요되는 작업이 나오는데 소스를 로컬에서 관리한다.
Subversion을 소스 저장소로만 사용하고 있다.
Subversion의 기능을 좀더 활용해 보자.
아래와 같은 과정을 거치도록 한다.
* 메인 스트림은 trunk, 개발 스트림은 B1으로 이해하자.
1. 모든 소스를 형상관리 시스템에 올려서 동기화 시킨다.
2. 현재 소스가 운영되고 있는 소스와 동일하다. : R1 태깅
3. 2주일 정도의 작업량이 들어와서 소스를 수정해야 한다.
현재는 형상관리 시스템과 운영되고 있는 소스와 일치시키기 위해 개발되고 있는 소스는 개발자의
로컬에만 존재한다.
개발자 장비가 없으면 수정하던 작업이 진행이 안된다.
이건 문제가 있다.
4. 메인 스트림과 별도의 개발 스트림을 만든다. : B1 브랜칭
5. B1에서 개발을 진행한다. : 소스를 수정하고 커밋한다.
6. 개발 진행중에 현재 운영중인 시스템에서 버그가 발견된다.
trunk에서 버그가 발견된 것이다.
현재 운영중인 소스(2)를 가져온다. : R1으로 스위칭
별도의 프로젝트를 만들어서 가져와도 되지만 동일한 소스때문에 헷갈릴 수도 있다. 작업이 끝나면 소스는 하나만 유지하자.
7. R1에서 버그를 수정하고 테스트한다.
R1에서 커밋을 하려고 하면 태그를 수정하겠냐고 물어본다. 하면 안된다.
태그는 특정 시점에 대한 스냅샷이다.
R1을 바탕으로 B1 브랜치도 만들어졌다.
8. trunk로 스위칭해서 커밋한다.
9. trunk에서 수정된
소스를 B1에도 적용한다.
그래야 버그가 처리된 소스가 최종적으로 적용된다.
B1에서 URL을 trunk로 두고 머지한다. 소스가 충돌나면 해결하고 커밋한다.
10. R2 태깅, 운영계에 적용, 이제부터 운영되는 소스는 R2다.
11. 개발이 완료되었음. branch에서 커밋
12. 개발계에 B1 소스를 올린다.
- 메인 스트림에서 버그나 수정사항이 나오면 trunk에서 수정해서 B1으로 머지한다.
테스트되는 소스는 B1이지만 trunk와 동일한 소스이다. trunk의 수정사항이 모두 반영된 소스이다.
테스트하면서 나온 수정사항은 B1에서 수정한다.(이 때 최신 소스는 B1이다. 그리고 이것으로 테스트되어야 한다)
13. 테스트가 완료되면 trunk에서 URL을 B1으로 두고 머지하고 R3 태깅, 운영계에 적용
여기서 중요한 점은 메인 스트림에서 변경되는
소스를 개발 스트림에도 적용을 한다는 것이다.
그리고 메인 스트림으로 반영하는 것은 운영계에 올리기 전에 한다.
운영계에 올리는 소스는 반드시 태그를 걸어 둔다.
- 2010-07-22
문득 trunk에서 태깅을 해야 하나 하는 생각이 든다.
현재 운영되고 있는 소스는 trunk의 최신본(HEAD)이다.
마지막 태깅된 소스와 동일하다.
브랜칭을 하기 전의 태깅은 필수고 trunk에서 직접 소스를 수정해서 반영하는 경우도 있으므로 태깅은 필수다.
이제는 개발자들이 trunk에서 커밋을 마음놓고 해도 된다.
단, 테스트가 된 소스를 올려야겠지.