Firebase의 Project를 staging, production으로 나눌 때의 지침

Firebase의 staging과 production의 분리에는 크게 나누어 2가지의 접근법이 있다

1프로젝트 내에 production/staging방향 앱을 등록한다

프로젝트 자체를 분리

필수로 프로젝트를 나누는 패턴

Cloud Firestore를 사용하는 경우

Cloud Functions를 사용하는 경우

스토리지 사용

Hosting에 정적 사이트를 구축하는 경우

위의 기능은 1프로젝트에 1개의 환경만을 만들 수 있으므로 project를 나눌 필요가 있다
각각 로컬로 작업하여 Firebase CLI나 CI를 통해 배포하는 흐름을 밟게 되므로 운영적으로도 project 자체를 나누게 된다

CLI에서 환경을 전환하는 방법 :
htps : // 푹 빠져라. 오, ぇ. 이 m/두 cs/cぃ? hl = 그럼 # p 로지 ct_ あああせ s

필수는 아니지만 나누는 것이 좋은 패턴

Authentication, Remote Config, FCM 등 프로덕션 사용자에게 영향을 줄 수 있는 설정을 터치하는 경우

Remote Config의 키 이름을 hogehoge_stg와 같이 운용으로 나눌 수 있지만, 같은 project에 프로덕션·스테이지의 환경 변수가 타고 있는 것은 사고의 근원이 된다

FCM도 타겟 앱을 신중하게 전환하면 좋지만 인적 실수의 온상이됩니다

Authentication도 말하지 않고 모가나

사용자 수가 적은 상태에서 웹로그 분석을 자주 시청하는 경우

비록 애널리틱스 만 사용하는 (예정) 앱이라고해도,
대시보드에서 매번 production의 앱에 필터를 걸지 않으면 조사 데이터가 흐려지므로 사용자 수가 적은 앱은 주의가 필요.
이것을 매번 할 수 있다면 프로젝트를 나누는 것이 좋습니다.

결론

장래적으로 나누는 경우, 이행이 번거롭거나 하기 때문에 조금이라도 Firebase를 이용한다면 처음부터 나누면 좋다고 생각한다.
그리고 프로덕션 환경을 편집 할 수있는 사람은 권한을 엄격하게 관리하면 사고가 어렵습니다.

홍보

풀 Firebase로 구현 한 개인 앱을 출시했습니다 !!

App Store📱

아래의 기능을 풀 활용한 앱입니다.
가족 · 커플의 작업 관리에 어려움이 있으시면 꼭 사용해보십시오.

Analytics

Authentication

Crashlytics

Firestore

Storage

Cloud Messaging

In-App Messaging

Storage

Remote Config

Dynamic Links