TeamCity 성공 사례 : Bica Studios
BICA STUDIOS 는 지속적으로 영감을 주는 브랜드를 선보이는 최고의 게임 엔터테인먼트 팀입니다.
부분 유료화 방식을 통해 수백만 유저들이 금전적인 부담 없이도 카리스마 넘치는 캐릭터와 새로운 인터랙티브한 경험, 흥미 진진한 세계를 액세스하는 멋진 게임을 개발하고 있습니다.
회사에 어떤 장애물이나 기회에 직면 했었습니까?
비즈니스적인 관점에서 시장 포화와 높은 UA비용 처리를 해야합니다. 또 다른 큰 관심사는 의미 있고 혁신적인 컨텐츠에 따른 강력한 메커니즘의 적절한 사용 검증이었습니다.
우리의 주요 관심사는 기술력이 허락하는 한에서 최대한 빠르게 변화에 대처하는 것입니다.
TeamCity 를 사용하기 전에 어떤 일을 경험하셨습니까?
우리의 빌드 파이프라인은 복잡합니다.
우리의 주력 제품으로 모바일 게임을 한다고 하면, iOS, 안드로이드, 윈도우폰 모든 플랫폼을 타겟으로 해야합니다. 안드로이드 플랫폼에는 구글 플레이 스토어, 아마존, Aptoide 총 3개의 다른 스토어가 있습니다. 각 빌드마다 디버그 및 스토어 버전이 있어야 합니다.
그래서 1 게임에 3개 플랫폼, 5가지 빌드, 10개의 다른 설정이 필요합니다.
각각에 대해 모두 수동으로 따로 설정하고 구성하다 보면, 릴리즈는 단지 시간만 필요한 것이 아닌 또 하나의 일이 되어 버리고 맙니다.
편집기 스크립트나 빌드 프로세스 자동화를 통해 오류를 줄이고 약간의 시간을 절약할 수는 있었지만, 여전히 엄청난 프로세스를 처리하는데 시간을 소모해야 했습니다.
그래서 우리는 CI (Continuous Integration) 를 통해 개발팀의 부담을 줄이기 위한 노력을 시도하기 시작했습니다.
어떤 제품 / 옵션을 고려했습니까?
효율적인 시간 사용을 위한 첫번째 단계는 버튼만으로 각 특정 빌드를 처리할 수 있는 자신만의 툴을 구축하는 것이었습니다. 창조적인 느낌으로 우리는 ‘셋업툴’이라고 불렀습니다.
이 툴을 사용함으로써 서로 다른 빌드에서 컨택스트 스위칭 할 때 걸리는 시간을 절약할 수 있었습니다. 하지만 각각의 개별적인 빌드는 완료하는데까지 약간의 개선만이 있었습니다.
몇몇 팀원들은 이전에 젠킨스에 대한 경험이 있었고, 그래서 우리는 그것을 시도해 보기로 했습니다. 그들의 이전 경험은 단지 사용을 해보았을 뿐이었고, 설정은 아니었습니다. 우리는 셋업을 위한 제품의 거대한 학습 프로세스를 확인하자마자 즉시 포기하고 말았습니다.
어떻게 평가를 했습니까?
우리가 TeamCity 를 시작하기로 결정했을 때 가장 먼저 관심을 끌었던 것은 복잡한 CI 시스템을 신속하게 설치할 수 있다는 것이 었습니다. (1개 서버와 2개 에이전트 구축에 2시간 이하 소요) Unity 빌드를 설정하는 데 도움이되는 MindCandy 플러그인을 발견하여 우리의 만족도는 크게 향상 되었습니다. (이 플러그인은 우리의 주요 목표였던 모바일 빌드를 대상으로하지는 않았습니다).
가장 시간이 많이 소요되는 부분은 따로 있었으며, 그것이 이 글을 작성하는 이유입니다. 이 때 동일한 시행 착오의 과정을 거칠 필요가 없습니다. 시간이 걸린 이유는 튜도리얼과 Unity 측면에서의 적절한 문서 부족 때문이었습니다. 배치 모드에서 편집기를 실행하고 편집기 스크립트에서 정적 함수를 호출하는 기능을 사용하기 위해 시도하는 중에도 최근의 기능들은 여전히 그대로였습니다.
이 벽을 극복해 나가면서 우리는 프로젝트가 매우 생산적으로 변해가는 것을 보았습니다. 모든 것이 처음 시도하는 것이었고, 평가판이었고, 오류투성이었음에도 불구하고, 2일차에 우리의 게임에 iOS 및 구글플레이 모두에서 4가지 다른 작업을 모두 포함하여 빌드 파이프 라인을 구축할 수 있었습니다.
우리의 첫번째 작업을 시도하고 시작할 시간이 다가왔습니다. 우리는 사생결단의 테스트를 했습니다: 게임의 iOS 버전을 빌드하였는데, 이 버전은 가장 시간이 많이 걸리는 작업이었습니다. (약 40분~60분). 21분 후에 빌드 아티팩트가 성공적으로 만들어졌을 때, 우리는 믿을 수 없었습니다. 평가는 끝났고, TeamCity 는 이제 그린라이트가 되었고, 더 이상 칼싸움을 할 필요가 없었습니다.
칼싸움을 하는 대신, 우리는 모든 작업들에 걸리는 시간을 측정하기 바빴습니다. 아래 표는 어떤 일이 있었는지에 대한 요약입니다:
Build Type | Time before TeamCity | Time after TeamCity |
Smashtime iOS | 45-60 min | 18-25 min |
Smashtime GooglePlay | 15-25 min | 5-13 min |
SliceIN iOS | 30-45 min | 18-22 min |
SliceIN GooglePlay | 4-6 min | 1-2 min |
빌드 시간이 절반 이하로 줄어든 일 외에도 디버그 플래그를 비활성화하는 것을 잊거나 최적화 작업을 활성화하는 일 등의 이슈를 피할 수 있게 되었습니다.
무엇이 TeamCity를 계속 사용하게 만들었습니까?
이러한 결과를 감안했을 때 우리는 CI 플랫폼으로 TeamCity 를 선택하지 않을 다른 옵션이 없었고, 다른 모든 플랫폼에 TeamCity 를 천천히 추가해 나갔습니다. 그 후 효율성과 정확성은 급격히 높아졌습니다. 빌드 결과에 대한 우리의 확신은 극도로 높아졌으며 개발자는 전체 프로세스에서 시간을 낭비하지 않게 되었습니다. 이로써 우리는 생산 공정을 완벽하게 완성 할 수 있었고, 쓸데없이 소모되던 시간을 다른 곳에 투자하여 더 많은 자동화와 작업에 투자할 수 있게 되었습니다.
TeamCity 를 사용하여 얻은 주요 성과는 무엇입니까? 다음으로 어떤 단계를 계획하고 있습니까?
두 가지 유형으로 분석됩니다: TeamCity를 CI 플랫폼으로 사용하여 단기간 및 장기간으로 미친 영향이 있습니다.단기 결과는 분명합니다: 빌드 시간 단축으로 제품 개발에 더 많은 시간을 할애 할 수 있습니다. 또한 수작업 단계가 줄어들어 사람의 실수가 줄어들고 빌드 및 전반적인 품질에 대한 확신이 높아집니다.
장기적으로는 우리가 테스트를 위해 쉽게 사용할 수있는 빌드를 가지고 있다는 사실은 더 많은 테스트를 더 자주, 더 정기적으로 할 수 있게 합니다. 이것은 문제를 빨리 발견하고 작은 문제가 나중에 큰 문제로 넘어 가지 않도록 도와줍니다.
전반적으로 이러한 이점들은 제품 개발 파이프 라인에 큰 영향을 미치고 최상의 결과로 바뀝니다.
되돌아 보면, TeamCity 와 함께하는 것이 올바른 선택이었습니다. 더 일찍 시작하지 않은 것을 후회합니다. 복잡하고 수동으로 빌드를 해야하는 프로젝트가 있다면 반드시 시도해 보시기 바랍니다.