별도의 개발자 및 제품 Firebase 환경
Firebase를 MBaaS로 사용하는 것을 고려하고 있지만 다음 문제에 대한 확실한 해결책을 찾지 못했습니다.
개발 용과 프로덕션 용으로 각각 별도의 Firebase 환경을 설정하고 싶지만 개발 환경과 프로덕션 환경간에 기능 (예 : 원격 구성 설정, 알림 규칙 등)을 수동으로 복사하고 싶지 않습니다. .
신뢰할 수있는 도구 나 방법이 있습니까? 원격 구성 또는 알림 규칙을 처음부터 설정하는 것은 어려운 작업이며 너무 위험 할 수 있습니다.
어떤 제안? 두 개의 별도 환경이있는 것보다 더 나은 방법이 있습니까?
별도의 Firebase 계정을 설정하는 방법을 설명하는 질문에 대한 다른 답변을 게시하기 전에 질문이 아닙니다. 다시 읽으십시오. 문제는 별도의 개발자 계정과 제품 계정간에 변경 사항을 전송하는 방법 또는 수동으로 복사하는 것보다 더 나은 솔루션입니다.
모두가 지적했듯이 둘 이상의 프로젝트 / 데이터베이스가 필요합니다.
그러나 설정 / 데이터 등을 개발에서 프로덕션으로 복사 할 수 있어야한다는 질문에 답하십시오. 나는 똑같은 필요가 있었다. 개발 및 테스트에서 몇 달 동안 데이터를 수동으로 복사하고 싶지 않았습니다.
결과는 데이터를 스토리지 버킷에 백업 한 다음 거기에서 다른 데이터베이스로 복원하는 것입니다. 이 작업을 수행하는 것은 매우 조잡한 방법이며 전체 데이터베이스 백업 / 복원을 수행했지만보다 통제 된 방식으로 해당 방향을 살펴볼 수 있습니다. 나는 그것을 사용하지 않았다-그것은 매우 새로운 것이지만 이것은 해결책일지도 모른다 : NPM Module firestore-export-import
편집 : Firestore 백업 / 내보내기 / 가져 오기 정보 여기 Cloud Firestore 데이터 내보내기 및 가져 오기
Firestore가 아닌 Firebase RTDB를 사용하는 경우이 문서가 도움이 될 수 있습니다. Firebase 자동 백업
프로덕션 데이터베이스가 개발과 동일한 스토리지 버킷에 액세스 할 수 있도록 권한을 올바르게 설정해야합니다. 행운을 빕니다.
firebase-tools firebase use
를 사용하는 경우 사용할 프로젝트를 설정할 수 있는 명령 이 있습니다.firebase deploy
firebase use --add
프로젝트 목록을 불러 와서 하나를 선택하면 별명을 묻습니다. 거기에서 당신은 할 수 firebase use alias
와 firebase deploy
해당 프로젝트에 밀어 것입니다.
개인적으로 Firebase 콘솔에 프로젝트로 my-app 및 my-app-dev가 있습니다.
현재 Firebase를 사용하고 있지 않지만 본인처럼 생각하고 있습니다. 콘솔에서 완전히 별도의 프로젝트를 만드는 방법이 있습니다. 이전 Firebase 사이트에 이것을 추천하는 블로그 게시물이 있었지만 지금은 제거 될 것으로 보입니다. https://web.archive.org/web/20160310115701/https://www.firebase.com/blog/2015-10-29-managing-development-environments.html
또한이 토론은 다음을 권장합니다 : https://groups.google.com/forum/#!msg/firebase-talk/L7ajIJoHPcA/7dsNUTDlyRYJ
이 블로그 포스트 는 디버그 및 릴리스 빌드 유형의 매우 간단한 접근 방식을 설명합니다.
간단히 말해서 :
- 다른 애플리케이션 ID 접미사를 사용하여 각 빌드 유형마다 Firebase에서 새 앱을 만듭니다.
- 최신 JSON 파일로 Android 프로젝트를 구성하십시오.
- applicationIdSuffix를 사용하여 빌드 유형에 따라 다른 애플리케이션 on Firebase와 일치하도록 애플리케이션 ID를 변경하십시오.
=> 자세한 설명은 블로그 게시물을 참조하십시오.
다른 빌드 풍미를 사용 하려면 공식 firebase 블로그 에서이 광범위한 블로그 포스트 를 읽으십시오 . 유용한 정보가 많이 포함되어 있습니다.
희망이 도움이됩니다!
내가 한 방식 :
- 나는 firebase에 대해 2 개의 프로젝트를 가지고 있었다.
- 로컬로 내 앱에는 두 개의 분기가 있습니다. 하나는 DEV이고 다른 하나는 PROD입니다.
- 내 DEV 지점에는 항상 DEV firebase 프로젝트의 JSON 파일이 있으며 PROD에 대해서도 마찬가지입니다.
이 방법으로 JSON을 유지 관리 할 필요가 없습니다.
다른 빌드 유형을 관리해야합니다
이것을 따르십시오
먼저 Firebase 콘솔에서 아이디를 YOURAPPNAME-DEV로 새 프로젝트를 만듭니다.
"Android 앱 추가"버튼을 클릭하고 새 앱을 만듭니다. 예를 들어 com.yourapp.debug로 이름을 지정하십시오. 새로운 google-services.json 파일이 자동으로 다운로드됩니다
프로젝트 src 디렉토리에서 이름이 "debug"인 새 디렉토리를 작성하고 여기에 새 google-services.json 파일을 복사하십시오.
모듈 레벨 build.gradle에서 이것을 추가하십시오
debug { applicationIdSuffix ".debug" }
이제 디버그 빌드를 빌드 할 때 "debug"폴더에서 google-services.json이 사용되며 릴리스 모드에서 빌드 할 때 모듈 루트 디렉토리에서 google-services.json이 고려됩니다.
내 상황 에서이 문제를 해결하기 위해 각각 동일한 Android 프로젝트 (예 : 다른 사람들 applicationId
이 applicationIdSuffix
제안 하지 않은 동일한 프로젝트)를 가진 3 개의 Firebase 프로젝트를 만들었습니다 . 결과적으로 3 개의 google-services.json 파일이 CI (Continuous Integration) 서버에 사용자 정의 환경 변수로 저장되었습니다 . 빌드의 각 단계 (dev / staging / prod)에 대해 해당 google-services.json 파일을 사용했습니다.
dev와 관련된 Firebase 프로젝트의 경우 Android 프로젝트에서 디버그 SHA 인증서 지문을 추가했습니다. 그러나 준비 및 자극을 위해 CI에 APK에 서명했습니다.
다음은 .gitlab-ci.yml
이 설정에서 작동 하는 제거 된 것 입니다.
# This is a Gitlab Continuous Integration (CI) Pipeline definition
# Environment variables:
# - variables prefixed CI_ are Gitlab predefined environment variables (https://docs.gitlab.com/ee/ci/variables/predefined_variables.html)
# - variables prefixed GNDR_CI are Gitlab custom environment variables (https://docs.gitlab.com/ee/ci/variables/#creating-a-custom-environment-variable)
#
# We have three Firebase projects (dev, staging, prod) where the same package name is used across all of them but the
# debug signing certificate is only provided for the dev one (later if there are other developers, they can have their
# own Firebase project that's equivalent to the dev one). The staging and prod Firebase projects use real certificate
# signing so we don't need to enter a Debug signing certificate for them. We don't check the google-services.json into
# the repository. Instead it's provided at build time either on the developer's machine or by the Gitlab CI server
# which injects it via custom environment variables. That way the google-services.json can reside in the default
# location, the projects's app directory. The .gitlab-ci.yml is configured to copy the dev, staging, and prod equivalents
# of the google-servies.json file into that default location.
#
# References:
# https://firebase.googleblog.com/2016/08/organizing-your-firebase-enabled-android-app-builds.html
# https://stackoverflow.com/questions/57129588/how-to-setup-firebase-for-multi-stage-release
stages:
- stg_build_dev
- stg_build_staging
- stg_build_prod
jb_build_dev:
stage: stg_build_dev
image: jangrewe/gitlab-ci-android
cache:
key: ${CI_PROJECT_ID}-android
paths:
- .gradle/
script:
- cp ${GNDR_CI_GOOGLE_SERVICES_JSON_DEV_FILE} app/google-services.json
- ./gradlew :app:assembleDebug
artifacts:
paths:
- app/build/outputs/apk/
jb_build_staging:
stage: stg_build_staging
image: jangrewe/gitlab-ci-android
cache:
key: ${CI_PROJECT_ID}-android
paths:
- .gradle/
dependencies: []
script:
- cp ${GNDR_CI_GOOGLE_SERVICES_JSON_STAGING_FILE} app/google-services.json
- ./gradlew :app:assembleDebug
artifacts:
paths:
- app/build/outputs/apk/
jb_build_prod:
stage: stg_build_prod
image: jangrewe/gitlab-ci-android
cache:
key: ${CI_PROJECT_ID}-android
paths:
- .gradle/
dependencies: []
script:
- cp ${GNDR_CI_GOOGLE_SERVICES_JSON_PROD_FILE} app/google-services.json
# GNDR_CI_KEYSTORE_FILE_BASE64_ENCODED created on Mac via:
# base64 --input ~/Desktop/gendr.keystore --output ~/Desktop/keystore_base64_encoded.txt
# Then the contents of keystore_base64_encoded.txt were copied and pasted as a Gitlab custom environment variable
# For more info see http://android.jlelse.eu/android-gitlab-ci-cd-sign-deploy-3ad66a8f24bf
- cat ${GNDR_CI_KEYSTORE_FILE_BASE64_ENCODED} | base64 --decode > gendr.keystore
- ./gradlew :app:assembleRelease
-Pandroid.injected.signing.store.file=$(pwd)/gendr.keystore
-Pandroid.injected.signing.store.password=${GNDR_CI_KEYSTORE_PASSWORD}
-Pandroid.injected.signing.key.alias=${GNDR_CI_KEY_ALIAS}
-Pandroid.injected.signing.key.password=${GNDR_CI_KEY_PASSWORD}
artifacts:
paths:
- app/build/outputs/apk/
이 솔루션은 너무 불투명하고 유지 관리하기 어려운 build.gradle 트릭에 의존하지 않기 때문에이 솔루션에 만족합니다. 예를 들어, applicationIdSuffix
및 buildType
s를 사용하여 접근 방식을 시도했을 때을 사용하여 빌드 유형을 전환하려고 할 때 계측 테스트를 실행하거나 컴파일 할 수 없다는 것을 알았습니다 testBuildType
. 안드로이드는 debug
buildType
내가 이해할 수없는 특별한 속성을주는 것처럼 보였다 .
사실, CI 스크립은 내 경험상 상당히 투명하고 유지 관리가 쉽습니다. 실제로 내가 설명한 접근 방식은 CI에서 생성 한 각 APK를 에뮬레이터에서 실행했을 때 Firebase 콘솔의 '앱을 실행하여 설치 확인'단계에서 시작한 것입니다.
Checking if the app has communicated with our servers. You may need to uninstall and reinstall your app.
to:
Congratulations, you've successfully added Firebase to your app!
for all three apps as I started them one by one in an emulator.
Firebase has a page on this which goes through how to set it up for dev and prod
https://firebase.google.com/docs/functions/config-env
Set environment configuration for your project To store environment data, you can use the firebase functions:config:set command in the Firebase CLI. Each key can be namespaced using periods to group related configuration together. Keep in mind that only lowercase characters are accepted in keys; uppercase characters are not allowed.
For instance, to store the Client ID and API key for "Some Service", you might run:
firebase functions:config:set someservice.key="THE API KEY" someservice.id="THE CLIENT ID"
Retrieve current environment configuration To inspect what's currently stored in environment config for your project, you can use firebase functions:config:get. It will output JSON something like this:
{ "someservice": { "key":"THE API KEY", "id":"THE CLIENT ID" } }
The way we are doing it is by creating different json key files for different environments. We have used service account feature as recommended by google and have one development file and another for production
I'm updating this answer based on information I just found.
Step 1
In firebase.google.com, create your multiple environments (i.e.; dev, staging, prod)
mysite-dev
mysite-staging
mysite-prod
Step 2
a. Move to the directly you want to be your default (i.e.; dev)
b. Run firebase deploy
c. Once deployed, run firebase use --add
d. An option will come up to select from the different projects you currently have.
Scroll to the project you want to add: mysite-staging, and select it.
e. You'll then be asked for an alias for that project. Enter staging.
Run items a-e again for prod and dev, so that each environment will have an alias
Know which environment you're in
Run firebase use
default (mysite-dev)
* dev (mysite-dev)
staging (mysite-staging)
prod (mysite-dev)
(one of the environments will have an asterisk to the left of it. That's the one you're currently in. It will also be highlighted in blue)
Switch between environments
Run firebase use staging
or firebase use prod
to move between them.
Once you're in the environment you want, run firebase deploy
and your project will deploy there.
Here's a couple helpful links...
Deploying to multiple environments
Hope this helps.
참고URL : https://stackoverflow.com/questions/37450439/separate-dev-and-prod-firebase-environment
'IT박스' 카테고리의 다른 글
비 블로킹 I / O가 멀티 스레드 차단 I / O보다 실제로 빠릅니까? (0) | 2020.08.02 |
---|---|
SASS.js가 있습니까? (0) | 2020.08.02 |
“알고리즘 디자인 매뉴얼”에 대한 솔루션은 어디에서 찾을 수 있습니까? (0) | 2020.08.02 |
Windows 서비스 및 예약 된 작업 (0) | 2020.08.02 |
bash 탭 완성은 어떻게 작동합니까? (0) | 2020.08.02 |