gitlab.md

Keyword

gitlab git

Reference

상황/ 궁금증

• 회사 프로젝트 중 개인 관리하는 프로젝트를 gitlab으로 옮김.
• 옮기기로 결심했던 큰 이유는 내가 가지고 있는 자료가 체계적으로 관리되지 않음, 공유가 불편함, text기반의 기록으로는 실제 코드 및 프로젝트 구조와 연관시키기 어렵다는 한계를 느꼈기 때문.
• 개인적으로 협업 프로젝트를 하면서, 사용했던 github-flow 를 쓰면서 자연스럽게 task 관리(한 번에 할 수 있을만큼 작은 단위로 나누는 연습, 누가 담당할지 assign), 쉬운 코드 리뷰 피드백, 나중에 재확인 가능(history) 이 인상적이었다.
• SLiPP에서 테스트기반 스터디를 들으면서, 개인차원의 관리에서 좀 더 나아가, 매끄럽게 공유될 수 있는 문화가 뭘까 생각하게 되었고,
• 개인노트를 share하기 위해서 wiki를, issue tracking 까지는 아니더라도 적어도 발생하는 issue 및 bug를 기록하는 것 자체로 의미가 있겠다는 확신이 들었다.
• 이 시스템?을 적용할 대상 모듈은 현재 혼자 관리하고 있고, 이번년도에 전체 담당팀이 바뀔 수도 있어서, 처음시작부터 끝까지(적어도 퇴사전) 내용을 아는 사람이 나 혼자임에도 잘 share가 잘 안되고 있다는 생각. 프로젝트 담당팀이 넘어가거나, 인수인계가 제대로 되지 않아서 계속 고생해왔던지라 최소한 다른 개발자가 볼 수 있는 문서는 만들어야 하지 않을까 고민에서 시작됨.
• 혼자 관리하는 프로젝트인데 issue tracking 까지 필요할까? 라는 의문이 들어서 다른 개발자 분들에게 물어봤었음.
• 다른 개발자 분들이 혼자 issue tracking 쓴다고 해도 history가 남는 이점, 일 관리(뭐했니? 이거했어요.) 등 도입했을때 괜찮은 여러 관점을 이야기해주셔서 막연하게 '썼을때 좋았었어' 에서 실제로 가치가 있겠구나 확신을 가지게 됨.
• 지금은 최대한 관리비용을 줄이면서(귀찮으면 오래 못씀) 효율적으로 관리할 수 있는 방법이 뭘까 고민 중.

진행

• svn 에서 gitlab으로 옮기면서 주의해야할 점을 기술.
• 업무에서 issue 관리는 처음이다보니, 관리비용과 협업할 사람(인계받을 사람)이 명확하게 알아볼 수 있을 정도로 기술 하는 것 사이에서 균형찾기가 key가 되지 않을까?
• open source 급으로 잘 관리되면 좋겠지만, 다른 사람이 봤을때도 이어갈 수 있을정도로 귀찮지는 않게 정도의 간격은 뭘까
  • 결국 소통에 대해서 깊게 고민하게 될 것 같다.