DAY 38-1 | 개인 프로젝트 — 유지보수 (1)

일단 버그가 자꾸 발견된다. 최조의 버전 v1.0.0+1 을 빌드하여 올린 후 환경변수가 누락된 버그와 route가 제대로 설정되지 않은 부분이 있던 버그를 고치기 위해 v1.0.0+2 로 올렸는데, 그 사이에 색상 틴트가 잘못 적용되는 치명적인 버그가 또 발견되어 하루만에 v1.0.1+3 으로 올라갔다. 왜 빌드번호 1에서 2로 갈 땐 semantic version이 안 올랐는데, 2에서 3으로 갈 땐 올랐는가. v1.0.0+2와 v1.0.1+3 사이에 Apple App Store 심사가 통과되었기 때문이다. 첫 배포가 이루어지기 전에는 v1.0.0 을 유지하고 있다가 첫 배포 이후에는 patch version을 하나 올린 거다.

이 정도로 치명적인 버그가 아니라면 이렇게 급하게 올리진 않을 것 같긴 한데. 일단 발견되는 녀석들을 issue로 등록해 놓고 하나씩 꺼내서 처리하기로 했다. 쌓여 있는 이슈들 중 중요도에 따라 우선순위 큐처럼 꺼내서 작업해야지. 버전이 올라가는 거에 따라 tag 및 release도 남기기로 했다.

빌드 가이드

업데이트 절차 중 누락되는 사항이 생기지 않도록 미래의 나를 위한 빌드 가이드도 노션에 작성해 놓았다. 버전 숫자 변경하는 것부터 각각의 스토어에 빌드해서 올린 후 버전 태그 달아서 commit하는 것까지. commit 먼저 하고 빌드/업로드 해도 되긴 하는데, 왠지 commit 하면 작업 끝! 이라는 느낌 때문에 순서를 이렇게 했다.

commit 먼저하고 빌드/업로드를 할 경우, commit에 태그 달고 GitHub에 Release Note 작성해서 Android의 [출시 노트]나 iOS의 [이 빌드에서 업그레이드된 사항]에 업데이트 요약 아래 Release Note 링크를 첨부하는 것도 괜찮을 것 같다고 생각했는데... 아무래도 그 업데이트 요약 텍스트에는 외부 링크를 청부하지 않는 게 일반적이니까.

업데이트/공지사항 알림

새로운 버전이 나왔을 때 사용자에게 알림을 보내주는 게 낫지 않을까 하고 찾아보았더니 앱 진입 시점에 버전 체크를 하여 알림을 띄워주는 방식이 가장 정석적이라고 하더라. 최소 지원 버전, 설치된 버전, 최신 버전을 비교하여 적절히 알림을 띄워 주는 거다.

설치된 버전이 최신 버전보다 낮으면 선택적으로 업데이트하라는 알림 화면을 보여주고, 설치된 버전이 최소 지원 버전보다도 낮으면 업데이트를 강제하는 알림 화면을 보여준다. 이렇게 하면 최소 지원 버전 아래의 앱에 대한 지원은 고려하지 않아도 되기 때문에 운영에 이점이 있다. 단, 최소 지원 버전을 너무 높게 책정하면 사용자가 피곤해질 수 있으니 치명적인 버그 수정이 아니고서는 웬만하면 버전 호환성을 고려하는 게 좋겠다.

그리고 그거랑 별개로 앱 공지사항이 있을 경우 알림 화면에 띄워주면 좋을 것 같더라. 공지사항 모아두는 곳을 따로 만드는 것보다는 공지가 자주 있지는 않을 테니 알림 화면에 두는 걸로 충분할 것 같다.

버전 알림에 업데이트 버튼을 넣든 앱 공지사항 알림에 관련 링크를 넣든 외부 링크 및 스토어 연결에는 url_launcher package가 필요하다고 하더라.

패치 업데이트

뭐가 많다. 버그가 자연발생하는 것 같다. 출판업계에서는 오탈자가 자연발생한다고 주장하더니 여긴 버그가 자연발생하는 모양이다. 프로젝트 기간이 촉박해서 테스트를 충분히 해보지 못한 채 심사를 넣은 탓도 있다. 거의 하루나 이틀에 하나씩은 새 업데이트가 올라가고 있다. 몰아치는 느낌이다. 첫 출시 때는 일단 빼놓고 추후에 업데이트해야지 하고 잠시 미뤄놓은 기능들은 아직 건드리지도 못한 채 v1.0.4+6에 도달했다. 갈 길이 멀구만.