팀원을 살리는 개발 도구 개선

IO스튜디오 C2팀에서 팀원을 살리기 위해 개발 도구 개선한 스토리입니다.

Transcript

1. 팀원을 살리는 개발 도구 개선 윤석주 2016.04.19
2. 발표 내용 • 개발 도구 개선으로 – 팀원의 시간을 살려보자 – 팀원의 불만을 없애보자 • 더 좋은 결과물을 낼 수 있도록 도와주자
3. C2팀 개발의 병목은?
4. 타 직군과 소통하는 프로그래머
5. 왜죠??
6. 2개의 이슈 • 모바일 빌드 이슈 • 빌드 리소스 관리 이슈
7. 모바일 빌드 이슈
9. 작업자는 • 내가 만든 것을 모바일에서 직접 보고 싶다 – 결과물의 퀄리티 확인 – PC와 다른 부분 확인 – 당연한 욕구
10. 모바일에서 보고 싶어요 아트, 기획 직군 프로그래머
11. 모바일에서 보고 싶어요 프로그래머 빌드 20분 APK업로드 5분 작업자에게 알림
12. 모바일에서 보고 싶어요 아트, 기획 직군 프로그래머의 시간이 많이 빼앗기니 꼭 필요할 때만 부탁하자
13. 하지만 좋은 게임을 만들기 위해선 김용하. 대인배 개발. 2007
14. 좋은 방향은 • 팀원 누구나 모바일 빌드가 가능하고 – 클릭만으로 빌드가 시작 되고 • 즉시 확인할 수 있는 환경 – APK를 직접 받아 볼 수 있고 – 피드백을 줄 수 있도록
15. 직접 개선해보겠습니다
16. 도구 선택
17. 선택의 이유 • 웹 UI로 모든 설정 가능 • Unity3D 빌드 플러그인 • S3 업로드 플러그인 • Slack 플러그인
18. 웹에서 설정 몇번 클릭만 했을 뿐인데 • SVN 업데이트 후 • Unity3D로 빌드 시키고 • S3에 업로드 하고 • Slack에 알려서 팀에 공유
19. 4시간 정도의 셋팅으로 58번의 빌드를 수행 20일 동안 19시간을 절약
20. 직군에 관계 없이 팀원 누구나 손쉽게 사용 가능 아트 직군 프로그래밍 직군
21. 모바일 빌드 이슈 결론 팀원 누구나 최신 프로젝트 결과물을 클릭 한번으로 팀에 공유 하고 모바일에서 직접 테스트 해 볼 수 있다
22. 빌드 리소스 관리 이슈
23. 빌드를 해야할 상황이 되면 프로그래머 오후 2시 까지 리소스 작업해서 커밋 부탁 드립니다
24. 2시 이후에 검수 하면 프로그래머 헉 리소스가 깨졌네요. 2시 30분까지 수정 부탁드립니다. 브라운님 죄송해요 곧 수정해서 올려 드릴께요 브라운
25. 2시 20분 쯔음에 코니 2시 작업물보다 지금것이 낫네 이제 커밋 해도 되겠지? 프로그래머님 커밋 했어요 브라운
26. 2시 30분에 업데이트 후 프로그래머 브라운님 리소스는 잘 되네요. 어 근데 아까 잘 되던 코니님 리소스가 깨졌어요 헉 죄송해요 수정해서 올려드릴께요. 코니
27. 3시 이후 프로그래머 코니님 리소스는 확인했습니다. 아 근데 어피치님 리소스가 깨지네요 헉 죄송해요 수정해서 올려드릴께요. 어피치
28. 2시에 뽑기로 한 빌드가 7시에 나왔어
29. 작업자는 • 더 좋은 리소스로 바꾸고 싶은 욕구 • 리소스가 나오는 모든 곳에서 확인하기 어려움 • 빌드 마감 이후도 작업 진행 필요 – 커밋을 해야 상급자도 작업물 확인
30. 프로그래머는 • 리소스, 버그 수정 사이드 이펙트로 괴로움 • 업데이트를 안 할 수도 없음 • 경영진 시연이 있는 경우 4~5일 고통받음
31. 해결책은 • 프로그래머가 주도적으로 관리하는 빌드용 브랜치 – 개발 브랜치에서 원하는 작업만 가지고 오도록 • 리소스 문제가 있으면 해결된 리소스만 가지고 옴 – 빌드 이슈가 있어도 정상적인 업무 진행은 가능 하도록 • 빌드가 다른 팀원들의 작업에 영향을 받지 않도록
32. SVN이라서
33. SVN Branch는 헬 • Branch = 폴더 복사
34. 브랜치에 커밋해도 • 내용으로는 어느 브랜치에 커밋 했는지 구분 불가 – 위의 로그에 KOR, DMM, PS4 커밋이 섞여 있음
35. Merge 할때도
36. 반면 Git은
37. Rebase 지원 • 작업중인 브랜치에 새로운 커밋 반영 • Merge hell 예방
38. 사실 다들 알고 있음 • 큐라레도 초창기에는 Git • 기획, 아트 직군이 힘들어 함 – Pull, Fetch, Checkout, Push… – 기획, 아트 직군 사람이 몇 배 많다
39. 추가적인 문제는 • 바이너리가 많으면 git이 매우 느려짐
41. 해결책은 • 기획, 아트 직군은 SVN 쓰고 프로그래머만 Git쓰자 – Git인데 SVN Frontend 없을까? – https://github.com/bozaro/git-as-svn
42. 바이너리 문제는 • Git LFS로 해결 – 바이너리 파일은 hash값만 기록하고 – 실제 파일은 서버에서 받아오는 구조 – Git에는 텍스트 파일만 남게 됨
44. 도입 방법 • Git 저장소 호스팅 용도로 GitLab을 사용 • 기획, 아트 직군을 위해 Git-as-Svn도 같이 설치 – Git-as-Svn의 인증은 GitLab이 담당 • LDAP로 회사 계정과 연동
45. Git 도입 결과 • 도입한지 일주일도 안되서 브랜치 7개! • 프로그래머들이 평화를 찾음 • GitLab을 사용해서 추가적인 기능들이 생김
46. GitLab으로 인한 장점 • 프로젝트 웹 페이지 • 저장소와 연동된 이슈 기능 • 코드 리뷰 • 통계 기능 • Slack 연동
47. 프로젝트 웹 페이지
48. 저장소와 연동된 이슈 기능
49. 저장소와 연동된 이슈 기능 • 이슈와 브랜치가 연동 되어 현재 작업 확인 가능
50. 코드 리뷰 • 리뷰를 받는 시스템을 도입 • 리뷰 후 Merge를 눌러서 GitLab에서 Merge 함
51. 통계 기능
52. Slack 연동
53. 빌드 리소스 관리 이슈 결론 • 제대로 된 브랜치 사용을 위해 Git(GitLab) 도입 – 프로그래머들이 평화를 찾았다 – 개발 브랜치를 쉽게 추가 할 수 있다 – 저장소와 연동된 이슈, 코드 리뷰 가능 • Git-as-Svn으로 기획, 아트에겐 SVN 제공 – 저장소 변경 후에도 문제 없음
55. 결론적으로 개발 도구 개선은 • 프로그래머의 개발 시간을 확보 하였다 • 좋은 문화(코드 리뷰)를 도입 할 수 있게 되었다 • 프로젝트 결과물 개선에 기여 하였다 • 팀원들의 업무 효율을 개선 하였다