Subversion을 활용한 소스 관리 전략

- 소스 형상 관리를 하다보면 이런 경우가 많다.
현재 운영되고 있는 시스템인데 현업으로부터 빈번한 수정사항이 나와서 소스변경이 잦다.
가끔 개선사항으로 일정 기간이 소요되는 작업이 나오는데 소스를 로컬에서 관리한다.
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에서 커밋을 마음놓고 해도 된다.
단, 테스트가 된 소스를 올려야겠지.