code-push-standalone 전환기 및 공식문서 파헤치기

App Center 지원 종료

그동안 App Center의 API 서버를 통해 code-push를 사용해왔던 유저들에게 절망적인 소식이 있다. Visual Studio App Center가 2025년 3월 31일에 종료된다고 발표한 것... 현재 맡고있는 서비스도 appcenter cli를 통해 편리하게 앱의 소소한 개선사항을 반영하곤 했는데 이제 코드푸시를 태우려면 2가지 방법 중 택 1을 해야한다.

1. 자체 서버 구축 혹은 MS Codepush Standalone 직접 설치 및 운영 (무료, 서버비 별도)

App Center 의존성 없이 CodePush 번들과 업데이트 정보를 서버를 구축해 직접 생성하고 업로드하기 혹은 마이크로소프트의 클라우드 컴퓨팅 서비스 Azure를 통해 App Center를 대신하여 배포하는 방법.

2. Expo Update 사용 (Expo Application Services, 유료)

CodePush와 유사한 클라우드 기반 expo publish, expo update 사용하기. 이제 React Native 공식문서에서는 Expo로 실행하는 것을 권장하기도 하고, Expo 생태계가 높은 자유도와 함께 RN프레임워크로서 많이 발전됐다고 한다. 또, 최근엔 웹뷰에 앱을 씌운 형태가 주류가 되어감에 따라 Expo로 시작해 생산성을 이끌어내는 추세도 한 몫하는 듯. 새로운 프로젝트를 시작한다면 무조건 Expo cli로....

 

현재 프로젝트 환경때문에 나는 1번 방법을 택했다. 토스나 숨고에서는 자체적으로 코드푸시 배포/운영을 하고있는 것 같은데 지금 당장 프로젝트에 적용하기에는 지식이 부족하다고 생각되어 나중에 백엔드 개발자님과 함께 고민해봐야 할 과제로 남겨두고, 라이브러리 공식문서를 따라 전환한 경험을 정리하려고 한다. 참고로 나는 이미 @react-native-code-push 라이브러리가 설치되어 있으므로 처음부터 구축하려는 분들은 먼저 App에 셋팅하고 오시길!!

https://github.com/microsoft/code-push-server

GitHub - microsoft/code-push-server: Standalone CodePush server from App Center

 

Azure 계정 생성 및 구독

Azure계정을 생성하고 CodePush Server를 실행하는 데 필요한 Service plan , App service, Storage account 서비스를 구독한다. 그리고 CodePush는 ID 공급자로 깃허브 또는 Microsoft를 사용하므로 인증 목적으로 CodePush에 대한 OAuth 앱 등록이 필요하다고 한다. 이 부분은 백엔드 개발자님이 깃허브 대신 Azure에서 애플리케이션 등록 할 때 설정해주셨다. 결과적으로, 생성된 앱 서비스의 기본 도메인이 server-url이 된다.(ex. codepush-xxxx.azurewebsites.net)

 

React-native-code-push 구성

생성된 server url은 android string.xml파일과 ios Info.plist에 각각 구성해주면 된다.

string.xml

<string moduleConfig="true" name="CodePushServerUrl">server-url</string>

 

Info.plist

<key>CodePushServerURL</key>
<string>server-url</string>

 

Code Push Cli

이제 appcenter cli를 대신해 azure 서버와 상호작용 할 수 있도록 code push cli를 실행해보자.

1. code-push-server 저장소를 로컬에 clone한다.

2. cli 경로로 이동한 다음 npm install

3. npm run build

4. cli를 전역에 설치한다. npm install -g

 

그 후 code-push-standalone 명령어를 통해 등록 절차를 진행한다~

해당 단계 진행 도중 permission denied: code-push-standalone 에러가 났었는데, package.json을 확인해보니 bin 항목에 code-push-standalone이 지정된 파일 경로가 있었다. 

"bin": {

"code-push-standalone": "./bin/script/cli.js"

},
권한 문제인 것 같아 터미널에 chmod +x ./bin/script/cli.js 명령어로 실행 권한을 부여해줬더니 정상적으로 진행됐다.

 

code-push-standalone register <optional: server-url>

server-url은 azure에서 생성된 url을 입력해주면 되고, 실행 후 열리는 브라우저를 통해 계정을 인증하면 된다. 그러면 codepush에 연결된 계정이 생성되고, cli에 로그인 할 수 있는 액세스 키가 생성되는데 터미널에 뜬 Enter your access key: 에 입력해주자. 그럼 로그인 끝! code-push-standalone whoami 로 연결된 id를 확인할 수 있다.

 

App 배포 및 관리

코드푸시를 배포하려면 codepush 서비스에 앱을 등록해야 한다. 별도로 업데이트 관리를 하고 릴리즈 할 수 있도록 플랫폼 별로 android와 ios 앱을 추가해주자!

code-push-standalone app add MyApp-Android
code-push-standalone app add MyApp-iOS

 

react-native로 만들어진 앱은 `release-react`를 통하게 되면 js번들과 asset파일을 기본 경로를 통해 자동으로 생성해주고, build.gradle파일과 Info.plist에 지정된 버전을 추론하여 릴리즈 프로세스를 단순화 해준다. RN프로젝트라면 안 쓸 이유가 없다ㅎ_ㅎ

code-push-standalone release-react <appName> <platform>
-> code-push-standalone release-react MyApp-Android android

 

코드푸시를 배포할 때는 기본적으로 Staging과 Production 둘 다 배포되고, <deploymentName>라는 추가적인 옵션을 통해 Staging혹은 Production으로 지정해 배포할 수 있다. 이 외에도 너무너무 많은 옵션들이 있기 때문에 꼭 문서를 정독하는 것을 추천한다.

code-push-standalone release-react MyApp-ios ios -d Staging
code-push-standalone release-react MyApp-android android -d Staging

 

배포 기록은 아래 history 명령어로 최신순 50개의 기록이 확인 가능하며,

code-push-standalone deployment history MyApp-ios <Staging | Production>

 

특정 배포에 대해 Staging에서 테스트 후 Production 배포를 하고싶은 경우 promote 를 통해 복사하면 된다.

code-push-standalone promote MyApp-ios Staging Production
[--description <description>]
[--label <label>]
[--disabled <disabled>]
[--mandatory]
[--noDuplicateReleaseError]
[--rollout <rolloutPercentage>]
[--targetBinaryVersion <targetBinaryVersion]

 

배포 후엔 patch 명령어를 사용해 설명을 적거나 필수 옵션을 지정할 수 있고,

code-push-standalone patch <appName> <deploymentName>
[--label <releaseLabel>]
[--mandatory <isMandatory>]
[--description <description>]
[--rollout <rolloutPercentage>]
[--disabled <isDisabled>]
[--targetBinaryVersion <targetBinaryVersion>]

 

rollback 명령어를 통해 업데이트 버전을 롤백할 수 있다.

code-push-standalone rollback MyApp-iOS Production

 

롤백에 대해서 문서에서 이야기하는 내용이 처음에는 이해가 잘 안됐는데, 천천히 살펴보니 아래와 같은 릴리즈 히스토리에서 오류가 있어서 v3을 롤백하게 되면

v3 대신 v2의 내용이 포함된 새로운 v4 릴리즈가 생성된다. v3이 설치된 유저는 v4로 강제 업데이트가 되고, v2 유저는 v4가 새로 배포됐어도 v2와 동일한 코드이므로 업데이트되지 않는다.

이전보다 더 옛날 버전으로 롤백을 하고 싶다면 --targetRelease를 지정해주면 된다.

code-push-standalone rollback MyApp-iOS Production --targetRelease v1

그러면 위의 동작과정 처럼 v1과 동일한 내용을 가진 새로운 릴리즈(v5)가 배포되고, 그럼 유저들은 v3에서 v5(=v1)로 업데이트하게 된다.

참고로 code-push release를 실행해서 v1, v2, v3 같은 업데이트를 배포했다면, 그중 v2만 골라서 개별적으로 삭제하는 것은 불가능하다. 아래 clear 명령어는 배포에 대한 모든 릴리즈 히스토리를 초기화 시키는 명령어이니 프로덕션 환경에서는 신중하게 사용하자.

code-push-standalone deployment clear <appName> <deploymentName>

 

마치며

혼자 뚝딱뚝딱 셋팅을 해보았는데 막히는 부분에서는 구글에 찾아봐도 자료가 없어서 많이 애먹었던 경험이였다. 그래도 번역기까지 돌려가며 공식문서에 의존해 공부한 결과 CodePush의 동작원리에 대해 조금 더 이해할 수 있었던 계기가 되었다. 내가 이해한 코드푸시의 흐름은 다음과 같다. 개발자가 앱을 빌드하고 업데이트를 생성하면, CodePush 서버에 업데이트 패키지가 업로드된다. 이 후 배포된 업데이트는 CodePush 서버의 데이터베이스와 스토리지에 저장된다. 클라이언트에서는 앱 실행 시 checkForUpdate()를 호출하여 업데이트를 확인하며, 설정된 CodePush 옵션과 deploymentKey를 활용해 적절한 업데이트를 가져온다.

결론적으로, CodePush 서버가 반드시 Azure에 의존할 필요는 없어 보인다. 오히려 프로젝트 환경에 맞춰 서버와 스토리지를 직접 구축하면, 보안이나 배포 정책을 보다 더 유연하게 관리할 수 있지 않을까... 아직 백엔드 지식이 부족한 만큼, 함께 일하는 개발자님과 상의하며 더 깊이 공부해 나가는 것을 목표로 삼아야겠다.