Android 어플리케이션의 출시 프로세스를 고려하여 2016년 겨울

개시하다


Google Play에서 안드로이드 애플리케이션의 Lilys는 어떻게 만들어졌습니까?
최근 Google PlayPublising API와 Balto를 활용한 개발 프로세스를 구축하고 있기 때문에 평소 애플리케이션을 어떻게 보내는지 소개하고 싶습니다.
앞으로 퍼블리싱 API를 사용하고 싶은 분들과 릴리플로를 개선하고 싶은 분들의 참고가 됐으면 좋겠습니다.

사용 중인 서비스


이번 보도는 절차를 중심으로 소개하며 각 도구의 상세한 설명을 생략했다.
다음은 링크가 준비되어 있으니 관심 있으신 분들은 확인해 주세요.
메인스트림(MainStream) 서비스네요
  • Google Play Publishing API
  • Balto
  • Fabric(Beta)
  • Travis CI
  • GitHub
  • 왜 했어요?


    Lilysplo를 정리하는 배경에서 한 버전의 발표에 너무 많은 시간이 걸렸다.
    최근에는 대부분 2주~1개월 간격으로 업데이트를 발표하지만, Google Play에 발표할 때는 영어/일본어 발표 노트와 앱 내 언어 준비 등으로 개발팀 이외의 사람과 교류하기도 한다.
    향후 현지화의 증가를 감안하면 이런 절차는 더욱 원활해졌다.
    또 개인이 작은 실수를 하기 쉬우므로 수작업을 최소화하고 싶다.수작업 공포

    작업흐름을 만들어 봤어요.


    그래서 이번 주제는 이 과제를 해결하기 위한 것이다
    Google Play API와 GiitHub을 이용하여 개발진이 Pull Request를 사용하는 개발 프로세스에 이 작업을 적용할 수 있는지 연구했습니다.
    이렇게 된 기분이야.
  • 평소의 개발
    GitHub -> Travis CI -> Balto or Fabric (Beta)

  • PullRequest가 Fabric에 발표될 때마다 PullRequest가 통합되면 Balti/Fabric에 동시에 발송됩니다.Balto는 구성원 이외의 피드백, Fabric은 PullRequest 리뷰 등에 사용됩니다.
    발토에 올리는 건 수작업인데 이걸 사용했어요.
    https://github.com/ymegane/gradle-balto-upload-plugin
  • 출시
    GiitHub->Google Pubishing API->Google Play(폐쇄회로)β)

  • 이 프로세스를 가져온 후 Google Play에 업로드할 때는 Publishing API를 통해서만 가능합니다.
    트래비스CI가 포함되지 않은 이유는 마지막에 적혀 있다.

    좀 써봤어요.


    내가 실제로 어떻게 운용하는지 소개할게.

    현지화


    번역 의뢰/리뷰는 기본적으로 GiitHub을 사용합니다.
    Pull Request는 GiitHub에서 그 지점에 직접 제출할 수 있습니다.
    간혹 XML 규칙을 지키지 않는 경우도 있지만 트래비스CI가 파괴될 뿐 전혀 문제가 없다.

    이전 프로세스와 마찬가지로 PullRequest가 릴리즈/제출되면 Fabric에 전송되기 때문입니다.
    개발 환경이 없어도 반영 결과를 확인할 수 있다.

    피드백


    UI 피드백은 주로 Balto를 사용합니다.
    자화자찬이지만 발토는 캡처가 달린 빠른 피드백 도구다.
  • 발토를 살짝 만져봤어요.
    http://qiita.com/gupuru/items/4f3850b0a4780964676a
  • 제품 매니저와 디자이너로부터 받은 피드백은 GiitHub의 issue로 등록됩니다.(※ 2016년 11월β버전 지정 스타일)

    기본적으로 개발 중인 최신판은 언제든지 시도할 수 있다.

    상점 배달


    게시 노트와 Google Play 스토어에 게재된 내용은 편지와 함께 조정됩니다.
    이것도 GiitHub에서 Pull Request를 만들어 진행한다.

    늘 그렇게 말하지만 지난번 발매 노트와는 차이가 있다는 것을 확인할 수 있다
    복잡한 Developer Constore에서 몇 분 동안 작업을 자동화할 수 있습니다.
    기본적으로 apk가 잘못한 사람 오류가 발생하지 않으니 안심하세요.
    PullRequest가 결합되면 Publishing API를 사용하여 업로드합니다.
    지금 사용하고 있는 것은 이쪽의Gradle plugon입니다.
  • GitHub - Triple-T/gradle-play-publisher: Gradle Plugin to upload your APK and metadata to the Google Play Store
  • 참조: http://asmz.hatenablog.jp/entry/use-gradle-play-publisher
  • 다음 설정 진행
    app/build.gradle
    play {
        serviceAccountEmail = "${props.getProperty("service_account")}"
        jsonFile = file("${props.getProperty("keyPath", "")}")
        errorOnSizeLimit = true
        track = 'beta' // or 'production' or 'rollout' or 'alpha'
    }
    
    ./gradlew clean assembleRelease publishApkRelease이렇게 하면...β판본이 공개되다.
    β버전에 올라온 APK에 문제가 없으면 제품판으로 공개한다.
    실제로 Progruard와 관련된 아카이브 처리는 모두 셸스크립트입니다.
    또한 현재 이 작업만 수동으로 수행됩니다.

    과제 등


  • 퍼블리싱 API를 통해 공개되면 발간 전 보고서가 시행되지 않는다Firebase Test Lab 등 다른 방법을 검토해야 한다.
  • Google Play Developer Constore의 사전 보고서 게시 시도
  • 실장 멤버 외에도 기릿허브를 접할 수 있다는 것은 좋은 일이지만, 약속 규칙 등 개발진의 규칙이 관철되면 부담이 커지는데, 역시 기릿허브는 개발자를 위한 도구라 어려움도 있었다.현재 Slack과 Google 문서 등도 함께 사용됩니다.

  • Private Repository라고는 하지만 KeyStore 제출에 저항력이 있어 현재 비즈니스 출시 때만 수동으로 수행되고 있다.

  • Bitrise 등 서비스가 믿을 만하다고 판단하면 자동화를 고려할 수도 있다.
  • 그나저나 개인용이지만 제일 좋아요
  • 매듭을 짓다


    2016 간판을 내걸었지만 비교적 건조한 서비스 집합이라는 점을 알아본 사람이 있을 테니 양해
    Lilysplo에서 자동화를 도입하는 것은 개발자가 개발에 집중하는 시간을 늘리는 데도 중요하다고 생각합니다.
    앞으로도 매일 토론해야 한다.(사실 쓰다 쓰다 보니까 좀 달라졌어.

    좋은 웹페이지 즐겨찾기