와.. 꽤 정리가 잘 되어 있네요..
음.. VCS 관련으로 개인적인 추천을 하자면...
1. Branch 활용에 대한 언급이 없으시네요... 활발하게 이용하고 계신가요? 저희 회사에서는.. 수정사항이 생길때 Branch를 이용하고는 있습니다면... 아무래도 Subversion의 Branch 기능은 좀 불편한 부분이 있어서.. 개인적으로 Git - Subversion 연동을 통해 로컬 Branch를 활용하고 있습니다. 배워야 한다는 단점만 제외하면... 아직까지는 제일 편한 방법이네요.
2. http://www.infoq.com/articles/agile-version-control 글을 꼭 한번 봐 주시기 바랍니다. VCS 활용을 극대화 하려면.. 아무래도 VCS "이용"에 대한 전략이 필요하다는 생각을 오랜기간 하고 있었는데... 상당히 정리를 잘 해 놨더라고요.
vcs 는 어떤 것이든 유사한 문제가 있는 것이 대부분입니다(변경을 관리할 때 공통적으로 생길 수 밖에 없는 근본적인 문제들). cvs 10년 이상 사용하다가 약 3개월 전부터 mercurial 사용하고 있는데, 공통된 문제점도 있고, 더 나은 점도 있더군요. 하나 이상의 vcs를 사용하는 것은 그리 좋은 아이디어는 아닌 것 같습니다. (참고로 저와 동료들은 꼭 필요한 변경은 주저않고 수행하지만, 그렇지 않은 경우 최대한 보수적 관점을 유지합니다. 즉, 뭔가 해결할 수 없는 문제가 없는 한 절대 툴을 바꾸지 않습니다. 반면 개발 프로세스는 쉽게 바꿉니다)
tracking system을 오픈하는 것도 그리 좋은 생각은 아닌 것 같습니다. 물론, 이메일로 버그보고를 받으면 ts에서 id부여후 답장을 자동으로 보내는 등의 자동화 정도는 괜찮을 듯 합니다. jira 쓰고 있는데, 기본적 기능만 사용하므로 별 어려움 없이 씁니다.
빌드와 테스트는 거의 동시에 일어나야 하지 않나 생각합니다. 즉, 개별 작업의 change set이 vcs의 메인라인에 커밋되기 전에 머지후 빌드 및 테스트가 돌아간 후 메인라인에 커밋되는 프로세스라면 데일리 빌드는 큰 의미가 없어집니다. 물론 이렇게 되려면 각 개발자가 언제든 돌려볼 수 있는 테스트 케이스가 있어야 합니다(개별 코드라인 전략은 위의 링크에 이미 있는 것과 유사하면 되겠죠. 제 기억이 맞다면, mercurial로 바꾸면서 동료가 알려준 perforce ppt(pdf?) 파일 내용과 유사하네요. tofu scale 만 기억나네요)
저는 개인용 위키도 사용합니다. http://www.tiddlywiki.com/ USB 메모리 스틱에 truecrypt로 무장한 위키 갖고 다니면서 잡동사니 들을 기록합니다.
개발툴이 양이면, 프로세스가 음인데, 프로세스에 대한 언급은 없어서 약간 아쉽네요. (적고나서 보니 거의 '프로세스' 이야기가 되버렸네요)
건승하시길...
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 |
댓글을 달아 주세요