올-하! 💚 안녕하세요. 여러분! 올리브영에서 모바일 앱 개발을 담당하고있는 개발요정🧚‍♀️ 입니다. 오늘은 올리브영 안드로이드 Android 테스트앱에 자동배포 프로세스를 적용한 이야기를 해보려고합니다.본론부터 말하는거 좋아하는 성격급한 저같은 분이 계실것같아서, 3줄요약 먼저 준비해봤습니다. ^^• Firebase App Distribution + fastlane 조합으로 했습니다. ♻️• 적용법 핵 쉬우니 아직도 수동배포하는 곳이 있다면 이 글을 꼭 읽어주셨으면 좋겠습니다! 🏃‍ 👇👇👇 왜 적용하게 되었는지, 어떻게 적용했는지 궁금하시다면 고고! 👇👇👇올리브영 Android 앱은 PlayStore Beta로 테스트앱 관리를 하고 있어요. feature 단위 건의 개발이 완료되면 버전별로 테스트 앱을 배포하고 QA를 진행하는 방식입니다. 사실 가장 기본적인 방법일 수도 있는데요, 이 방법에는 몇가지 비효율적인 부분들이 있었습니다.1. 테스트앱을 제공하는데 너무 많은 시간이 걸린다.개발이 완료되면 앱을 빌드한뒤 업로드해야합니다. 우선 PlayStore에 2차 인증을 거친 로그인을 해야하고 , 적당한 릴리즈노트와 함께 앱을 업로드하면, 앱파일을 첨부하는데 일정 시간을 소요한뒤에 앱을 제출할 수 있습니다. 업로드가 완료되면 바로 제공되는 것도 아닙니다. 약 30분의 '출시준비중' 단계를 대기한 후에 테스터들에게 앱이 제공됩니다.2. 앱이 제공되고나면 QA엔지니어에게 직접 알려야한다.앱이 제공되고나면 QA엔지니어에겐 누가 알려줄까요? That's Me..^^.. 🧚‍♀️ 앱 업로드 후 30분동안 '출시준비중' 상태를 뺑글뺑글 도는 것을 지켜보다가, 출시가 완료되면 QA엔지니어에게 호다닥 달려가서 알립니다. (호외요 호외~)3. 테스터가 추가될때마다 일일이 추가해야하고, 오랫동안 기다려야한다.신규 테스터를 추가하기 위해서는, (1) 플레이스토어 계정을 전달받아야하고 (2) 전달받은 계정에 수기로 권한을 등록해야합니다. (3) 권한을 획득한 테스터는 플레이스토어에서 '베타 참여하기' 버튼을 누른 뒤 (4) 약 4시간을 기다려야 테스트앱을 다운받을 수 있습니다.4. 이전 버전을 테스트할 수 없다. 한번에 1개의 버전만 테스트가 가능하다.그나마 TestFlight는 '이전 빌드 보기'통해 과거 버전의 앱도 설치할 수 있어서, iOS는 이 방법으로 기능별 버전을 분리해서 QA를 진행하고 있습니다. 그러나 플레이스토어는 가장 최신 버전의 앱만 제공할 수 있어 동시다발적으로 여러개의 QA를 태울땐 항상 난감합니다. 또 프로덕트에 앱이 출시되고나면, 자연스레 Beta에 등록된 앱이 이전 버전이 되면서 무효화 되기 때문에 Beta앱을 또 다시 빌드해서 등록해주어야합니다. 안 그래도 챙겨야할게 한두개가 아니라 바쁜 배포날.. 또 하나의 배포 태스크인셈이죠..이러한 이유들로, 배포툴 변경과 배포 자동화에 대해서는 사실 꽤 오래전부터 계획되어 왔었습니다. 자동화를 위한 툴은 꽤 여러가지가 있는데요, 보통 Bitrise나 fastlane을 가장 많이 사용하는 것

올-하! 💚 안녕하세요. 여러분! 올리브영에서 모바일 앱 개발을 담당하고있는 개발요정입니다. 오늘은 올리브영 앱을 개발하는 앱개발 파트의 업무 프로세스 수립 및 팩토링 과정을 이야기해보려고 합니다.올리브영앱은 2016년 처음 출시된 이후부터 계속 웹앱으로 유지되고 있었지만, 더 나은 사용자 환경을 위해 하이브리드 플랫폼으로의 개편을 앞두고 있습니다. 그 과정에서 진행된 밑바닥부터 시작하는 프로세스 수립기, 함께 보시죠!월드 베스트셀러 성경의 첫 장 '창세기'는 6일에 걸쳐 신이 세상을 만드는 과정에 대한 이야기입니다. 첫째날에는 빛을 만들고 둘째날에는 하늘을 만들고, 셋째날에는 식물, 그리고 마지막날엔 사람을... 갑자기 웬 성경이냐 하시겠지만, 앱개발 파트의 프로세스 수립기는 흡사 무에서 유를 만드는 성경의 창세기와 비슷합니다.파트의 출범을 위해서는 생각보다 할 일이 많습니다. '업무 프로세스', 참 딱딱한 말이지만 어쨌든 개발업무를 위한 프로세스를 수립해 봅시다! 이 문서의 앱개발 파트 창세기는 총 7장으로 구성되어있습니다.• 6장. 티켓 라이프사이클 정의제가 생각하는 개발업무의 가장 기본은 협업입니다. 한국인들은 한국어로 소통하고 중국인들은 중국어로 소통하듯이, 개발자들끼리 소통하기 위해서는 같은 컨벤션 안에서 소통해야합니다.📖 코드 스타일 가이드 정의앱개발 파트에서 사용하는 언어 stack은 크게 Kotlin, Swift, Typescript가 있습니다. 이 언어들을 사용해서 Android, iOS, ReactNative 플랫폼 앱을 만들어요. 그러니 각 플랫폼별 언어 사용환경에 맞게 코드 스타일을 정의해야합니다. 일반적으로는 각 언어 별로 스타일 가이드를 제공하고 있기 때문에 큰 틀은 이를 따르면 되지만, 조직에 맞는 코드 스타일을 따로 고민할 필요는 있습니다. 예를들면 인덱스 변수를 정의할 때 A 언어에서는 네이밍을 권고하고, B 언어에서는 네이밍을 권고한다면 각 플랫폼에 맞는 권고를 따라갈지, 조직 내 코드 스타일을 수립해서 플랫폼 제약 없이 통일할지 등의 논의가 필요하죠.다음은 올디브 앱개발 파트의 코드 스타일 수립에 베이스가 된 언어 별 스타일 가이드입니다.자, 스타일 가이드를 정했으니 이제 끝난걸까요? 아닙니다. 이미 익숙한 컨벤션들이지만, 몇십 페이지나 되는 스타일가이드를 정확히 외우고 지키기는 어렵습니다. 내가 작성한 코드들이 컨벤션에 맞는지 나 대신 검사해줄 Lint를 적용할것입니다. 마치 중앙선 침범 방지를 위해 가드레일을 설치하는 작업이죠!테스트를 빌드하여 앱이 기능적 요구사항을 충족하는지 확인하는 것 외에도 린트를 통해 코드를 실행하여 코드에 구조적 문제가 없는지 확인하는 것이 중요합니다. lint 도구를 사용하면 구조적 문제로 인해 앱의 안정성과 효율성에 영향을 미치거나 코드 관리에 지장을 줄 가능성이 있는 코드를 찾을 수 있습니다. lint에서 감지된 각 문제는 설명 메시지 및 심각도 수준과 함께 보고되므로 개선이 시급한 순서대로 신속히 우선순위를 정할 수 있습니다. 문제의 심각도 수준을 낮춰서 프로젝트와

안녕하세요. 신사업부문 만화경셀 안드로이드 개발자 오재환입니다. 만화경은 우아한형제들의 웹툰 플랫폼으로서 2020년 5월 구글피처드, 2020올해를 빛낸 인기 앱 우수상, 2020 올해를 빛낸 엔터테인먼트 앱 우수상을 받았습니다! 자랑 좀 하고 싶었어요 저는 2019년 3월에 입사하여 지금까지 만화경 안드로이드를 혼자 개발하고 있는데요 이 글은 저처럼 혼자 혹은 앱을 처음부터 개발하시는 분들을 위해 제가 어떤 부분을 고민하고 신경 써서 앱을 개발했는지를 공유하고자 합니다. 기술 블로그이긴 하나 심도 있는 기술보다는 제가 처음부터 안드로이드 앱을 만들면서 생각했던 것들을 경험 위주로 글을 풀어나가겠습니다. 모든 것의 시작 모든 것은 입사와 함께 시작합니다. 입사 후에는 바로 우아한형제들의 오리엔테이션 과정인 컬쳐캠프를 다녀왔고, 신규입사자 가이드에 있는 것들을 이것저것 세팅하고 나니 첫 주가 벌써 끝나버렸습니다. 그래서 제대로 된 개발은 2주차부터 시작하게 되었습니다. 이때 제게 주어진 상황은 5개월 이내에 앱을 완성해야 했고, 기획과 디자인이 미리 나와 있는 것이 아닌 같이 만들어나가야 하는 상황이었습니다. 그래서 아직 기획과 디자인이 픽스되지 않은 첫 주차 때 최대한 할 수 있는 환경설정을 다 해보려고 했습니다. 개발 첫 주차에는 대체로 환경설정에 몰두했습니다. 위 커밋 메시지들을 보면 컨벤션 아키텍쳐 코드 템플릿 버전관리 CI/CD 이 항목들로 이루어져 있는데 이를 기반으로 어떤 식으로 만화경 안드로이드 앱을 만들었는지를 풀어나가 보겠습니다~ Day1 컨벤션의 날 일단 코드를 작성하기 전에 규칙부터 세워야 한다고 생각합니다. 비록 혼자서 개발할지라도 언젠가는 팀원이 들어올 테고 통일된 규칙을 기반으로 코드를 작성하는 것이 좋다고 생각해서 일단 규칙부터 세우기로 했습니다. 제가 적용한 규칙들은 총 4가지가 있습니다. Code Style Android Lint Ktlint Detekt Git Hooks Code Style 일반적으로 회사 혹은 오픈소스들에는 사용하는 스타일 가이드가 존재하는 경우가 많습니다. 저는 아래 스타일 가이드들을 참고하여 만화경 스타일 가이드를 만들었습니다. 구글 스타일 가이드 스퀘어 자바 & 안드로이드 스타일 가이드 안드로이드 코틀린 스타일 가이드 저는 안드로이드 스튜디오에서 일반적으로 사용하는 코틀린 스타일 가이드 및 xml 가이드를 적용하였습니다. 이 부분은 팀의 취향에 따라 갈릴 수 있습니다. 예를 들어 Square의 안드로이드 코드스타일은 위와 같이 Indent가 2인 형태를 띠고 있습니다. 이 부분은 팀원의 취향껏 서로 합의하고 맞춰주시면 됩니다. Android Lint 코드스타일을 설정해 뒀다면 그 이후에는 정말로 그 코드가 내가 원하는 규칙들에 따라서 작성됐는지 정적분석을 해주는 Lint를 돌리는 단계가 필요합니다. 일단 안드로이드의 기본적인 린트인 Android Lint부터 설정해줍니다. Android Lint는 앱 소스 파일과 lint.xml를 통해서 앱의 문제점들을 해결해 줍니다. Ktlin