[Agile Beginners] 체크아웃 - 체크인 주기가 짧은 것이 좋은건가요?

[YoungHyun,Kim]

안녕하세요. 김영현입니다.

현재 회사에서 SCM tool로 P4(Perforce)를 사용하고, Defect DB로는 CQ(ClearQuest)를 사용합니
다.

개발자가 변경사항을 코드에 반영하고 서버에 이를 반영하기 위해서는 우선 CQ에 activity를 만들어야 합니다. 그리고, P4
를 사용해 해당 파일을 checkout-checkin 해 서버에 변경사항을 반영합니다.

별 문제가 없어보이는 시나리오지만, 파일 이동과 같은 단순한 변경사항의 경우에도 CQ에 activity를 만들어야 합니다. 제
경우 파일하나를 옮기는데 길게는 10분 정도 걸린 경우도 있었습니다. CQ가 느리기도 하고, activity를 만들고, 열고,
리뷰를 보내는 여러 단계가 있어 시간이 좀 걸립니다.

상황이 이렇다 보니 개발자들이 다른 변경사항의 경우 다른 activity로 만들어야 하는데 "TEST"라는 이상한 제목의
activity를 한 개만 만들어 모든 수정사항을 퇴근 전에 서버에 반영하는 경우도 있습니다.

그래서, SE그룹에 이 같은 문제가 있으니 defect과 관련된 activity만을 CQ에서 하고, defect을 원인으로 하
지 않는 수정의 경우 P4만을 사용해 관리하도록 하도록 변경하고 싶습니다.

제목과 같이 체크아웃 - 체크인 주기가 짧은 것이 좋다는 자료가 있으면 이를 바탕으로 SE그룹에 정식으로 요청을 하려고 합니
다.

좋은 자료나 다른 생각이 있으시면 알려주세요.

감사합니다.

--
Google 그룹스 'Agile Beginners' Q&A' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ab...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 abqna+un...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/abqna?hl=ko에서 그룹을 방문하세요.

[이지연]

소스코드 형상관리에서 checkin-checkout 주기에 대한 정답은 없다고 생각합니다.

 

다만 소스코드 리파지토리에 생기는 변경에 대해서 어느 범위, 어느 수준까지 관리되고 있느냐가 중요하다고 생각합니다.

 

2010년 5월 11일 오후 2:31, YoungHyun,Kim <yhyu...@gmail.com>님의 말:

[김영현]

저는 CQ로는 defect이 원인인 변경사항만, P4로는 기타 다른 변경사항을 관리하도록 하려는 것이 초점이었습니다.

그래서 체크아웃 - 체크인 주기가 CQ때문에 불필요하게 길어지는 경우가 있다는 것은 이유로 앞에서 언급한 것처럼 정책을 변경하면 좋을 것 같다라는 것을 말하려고 하였습니다.

그런데, 좀더 정확히 하자면 이지연 님께서 말씀해주신 것 처럼 "어느 범위"에 해당하는 부분을 명확하게 하고 싶은 것이었네요.

단지 질문에서는 제가 근거로 제시하고자 하는 부분에 대한 증거자료를 찾을 수 있을까해서 질문을 올렸습니다. :)

그런데 이지연님께서 말씀하신 부분 중에서 "어느 수준"에 해당하는 것은 정확하게 무엇인지요? 궁금해서요 ㅠ_ㅜ

감사합니다.

2010년 5월 11일 오후 3:22, 이지연 <ezon...@gmail.com>님의 말:

[이지연]

그 설명을 빠뜨렸네요, 제는 이렇게 생각합니다..^^;

 

 

"어느범위"

 : 기능 구현으로 인한 수정, defect으로 인한 코드 수정, 사양변경으로 인한 코드 수정, 기타 수정

 ** '기타 수정'은 개발팀 상황에 따라 달라질 것 같고, 필요하면 조금 더 세분화 할 수도 있을 것 같아요.

 ** defect도 검증부서에서 검출한 것과 개발팀 내부에서 발견한 것으로 볼 수 있는데,

    어느것을 "defect으로 인한 수정"으로 볼지는 정의해야 합니다.

 

 

"어느수준"

 : cq activity 관리에 process model이 반영되어 있다면, cq form에 입력하는 정보와 process 절차 차등 적용

 : checkin-checkout comment만으로도 변경 사항을 알 수 있다면,, 말씀하신 것처럼 중요 범위에 대해서만 cq와 연계 관리

    (이전 제가 있던 조직에서는 defect으로 인해 코드 수정할 때는 반드시 cq activity와 연계하도록 하였습니다.)

 

 

그 외로,

CQ 성능이 원인이라면, 이에 대한 개선을 요청할 수도 있을 것 같아요.

 

checkin-checkout시, comment는 어떻게 작성되는지 궁금하네요.

 

 

아참, 그리고 저는

소스코드 레파지토리에 생기는 모든 변경에 대해서는 어떻게든 관리되어야 안정적으로 개발을 할 수 있다고 생각합니다..^^

 

 

2010년 5월 11일 오후 4:09, 김영현 <yhyu...@gmail.com>님의 말:

[이지연]

"어느 수준"에 대한 부연 설명..

 

제가 있던 조직에서는

defect(검증부서에서 발견한)으로 인한 수정에 대해서는 최소한으로 activity로 관리해야겠다고

중요 부분을 정의하였던거죠.

 

중요부분은 조직에서 정의하기에 따라 다를 것 같습니다~

2010년 5월 11일 오후 4:39, 이지연 <ezon...@gmail.com>님의 말:

[김영현]

"제가 있는 조직은 모든 변경사항을 activity로 관리한다"로 되어있는 것 같습니다.

그리고, 현재 단순한 수정이던 defect이 원인이 되는 수정이든 CQ activity를 생성할때 작성한 코멘트가 checkout-checkin 코멘트가 되고있습니다.

말씀해주신 것처럼 적절한 범위와 수준이 고려되어야 할텐데 "이 같은 사항을 고려해 봅시다" 라고 해도 "이건 정책이다" 라고만 대답이 돌아와서 지금 적절한(?) 근거와 이를 지지하는 증거자료를 찾고 있는 중입니다. ㅠ_ㅜ

2010년 5월 11일 오후 4:42, 이지연 <ezon...@gmail.com>님의 말:

[Hans Yoon]

우리 조직도 모든 변경사항은 activity로 관리한다는 기준으로 일을 진행하고 있습니다.
저희는 ClearCase나 CQ는 그런 복잡한 거 안쓰고 그냥 단순하게 SVN + Redmine으로 연동해서 쓰고 있습니다.

SVN에서 변경 전에 activity, 레드마인 용어로는 일감이 만들어지지 않으면 커밋이 안되도록 해서 쓰고 있습니다.
일감의 상태가 "신규"이거나 "보류" 등일 때에도 커밋이 안되고, 테스트 쪽으로 넘어가서 검증 중일 때에도 못합니다.
개발자가 테스트 중인 사항을 다시 수정할 일이 발생하면 재발생 요청하고 기록을 남기도록 하고 있습니다.

그런데, 매우 단순하거나 관리적인 용도로 형상을 변경해야 하는 경우가 발생합니다.
브랜치를 딴다거나, 태깅을 한다거나 또는 구조를 변경하는 (이건 좀 복잡하네요..) 등 말이죠.

이런 경우에는 레드마인의 강력한 워크플로우 기능을 이용해서 좀 색다른 일감을 만들었습니다.
"할일" 이라고 정의된 일감은 개발자나 팀장의 지시할 사항으로 결함이나 개선 등과 좀 거리가 먼 경우인데.
이것에 한해서는 개발자들이 일감을 만들고 자체 종료할 수 있게 권한을 부여했습니다.

저희는 큰 조직이 아니지만
일감과 형상관리를 연결시키지 않았을 때와 했을 때 차이가 많이 발생하더군요.

스크립트를 통해서 일정한 형식에 맞지 않는 로그를 남기는 소스에 대해서는 커밋을 할 수 없게 합니다.
그러니 자연스럽게 커밋 로그에 "소설"을 쓰는 개발자들이 늘어갑니다.
그러니 커밋 로그만 봐도 업무일지가 되더군요.


아, 그리고 저희는 짧은 체크인 주기를 강제합니다.
빌드만 깨먹지 않는다면, 혹은 TDD로 작성된 코드 수행이 멈추지만 않는다면, 수시로 커밋하도록 내부 규정이 정해져 있습니다.
((작은 조직이라서 개발자들이 최종빌드해서 테스테들에게 넘기므로 약간 상황이 다르겠네요.))

수시로 커밋하는 중요한 이유는 커밋할 때마다 작업시간을 기록하게 합니다.
너무 오래 커밋을 안하면 작업시간을 기록할 수 없습니다.
까먹으니까요.

이렇게 집계된 작업시간은 전체적으로 각 개인별로 자동으로 번다운 차트를 그려줍니다.

참고바랍니다.

2010-05-11 (화), 16:48 +0900, 김영현: