Fastlane 및 Travis를 사용하여 React 네이티브 애플리케이션 게시

최초로 칼로스쿠스타 블로그에 올라왔어요.

1년 전, I wrote a post은 Fastlane이 React 원본 응용 프로그램의 납품 절차를 개선하는 데 어떻게 도움을 줄 수 있는지에 대해 이야기했다.그 순간, 비록 모든 것이 자동화되었지만, 배치는 여전히 우리 중의 한 사람에게 의존하고, 그는 로켓을 발사하기 위해 장착된 기계를 가지고 있다🚀. 우리는 CI 머신을 통해 지속적으로 응용 프로그램을 납품하여 이 과정을 쉽게 개선할 수 있다.이때 Travis CI에서 구조합니다!👷🏻‍♂️

프로세스

문제를 설명하기 전에 배치 과정의 복잡성을 이해하는 것이 중요하다.
간단히 말해, 우리는 두 개의 플랫폼이 있다: iOS🍏, 안드로이드🤖 플랫폼마다 두 개의 응용 프로그램을 컴파일했습니다. 베타 테스트 응용 프로그램, Canary라고도 합니다.🐤 생산🚀 하나
기본적으로 모든 플랫폼은 차례대로 차도를 통과하는데, 보기에 이렇다👇

Code sign setup✍️

Version management🔖

Native builds📦

Beta testing distribution🐤

Stores distribution🚀

Sourcemaps🗺

Communication🗣

이제 배치 과정의 모든 절차를 깊이 있게 이해하여 우리가 무엇을 하고 있는지 알아보자.

코드 플래그 설정✍️

이 어플리케이션에 서명하는 게 무서워요.😱, 특히 자바스크립트 생태계에서 왔을 때인증서, 프로필, 키...개발팀에서 그것을 사용할 때, 당신은 반드시 완전히 조리가 있어야 합니다.
우리는 codesigning.guide concept에서 Fastlane을 채택했다.기본적으로 이 아이디어는 개발팀에서 인증서를 저장하고 나누어 주는 특정한git 저장소를 제시했다.iOS와 Android 코드 서명 파일을 GitHub의 암호화된 개인 git 저장소에 저장합니다.
그리고 각 배포의 CI 시스템에서 저장소를 복제하고 복호화된 인증서를 설치합니다.iOS에서 CI는 인증서가 설치된 OS X Keychain을 만듭니다.

버전 관리🔖

이 컴퓨터의 생성과 저장은 코드 버전이 흔들려야 합니다.
모든 플랫폼은 자신의 방식으로 버전을 관리하고 번호를 구축한다.이 두 버전 사이의 차이점은 버전은 새 버전을 식별하는 공공 저장 번호로 사용해야 하고, 버전 번호는 증량 식별자로서 각 버전에 변화가 발생한다는 것이다.
안드로이드🤖

공용 버전 번호: versionName

내부 버전 번호: VERSION_CODE

네트워크 간 네트워크 운영 체제🍏

공용 버전 번호: CFBundleShortVersionString

내부 버전 번호: CFBundleVersion 및 CURRENT_PROJECT_VERSION

이러한 속성은 .plist, .pbxproj, .properties 및 .gradle 파일에 저장됩니다.버전 관리를 자동화하고 실행하기 위해 우리는 package.json version number을 우리의 공공 버전 번호의 실제 출처로 사용한다💯. 이것은 우리가 npm version cli command을 사용하여 요동을 관리하는 것을 허락한다.

네이티브 생성📦

우리는 두 대의 기계를 제공하여 이 기계의 응용 프로그램을 구축하고 컴파일해야 한다.
iOS에 대해 우리는 Xcode를 사용하여 macOS 시스템을 설정합니다. 이것은 프로그램을 컴파일하고 서명하는 유일한 방법이기 때문입니다.Android에서는 모든 Android Studio, 소프트웨어 패키지, 도구를 포함하여 Linux 시스템을 제공합니다.
이 기계들은 우리의 CI에 의해 만들어졌는데, 이것은 모든 구축이 새롭고 깨끗한 환경에서 운행된다는 것을 의미한다💻.

베타 테스트 분포🐤

응용 프로그램을 테스트 인원에게 나누어 주기 위해 우리는 iOS에서 TestFlight, 안드로이드에서 HockeyApp을 사용한다.Google Play 테스트 버전을 시도했지만 Hockey App에 비해 앱 출시가 너무 느렸습니다.

매장 배송🚀

응용 프로그램을 상점에 나누어 주기 위해서, 우리는 생산 버전을 iOS의 TestFlight과 안드로이드의 Google Play Store에 업로드할 것이다.방출은 인공으로 완성된다.

원본 지도🗺

붕괴와 오류에 대한 읽을 수 있는 정보를 얻기 위해 Bugsnag이라는 서비스를 사용했습니다.새 버전을 배치할 때마다 디버그 기호 .dSYM과sourcemaps를 Bugsnag에 업로드해야 합니다.

표현🗣

마지막으로, 응용 프로그램을 배치할 때, 우리는 우리의 베타 테스트 인원, 발표 매니저와 개발자에게 통지해야 한다. 우리는 새로운 버전을 가지고 있다.우리는 Slack을 일부 통로에 경보를 보내는 로봇과 함께 사용할 것이다.

문제

매번 우리가 버전을 발표하고 싶을 때마다, 우리는 반드시 수동으로 시작해야 한다🔥 패스트트랙 배포 채널.이것은 인위적인 요소가 필요하다는 것을 의미한다.이것은 시간이 소모되는 과정으로 코드 서명, 편견이 있는 환경, 소프트웨어 업데이트, 본 기기의 플랫폼 의존성 등 원인으로 인해 종종 실패할 수 있다.

기계는 일을 해야 하고, 사람들은 생각을 해야 한다.

의심할 여지없이 우리는 모든 일을 자동화함으로써 이 문제들을 해결하기로 결정했다.

솔루션

해결 방안은 이 자동화 과정을 하나의 시스템에 실시하는 것이다. 우리의 continously delivers 지점은 master을 신기하게 상점으로 밀어낸다🎉, 매니저가 언제 새 버전을 발표할지 자유롭게 결정하도록 하다.마지막으로, 우리는 모든 것을 잊고, 즐거워질 수 있다!❤️
Travis와 Fastlane을 통합하여 애플리케이션을 자동으로 배포하는 방법을 살펴보겠습니다.👏.

스피드 채널

우리는 두 개의 deployment 채널을 가지고 있는데, 하나는 안드로이드용, 하나는 iOS용입니다.나는 그 중의 중요한 부분을 중점적으로 설명하기 위해 차도를 약간 간소화했다.우선 우리는 안드로이드 플랫폼을 배치한 다음에 iOS를 배치한다.
lane는 package.json에서 온 버전 번호를 받았습니다. 제가 전에 말한 바와 같이 npm를 통해 버전 제어를 할 수 있습니다.
우리가 해야 할 첫 번째 일은 공공 버전 번호와 내부 버전 번호를 수정하는 것이다.iOS 채널에서 키체인에 저장하고 응용 프로그램에 서명할 수 있는 setup_certificates이 필요합니다.
그리고 저희가 canary을 시작하겠습니다.🐤 및 production🚀 차도.이 두 사람은 본 컴퓨터의 응용 프로그램을 개발하는 사람이다.

Canary: Beta 테스트 구축, TestFlight 및 Hockey App으로 운송.

Production: Production build, TestFlight 및 Google Play 스토어로 배송.

그리고 모든 원본 맵과 디버그 기호 파일을 Bugsnag에 업로드합니다.
다음에git 지점을 만들어서 commit_and_push_version_bump 채널을 통해 버전 충돌을 제출합니다.잠시 후, iOS 채널에서, 우리는 master 채널을 사용하여 만든git 지점을 git_flow_merge 위에 통합합니다.배치 과정에서 버전을 유지하기 위해서, 우리는 이 문제들을 제출해야 한다.그렇지 않으면 상점에서 오류를 던져야 합니다. 업로드된 버전이 이미 존재합니다!
마지막으로 Slack과 연락하여 두 가지 배포를 소통합니다.
안드로이드🤖

lane :deployment do |version: version|
  bump_version_number(version: version)
  canary
  production
  sh 'npm run repositories:upload:android'
  commit_and_push_version_bump
  slack_notification(platform: 'Android', version: version)
end

네트워크 간 네트워크 운영 체제🍏

lane :deployment do |version: version|
  setup_certificates
  bump_version_number(version: version)
  canary
  production
  sh 'npm run repositories:upload:ios'
  commit_and_push_version_bump
  git_flow_merge(version: version)
  slack_notification(platform: 'iOS', version: version)
end

다음은 우리의git 로그입니다. 한 지점을 master으로 통합하여 배치한 후의 모습입니다.🙌:

트래비스 CI

우리는 build stages을 사용하여 순서대로 3단계로 나누어 배치 과정을 운행한다.테스트를 통과한 후 master 지점에만 애플리케이션을 배포할 수 있습니다.✅.
구축 단계를 살펴보겠습니다.👇

모든 구축 단계는 자신의 공급과 환경이 있다.예를 들어 Deploy iOS은 Xcode와 Node가 있는 macOS machine에서 실행됩니다.js가 설치되어 있고 Deploy Android은 JDK, AndroidSDK, Node가 있는 Ubuntu machine을 사용합니다.js.
테스트 단계✅
첫 번째 단계에서 우리는 들보와 테스트 세트를 실행한 적이 있다.모든 것이 예상대로 진행되도록 확보하다.만약 고장이 발생하면 우리는 자동으로 배치를 정지할 것이다.

- stage: Test and lint ✅
  language: node_js
  node_js: 8.5.0
  install: yarn
  script: npm run test:lint && npm run test:unit

Android 단계🤖
Android stage는 모든 소프트웨어와 의존 항목을 포함하는 Ubuntu machine의 설정을 만들었습니다.그리고 우리는 참새를 만든다🐤 생산🚀 응용 프로그램.그리고 우리는 그것들을 배치한다.약 15분 후⏰ Android 어플리케이션에서 배송됩니다.👏

- stage: Deploy Android 🤖
  if: branch = master AND type = push
  language: android
  jdk: oraclejdk8
  android:
    components:
      - tools
      - platform-tools
      - android-26
      - extra-google-m2repository
      - extra-google-google_play_services
  before_install:
    - nvm install 8.5.0
    - gem install bundler
    - bundle install
  before_script:
    - ./internals/scripts/travis/gitconfig.sh
  install: yarn
  script: npm run deployment:android

iOS 단계🍏
iOS 단계에서 Xcode와 필요한 모든 의존항을 사용하여 설정된 macOS machine을 만듭니다.그리고 우리는 참새를 만든다🐤 생산🚀 응용 프로그램.그리고 우리는 그것들을 배치한다.약 20분 후⏰ iOS 어플리케이션에서 배송됩니다.👏

- stage: Deploy iOS 🍏
  if: branch = master AND type = push
  language: node_js
  node_js: 8.5.0
  os: osx
  osx_image: xcode9.2
  before_install: bundle install
  before_script:
    - ./internals/scripts/travis/gitconfig.sh
  install: yarn
  script: npm run deployment:ios

경험과 교훈

모든 일을 자동화함으로써 가능한 한 인위적인 요소를 피해라!

현지 생태계는 어렵고 때로는 낙담할 수도 있으니 받아들여야 한다.이것은 우리의 전문 지식이 아니다. 왜냐하면 우리는 JS 개발자이기 때문이다. 그러나 많은 사람들과 문서가 도움을 줄 수 있기 때문이다.

제작 공정.

무슨 문제 있어요?