· 톺아보기

질문

앱 개발자분들 테스트랑 배포 관리 어떻게 하시나요?

The심이 ·

조회 6,480 · 공감 0 · 댓글 21

회사 앱 개발자 부재로 제가 어떻게든 6개월 끌어 갔는데. 


이래저래 리서치 하고 했는데 제 주변엔 순수 앱 개발자가 없어서. 개발한당에 여쭙습니다. 


현재 사항 

1. React-Native 로 서비스 중인 앱이 있음. 

2. 개발 완료 후 테스트를 위해 APK를 직접 QA에 전달 후 테스트

3. 2번의 방식이 뭔가 아닌 것 같아서 파이어 베이스를 통한 테스트 배포

4. IOS의 경우 테스트 플라이트를 통해서 QA를 위한 배포. 


이렇게 하니까 QA 할때 마다 버전 정보도 올려야 하고, 그러다 보니 버전 정보는 꼬이고.

이력관리는 git 밖에 없어서 

버전 마다 어떤 이슈가 있었는지 트래킹도 잘 안되고. 



이게 맞나 싶은 겁니다. 


여기저기 찾아봐도 최신 앱 개발 트랜드는 어떻게 되는 지 이해가 안 가거나 잘 몰라서 어떻게 하는 지 알고 싶습니다. 


아 그리고 build.gradle에서 버전 코드랑, 버전 네임 중 코드만 올리고 버전 네임은 그대로 해도 

배포시 문제가 안 된다는데.  


이게 맞다는 사람도 있고 아닌 사람도 있어서. 


이걸 실제 프로덕션에 올려보면서 테스트 하기가 참 그러네요.. ㅡㅡ;;;

댓글 21

  1. 퓨리넬 ·
    iOS 의 경우 인증서와 버전, 빌드 번호, 아카이브 및 업로드 자동화를 fastlane 으로 하고 있습니다.
    https://medium.com/hcleedev/ios-%EB%B0%B0%ED%8F%AC-%EC%9E%90%EB%8F%99%ED%99%94-fastlane-%EC%8B%9C%EC%9E%91%EB%B6%80%ED%84%B0-%EC%A0%81%EC%9A%A9%EA%B9%8C%EC%A7%80-3d9107cdc3b4
    그런데 저도 여기 왔는데 이미 다 셋팅이 되어있던거라 어떻게 fastlane 환경을 만드는 지는 모르겠고
    React-Native 에서도 동일하게 사용할 수 있는지는 모르겠네요;;;
  2. The심이 ·
    @퓨리넬님 참고해보겠습니다. 답변 감사합니다.
  3. susemi99 ·
    안드로이드는 플레이스토어에 내부테스트라고 검수 안 받고 배포하는거 있어요. 저는 어지간하면 버전코드랑 이름을 같이 올립니다. 1.1.0 에서 수정사항이 발생하면 1.1.1, 1.1.2, ..., 1.1.17 이런 식으로 세 번째 자리만 바꿔요.

    iOS는 기기 uuid 등록하기 힘들어서 테스트 플라이트로 하고요.

    버전별 수정사항은 이슈에 있을테니까 괜찮지 않나요? 배포할 땐 main 브랜치에서 할거니까 git에서도 보기 쉽고요 .
  4. The심이 ·
    @쎄미님 제가 지금 그렇게 하고 있는데 맞는 방법이었군요. (답변 감사합니다.
  5. 윈드로머 ·
    " QA 할때 마다 버전 정보도 올려야 하고, 그러다 보니 버전 정보는 꼬이고." 이 부분이 잘 이해가 안되네요.
    릴리즈를 위한 branch 가 있을거고, 배포 시점의 git 에 tag 붙여서 관리하면 조금 편하고요.
  6. The심이 ·
    @윈드로머님 설명이 부족했네요. 개발팀에서는 git을 통해 다 관리가 되고 있는데. 이걸 QA 팀으로 넘길때 테스트 플라이트, apk 파일 전달 <- 이런식으로 하고 있습니다.
    그러다 보니 테스트 하고 나서 수정 하면 1.1.13, 14, 15 이렇게 버전이 계속 늘어나거든요.
    개발팀에서 이력관리는 하고 있는데 QA로 넘길때 어떻게 전달해주고, 버전별 이슈를 전체 공유 하기 위한 툴을 어떤걸 써야할지. JIra를 쓰려다가 QA에서 모른다고 하고, 노션으로 하니까 제대로 적지 않아서 공유가 제대로 안돼서요.
  7. 윈드로머 ·
    @The심이님 많은 곳에서 말씀하신 부분이 잘 안지켜져서 문제가 발생합니다.
    "QA에서 모른다고 하고, 노션으로 하니까 제대로 적지 않아서 공유가 제대로 안돼서" - 가 문제인 것이지요.
    Git + 이슈관리 툴을 개발팀 QA 같은 걸 사용해야 합니다. 누군가는 교육하고 끌고 나가는 수 밖에요..
  8. 트위니 ·
    @윈드로머님 도 말씀하셨지만, "git 브랜치 전략" 으로 검색해서 정책을 적용하면 될거 같은데요.

    "QA 할때 마다 버전 정보도 올려야 하고, 그러다 보니 버전 정보는 꼬이고.
    이력관리는 git 밖에 없어서 버전 마다 어떤 이슈가 있었는지 트래킹도 잘 안되고. "

    이런 문제 해결을 위해 git 이 있는건데요 :)
  9. The심이 ·
    @트위니님 설명이 부족했네요. 개발팀에서는 git을 통해 다 관리가 되고 있는데. 이걸 QA 팀으로 넘길때 테스트 플라이트, apk 파일 전달 <- 이런식으로 하고 있습니다.
    그러다 보니 테스트 하고 나서 수정 하면 1.1.13, 14, 15 이렇게 버전이 계속 늘어나거든요.
    다른 곳에서는 QA팀에 git 계정을 주거나 하는지 궁금했습니다.
  10. dante2k ·
    CI/CD 관련해서 배민에 간단한 소개글이 있어서 올려드립니다.
    https://techblog.woowahan.com/2579/

    해당 글에는 이슈 처리 방법에 대해서는 논하지 않는데,
    jira, github issue 등으로 이슈에 대한 티켓번호 발행, git commit 시 티켓번호로 feature, bugfix 브랜치 생성, commit 시 티켓번호 명시로 이슈 트래킹합니다. (git log 에서 티켓번호로만 검색해도 대충 어떻게 진행되었는지 보이죠.)
  11. The심이 ·
    @dante2k님 CI/CD구성은 되어 있습니다. APK 는 어찌 어찌 슬랙으로 떨굴 수 있는데 아이폰은 테스트플라이트 말고는 딱히 대안이 없어서. 리서치 중입니다.
    APK 파일로 테스트 해도 실제로 안드로이드의 경우 버전 변경이나, 배포 후 설정 등으로 버그가 난 적이 있어서 현재는 내부 테스트 배포로 하고 있습니다.
  12. Plenty ·
    iOS 는 빌드 번호만 올려도 테스트 플라이트를 통해 배포 가능합니다.
    버전 1.1.1 인데 빌드 번호는 1,2,3,4,5,6,7,.... 계속 늘려가는 방식으로요.
    버전과 빌드 번호에 맞춰서 선택 설치하시면 됩니다.
  13. The심이 ·
    @Plenty님 대부분 비슷하군요. 앱 쪽은 안 해봐서 내가 하는 게 맞나? 의구심이 들때가 많습니다.
    분명 더 좋은 방법이 있을 텐데 하면서 이런 거 저런 거 테스트 해보는데. 아시다시피 개발자는 돈과 시간이 없죠.. 응??
    답변 감사합니다.
  14. parkboo ·
    iOS는 테스트플라이트(줄여서 테플), 안드로이드는 app bundle로 올려서 플레이스토어를 통한 베타테스트로 진행하고 있습니다.
    테플이나 앱번들 테스트는 버전은 그대로 두고 빌드번호만 올려가면서 해도 되고요
    실제 앱스토어나 플레이스토어 배포할 때에만 기존 버전 피해서 하면 됩니다.

    버전 기록은 배포할 때마다 git에 태그 꼬박꼬박 달아주는게 좋습니다. 안달아도 이력 거슬러가면서 확인은 되지만 상당히 귀찮죠.
  15. The심이 ·
    @parkboo님 제가 하는 방법이 맞기는 맞았군요. (휴우~) 감사합니다.
  16. 고등어 ·
    저희는 빌드 때 git head 를 포함시켜서 저장합니다.
    보통은 버전+git tag 선에서 마무리하고 혹시 핫픽스들이 꼬여서 버전이랑 코드랑 불일치하면 그 때 커밋 해시 보고 찾습니다.
  17. 밍키사랑 ·
    @고등어님 지나가다 궁금해서요...
    빌드때 git head 를 포함시켜서 저장한다는것이... 어떤 의미인가요?
  18. 고등어 ·
    @깜찍군님 해당 빌드 버전이 생성하는 모든 로그에 그 당시의 git head (커밋 해시) 를 출력하도록 하였습니다.
  19. 백수청년 ·
    ms appcenter 배포 시스템도 고려해보세요.
    bitrise + appcenter 도 좋습니다.
  20. 루나네스 ·
    저는 버전은 1.2.0 이번 배포 version name이라면 QA진행 후 수정사항 반영하여 배포할 때는 version code만 올립니다
    1.2.0 (100) 에서 시작했다면 QA끝난 뒤에는 1.2.0(1xx)가 되겠지요

    iOS의 경우에는 버전(1.2.0)은 그대로인 상태에서 코드(?)는 계속 업그레이드 하면서 테스트 배포가 가능하거든요

    그래서 최종 버전코드를 기준으로 스토어에 배포 합니다
    그리고 git은 master로 병합하고, tag를 달아서 관리하기 편하게 합니다
  21. Noelstyle ·
    저는 그냥 젠킨스에 firebase app distributions 으로 배포중입니다.

    커밋에 특정 문자열 포함하거나 일정 주기로 변경사항이 있다면 젠킨스가 빌드 돌리고 파이어베이스 앱 디스트리뷰션에 배포합니다.

    배포할 때 릴리즈 노트는 이전 빌드부터 이번 빌드까지의 커밋 히스토리(diff) 모아서 같이 보내주고 있고,
    jira의 해당 프로젝트에 version 추가해줍니다. (affectedVersion, fixedVersion 필드에 활용)
    git sha-1 도 릴리즈 노트에 포함해서 qa/개발 커뮤니케이션시 형상을 특정할 때 사용중입니다.

    그리고 jira같은 경우는 qa와 같이 쓸 방법을 모색하시는게 좋을 것 같습니다. (저는 개발 -> QA -> 개발 하고 있습니당)

개발한당 최근 글

개발한당 목록 더 보기