ASOS Londroid
2019년 1월 21일, ASOS 본사에서 호스팅한 기술 세미나에 다녀왔다.
컨퍼런스 참여 전에 하이드 파크에 들렸다가 길도 잃고 모르고 엄청 위험한 길로 다니기도 해서 진이 다 빠진 상태로 도착했다.
그렇지만 위에 사진에 보면 스피커가 서는 곳에 드론이 있는데 사진 찍어서 Londroid랑 ASOS 태그 하면 추첨을 통해서 저 드론 준다길래 바로 사진 찍어서 트위터에 올렸다. 결과는 광탈...! 그때 입고 간 옷들이 다 ASOS에서 산 거여서 느낌이 좋았는데 정말 느낌만 좋고 말았다.
(각설하고) ASOS 기술 세미나 세션에서 나왔던 내용들을 정리해봤다.
Session 1. Everything They Don't Tell You About Dynamic Features and Instant Apps (Speaker: Jamie Adkins from Pulselive)
Android Dev Summit '18에서 이 두 가지 기능이 소개된 적이 있었다.
Dynamic Feature https://youtu.be/QdoEcfibG-s?t=1184
Instant App https://www.youtube.com/watch?v=L9J2e5PYXNg
Android Dev Summit '18 참여했을 때 흥미 있게 본 세션이었는데 써 볼 기회는 나지 않았다. Instant Apps은 내가 알기로는 apk 파일로 빌드된 경우에는 못 쓴다고 들었기 때문에 좀처럼 해볼 기회가 없었고, Dynamic Feature는 전 회사에서 두 번정도 운을 띄운 적이 있었지만... 그 환경에서는 현실적으로 불가능해서 호응을 얻기 힘들었다. 그런데 실제로 경험해 본 개발자가 들려주는 생생한 경험담이라니...! 아젠다 떴을 때부터 기대가 많이 되었었다.
<세션 내용>
- Dynamic Features?
- 유동적으로 유저가 원하는 기능만 설치해서 사용할 수 있도록 할 수 있음
- At-Install Delivery - 인스톨 시에 다운 받을 수 있게 함
- Conditional Delivery - 조건에 맞는 기기에만 인스톨 되게 함 (Hardware features, minimum API level 등)
- On demand Delivery - 앱이 피쳐 모듈이 필요하다고 요청하면 다운 받게 함
- Instant Delivery - APK를 다운 받지 않고 실행해서 앱을 경험할 수 있게 함
- 4MB 제한에 대해
- Android/AndroidX를 비롯하여 필수인 것들을 포함하면 2.2MB이고 코드나 에셋이 그 외를 차지 함
- 최종적으로 3.95MB를 만들어서 Instant App을 릴리즈 할 수 있었음
- 특히 이미지 용량을 많이 줄이려고 노력함
- Dependency Injection
- 대거를 사용한 멀티 모듈(다이나믹 피쳐 포함) 환경에서 어떻게 관리할지에 대한 논의가 있었음
- DaggerApplication 필요가 없었음
- 몇몇의 Dependencies는 Singletons으로 설정할 필요가 있음
- Proposal 1 - AppComponent는 :app module에 있도록 함
- Proposal 2 - Application class는 :base module, 그리고 Singleton Scope인 CoreComponent를 제공하게 함.
- Proposal 3 - AppComponent가 CoreComponent에 Singletons을 위해서 Depend하게 함(AppComponent would depend on CoreComponent for any Singletons.)
- Proposal 4 - AppComponent would be built and scoped to the Activities in :app
(한글로 설명하기가 힘든 부분이 있어 영어 그대로 추가합니다. 자세한 내용은 아래 링크 참조)
Everything They Don’t Tell You About Instant Apps — Problems with Dagger Android
Every single problem we hit when migrating the Cricket World Cup 2019 app to dynamic features, and how we solved them.
medium.com
- Manifest Merging
- Manifest Activity 선언부의 Theme 부분에서 처음에 Theme 리소스를 링크 못 하는 문제가 있었음
- 두 가지의 해결 방법이 있었는데 하나는 모든 styles 파일을 :base 모듈로 옮기는 것(그렇지만 파일 용량 제한 때문에 곤란했음)
- 나머지 하나는 stub styles를 :base 모듈에 만드는 것 -> 처음에 이걸로 해결하기로 함
- stub theme이 동작하게 하려면 App bundle로 뽑아야 하는데 APK로 QA에게 전달을 못하게 되는 문제가 발생. APK에서는 stub theme이 정상작동 하지 않았다. -> 결국 모든 styles을 :base 모듈로 결국 옮김
- Fire tips
- 프로가드 룰을 더블 체크 할 것
- AGP 버전은 3.5 이상 사용할 것
- 4MB의 제한을 확인하기 위해 Android Studio의 Apk Analyser 사용
Session 2. How To Deliver Features Faster, With Greater Confidence (Speakers: ASOS Android Team)
보통은 안드로이드 세미나면 안드로이드 개발자만 나와서 발표하거나 가끔 QA 엔지니어만 나와서 발표하는 게 한국에서는 흔한데, 영국에서는 벌써 두 번째로 QA와 Android 개발자가 어떻게 협업해서 결과물의 질을 높이는지에 대한 발표를 들었다. 특히 QA 자동화에 대해서 하나도 모르던 나에게 정말 신세계를 보여준 발표였다. ASOS 세션은 진짜 자세하게 많이 풀어서 설명을 해줬는데, 대기업답게 앱 안정성에 많이 투자하는 느낌이 물씬... 들었다. 특히 맥 미니 몇 개로 클라우드 테스트 돌리는 설명도 나왔었던 걸로 기억하는데, 정말 제대로 검증하는구나 싶었다.
<세션 내용>
ASOS App
- 99.9% Crash Free, 지난 한 해 42번 릴리즈(약 1주에 1번 릴리즈), 79개의 피처를 개발함
개선 전 상황
- (개선 전) 예전에는 1달에 한 번씩 릴리즈 함
- (개선 전) 릴리즈할 때가 되면 릴리즈 브랜치 개발을 멈추고 안정화를 함
- (개선 전) 유닛 테스트는 적정했지만 UI Tests는 없었음
문제점
- 문제점이 고쳐지기까지 한 달을 기다려야 함
- 회귀 테스트 시간이 많이 소요 됨
- 회귀테스트에서 예상하지 못한 이슈나 피쳐가 발견되면 릴리즈가 연기될 수 있음
- 모든 팀들이 영향을 받고 한 번에 한 번 있는 릴리즈가 느려짐
해결 방법
- CI/CD - 애자일을 하는 데에 필요함
- 1번 문제점 → 릴리즈를 자주 하는 것 → 1주에 1번씩으로 바꿈
- 2번 문제점 → 자동 회귀 테스트를 도입함. 현재 10300 Unit Tests, 1500 UI Tests, 30 End to End Test를 계속 해서 돌리고 있음
- 3번 문제점 → 새로운 브랜치 단계를 설정함. QA의 테스트를 거쳐야만 머지 가능한 단계를 만들었음. 실제로 큰 모니터에 develop 브랜치 상황이 stable한지 안 한지를 띄워서 항상 stable하도록 유지함
자동화 Tools
- Webhook을 이용하여 업무 툴을 연결시켜서 사용함
- 자동화 로봇이 하는 일
- 지라에서 티켓을 끊고 in Progress로 넘기면 티켓 이름으로 브랜치를 만들어준다.
- 개발자가 구현하고 PR을 만들면 티켓을 Review로 넘기고, 리뷰 요청, APK 파일까지 생성한다.
- 리뷰가 완료되면 QA가 확인할 수 있도록 label을 달고 지라에서 ready to test로 티켓을 옮겨준다
'Study' 카테고리의 다른 글
| RxJava 공부 정리 - 3 (0) | 2019.10.13 |
|---|---|
| RxJava 공부 정리 - 2 (0) | 2019.07.17 |