회사 앱 개발자 부재로 제가 어떻게든 6개월 끌어 갔는데.
이래저래 리서치 하고 했는데 제 주변엔 순수 앱 개발자가 없어서. 개발한당에 여쭙습니다.
현재 사항
1. React-Native 로 서비스 중인 앱이 있음.
2. 개발 완료 후 테스트를 위해 APK를 직접 QA에 전달 후 테스트
3. 2번의 방식이 뭔가 아닌 것 같아서 파이어 베이스를 통한 테스트 배포
4. IOS의 경우 테스트 플라이트를 통해서 QA를 위한 배포.
이렇게 하니까 QA 할때 마다 버전 정보도 올려야 하고, 그러다 보니 버전 정보는 꼬이고.
이력관리는 git 밖에 없어서
버전 마다 어떤 이슈가 있었는지 트래킹도 잘 안되고.
이게 맞나 싶은 겁니다.
여기저기 찾아봐도 최신 앱 개발 트랜드는 어떻게 되는 지 이해가 안 가거나 잘 몰라서 어떻게 하는 지 알고 싶습니다.
아 그리고 build.gradle에서 버전 코드랑, 버전 네임 중 코드만 올리고 버전 네임은 그대로 해도
배포시 문제가 안 된다는데.
이게 맞다는 사람도 있고 아닌 사람도 있어서.
이걸 실제 프로덕션에 올려보면서 테스트 하기가 참 그러네요.. ㅡㅡ;;;
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 에서도 동일하게 사용할 수 있는지는 모르겠네요;;;
iOS는 기기 uuid 등록하기 힘들어서 테스트 플라이트로 하고요.
버전별 수정사항은 이슈에 있을테니까 괜찮지 않나요? 배포할 땐 main 브랜치에서 할거니까 git에서도 보기 쉽고요 .
릴리즈를 위한 branch 가 있을거고, 배포 시점의 git 에 tag 붙여서 관리하면 조금 편하고요.
그러다 보니 테스트 하고 나서 수정 하면 1.1.13, 14, 15 이렇게 버전이 계속 늘어나거든요.
개발팀에서 이력관리는 하고 있는데 QA로 넘길때 어떻게 전달해주고, 버전별 이슈를 전체 공유 하기 위한 툴을 어떤걸 써야할지. JIra를 쓰려다가 QA에서 모른다고 하고, 노션으로 하니까 제대로 적지 않아서 공유가 제대로 안돼서요.
"QA에서 모른다고 하고, 노션으로 하니까 제대로 적지 않아서 공유가 제대로 안돼서" - 가 문제인 것이지요.
Git + 이슈관리 툴을 개발팀 QA 같은 걸 사용해야 합니다. 누군가는 교육하고 끌고 나가는 수 밖에요..
"QA 할때 마다 버전 정보도 올려야 하고, 그러다 보니 버전 정보는 꼬이고.
이력관리는 git 밖에 없어서 버전 마다 어떤 이슈가 있었는지 트래킹도 잘 안되고. "
이런 문제 해결을 위해 git 이 있는건데요 :)
그러다 보니 테스트 하고 나서 수정 하면 1.1.13, 14, 15 이렇게 버전이 계속 늘어나거든요.
다른 곳에서는 QA팀에 git 계정을 주거나 하는지 궁금했습니다.
https://techblog.woowahan.com/2579/
해당 글에는 이슈 처리 방법에 대해서는 논하지 않는데,
jira, github issue 등으로 이슈에 대한 티켓번호 발행, git commit 시 티켓번호로 feature, bugfix 브랜치 생성, commit 시 티켓번호 명시로 이슈 트래킹합니다. (git log 에서 티켓번호로만 검색해도 대충 어떻게 진행되었는지 보이죠.)
APK 파일로 테스트 해도 실제로 안드로이드의 경우 버전 변경이나, 배포 후 설정 등으로 버그가 난 적이 있어서 현재는 내부 테스트 배포로 하고 있습니다.
버전 1.1.1 인데 빌드 번호는 1,2,3,4,5,6,7,.... 계속 늘려가는 방식으로요.
버전과 빌드 번호에 맞춰서 선택 설치하시면 됩니다.
분명 더 좋은 방법이 있을 텐데 하면서 이런 거 저런 거 테스트 해보는데. 아시다시피 개발자는 돈과 시간이 없죠.. 응??
답변 감사합니다.
테플이나 앱번들 테스트는 버전은 그대로 두고 빌드번호만 올려가면서 해도 되고요
실제 앱스토어나 플레이스토어 배포할 때에만 기존 버전 피해서 하면 됩니다.
버전 기록은 배포할 때마다 git에 태그 꼬박꼬박 달아주는게 좋습니다. 안달아도 이력 거슬러가면서 확인은 되지만 상당히 귀찮죠.
보통은 버전+git tag 선에서 마무리하고 혹시 핫픽스들이 꼬여서 버전이랑 코드랑 불일치하면 그 때 커밋 해시 보고 찾습니다.
빌드때 git head 를 포함시켜서 저장한다는것이... 어떤 의미인가요?
bitrise + appcenter 도 좋습니다.
1.2.0 (100) 에서 시작했다면 QA끝난 뒤에는 1.2.0(1xx)가 되겠지요
iOS의 경우에는 버전(1.2.0)은 그대로인 상태에서 코드(?)는 계속 업그레이드 하면서 테스트 배포가 가능하거든요
그래서 최종 버전코드를 기준으로 스토어에 배포 합니다
그리고 git은 master로 병합하고, tag를 달아서 관리하기 편하게 합니다
커밋에 특정 문자열 포함하거나 일정 주기로 변경사항이 있다면 젠킨스가 빌드 돌리고 파이어베이스 앱 디스트리뷰션에 배포합니다.
배포할 때 릴리즈 노트는 이전 빌드부터 이번 빌드까지의 커밋 히스토리(diff) 모아서 같이 보내주고 있고,
jira의 해당 프로젝트에 version 추가해줍니다. (affectedVersion, fixedVersion 필드에 활용)
git sha-1 도 릴리즈 노트에 포함해서 qa/개발 커뮤니케이션시 형상을 특정할 때 사용중입니다.
그리고 jira같은 경우는 qa와 같이 쓸 방법을 모색하시는게 좋을 것 같습니다. (저는 개발 -> QA -> 개발 하고 있습니당)