별도의 개발 및 Prod Firebase 환경
MBaaS로 Firebase를 사용할 것을 고려하고 있지만 다음 문제에 대한 신뢰할 수 있는 솔루션을 찾을 수 없었습니다.
두 개의 Firebase 환경(하나는 개발용, 하나는 운영용)을 별도로 설정하고 싶지만, 기능(예: 원격 구성 설정, 알림 규칙 등)을 개발 환경과 운영 환경 간에 수동으로 복사하는 것은 원하지 않습니다.
제가 의지할 수 있는 도구나 방법이 있습니까?원격 구성 또는 알림 규칙을 처음부터 설정하는 것은 어려운 작업이며 너무 위험할 수 있습니다.
좋은 의견이라도 있나?두 개의 독립된 환경을 구축하는 것보다 더 나은 접근 방식이 있습니까?
별도의 Firebase 계정을 설정하는 방법을 설명하는 질문에 대한 다른 답변을 게시하기 전에 질문이 아닙니다. 다시 읽어보십시오.문제는 개별 개발 및 프로드 계정 간에 변경 사항을 전송하는 방법 또는 수동으로 복제하는 것보다 더 나은 솔루션입니다.
Firebase-tools 명령이 .firebase use
할 수 .firebase deploy
firebase use --add
프로젝트 목록이 나타나고 하나를 선택하면 별칭을 묻는 메시지가 나타납니다.거기서 당신은 할 수 있습니다.firebase use alias
그리고.firebase deploy
그 프로젝트를 추진할 것입니다.
저는 개인적으로 파이어베이스 콘솔에 my-app과 my-app-dev를 프로젝트로 가지고 있습니다.
모두가 지적했듯이 프로젝트/데이터베이스가 두 개 이상 필요합니다.
그러나 개발에서 생산으로 설정/데이터 등을 복사할 수 있어야 한다는 점에 대한 귀하의 질문에 답하기 위해섭니다.저도 똑같은 욕구가 있었습니다.몇 달 동안 개발 및 테스트를 하면서 데이터를 수동으로 복사하고 싶지 않았습니다.
그 결과 데이터를 스토리지 버킷에 백업한 다음 거기서 다른 데이터베이스로 복원했습니다.전체 데이터베이스 백업/복원 작업을 수행한 것은 상당히 거친 작업이지만, 이 방향을 통해 보다 제어된 방법을 찾을 수도 있습니다.저는 그것을 사용해 본 적이 없습니다 - 그것은 매우 새로운 것입니다 - 하지만 이것은 해결책일 수 있습니다: NPM 모듈 firestore-export-import.
편집: Firestore 백업/내보내기/가져오기 정보 여기에 Cloud Firestore 데이터 내보내기 및 가져오기
Firestore가 아닌 Firebase RTB를 사용하는 경우 이 설명서가 도움이 될 수 있습니다.
운영 데이터베이스가 개발과 동일한 스토리지 버킷에 액세스할 수 있도록 하려면 사용 권한을 올바르게 설정해야 합니다.행운을 빌어요.
저는 현재 파이어베이스를 사용하고 있지 않지만, 당신처럼 생각하고 있습니다.콘솔에 완전히 별도의 프로젝트를 만드는 것이 방법인 것 같습니다.예전 파이어베이스 사이트에 이것을 추천하는 블로그 게시물이 있었는데, 지금은 제거될 것으로 보입니다.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/7dsNUTTLYRYJ
내가 한 방법은:
- 파이어베이스에 두 개의 프로젝트가 있었습니다. 하나는 DEV용이고 다른 하나는 PROD용입니다.
- 지역적으로 내 앱에는 DEV라는 이름과 PROD라는 이름의 두 개의 지점도 있었습니다.
- 제 DEV 지사에는 항상 DEV Firebase 프로젝트의 JSON 파일과 마찬가지로 PROD용 파일이 있습니다.
이렇게 하면 JSON을 유지할 필요가 없습니다.
다양한 빌드 유형을 관리해야 합니다.
따라오세요
먼저 Firebase 콘솔에서 새 프로젝트를 만듭니다. 이름 ID는 YOURAPPNAME-DEV입니다.
"안드로이드 앱 추가" 버튼을 클릭하고 새 앱을 만듭니다.com이라고 이름 지어주세요.예를 들어, 당신의 앱.vmdk.새 Google-services.json 파일이 자동으로 다운로드됩니다.
프로젝트 아래에서 src 디렉터리를 만들고 이름이 "debug"인 새 디렉터리를 만들고 여기에 새 Google-services.json 파일을 복사합니다.
모듈 수준의 build.gradle에서 다음을 추가합니다.
debug { applicationIdSuffix ".debug" }
이제 "debug" 폴더에서 debug build google-services.json이 사용되고 모듈 루트 디렉터리에서 릴리스 모드로 빌드할 때 Google-services.json이 고려됩니다.
방금 찾은 정보를 바탕으로 이 답변을 업데이트합니다.
1단계
firebase.google.com 에서 여러 환경(예: 개발, 스테이징, prod)을 생성합니다.
마이사이트 개발
나의 사이트 방문자
나의 사이트 방문자
2단계
기본값으로 사용할 직접(예: dev)으로 이동합니다.
»firebase deploy
배포가되면 를 합니다.firebase use --add
현재 보유하고 있는 다른 프로젝트 중에서 선택할 수 있는 옵션이 나타납니다.
추가할 프로젝트(mysite-staging)로 스크롤하여 선택합니다.
그러면 해당 프로젝트의 별칭을 묻는 메시지가 표시됩니다.스테이징을 입력하십시오.
각 환경이 별칭을 가질 수 있도록 prod 및 dev에 대해 항목 a-e를 다시 실행합니다.
현재 환경 파악
려달을 합니다.firebase use
default (mysite-dev)
* dev (mysite-dev)
staging (mysite-staging)
prod (mysite-dev)
하나의 환경 왼쪽에 별표가 표시됩니다.그게 당신이 현재 타고 있는 사람입니다.또한 파란색으로 강조 표시됩니다.)
환경 간 전환
려달을 합니다.firebase use staging
또는firebase use prod
그들 사이를 이동하는 것.
원하환도실면행달을 실행합니다.firebase deploy
프로젝트가 거기에 배치됩니다.
여기 몇 가지 유용한 링크가 있습니다...
이게 도움이 되길 바랍니다.
테스트 및 UAT를 위해 로컬 개발 서버에서 새로운 Firebase 에뮬레이터의 인스턴스를 실행하기로 선택하여 GCP를 완전히 배제했습니다.이 사용 사례에 맞게 설계되었습니다.
https://firebase.google.com/docs/emulator-suite
이 블로그 게시물은 디버그 및 릴리스 빌드 유형과 함께 매우 간단한 접근 방식을 설명합니다.
간단히 말해서,
- 다른 애플리케이션 ID 접미사를 사용하여 각 빌드 유형에 대해 새 App on Firebase를 만듭니다.
- 최신 JSON 파일로 Android 프로젝트를 구성합니다.
- applicationIdSuffix를 사용하여 빌드 유형에 따라 Firebase의 다른 앱과 일치하도록 응용 프로그램 ID를 변경합니다.
자세한 설명은 블로그 게시물을 참조하십시오.
다양한 빌드 버전을 사용하려면 공식 파이어베이스 블로그의 이 광범위한 블로그 게시물을 읽어보십시오.그것은 많은 귀중한 정보를 포함하고 있습니다.
도움이 되길 바랍니다!
프로젝트를 . 각 프로젝트 동일한 Android 프로젝트, Android 프로젝트)를 가지고 .applicationId
를 applicationIdSuffix
다른 사람이 제안함).따라서 사용자 지정 환경 변수로 CI(Continuous Integration) 서버에 저장한 3개의 Google-services.json 파일이 생성되었습니다.빌드의 각 단계(dev/staging/prod)에 해당하는 Google-services.json 파일을 사용했습니다.
개발과 관련된 파이어베이스 프로젝트의 경우 안드로이드 프로젝트에서 디버그 SHA 인증서 지문을 추가했습니다.하지만 준비와 홍보를 위해 저는 단지 CI가 APK에 서명하도록 할 뿐입니다.
에 옷을 벗은 옷을것입다니벗은이것은-▁stripped가 있습니다..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/
이 솔루션은 너무 불투명해서 유지하기 어렵다고 생각하는 빌드.그래들 트릭에 의존하지 않기 때문에 만족합니다.예를 들어, 다음을 사용하여 접근법을 시도했습니다.applicationIdSuffix
다른 그에밖.buildType
다음을 사용하여 빌드 유형을 전환하려고 할 때 계측된 테스트를 실행하거나 컴파일할 수 없습니다.testBuildType
는 Android에 하는 것처럼 .debug
buildType
제가 이해하기 위해 조사할 수 없었던 것.
제 경험상 CI 스크립은 매우 투명하고 유지보수가 쉽습니다.실제로, 제가 설명한 접근 방식은 효과가 있었습니다.CI에서 생성한 각 APK를 에뮬레이터에서 실행했을 때 Firebase 콘솔의 "설치 확인을 위해 앱 실행" 단계가
앱이 서버와 통신했는지 확인하는 중입니다.앱을 제거하고 다시 설치해야 할 수도 있습니다.
대상:
축하합니다. Firebase를 앱에 성공적으로 추가했습니다!
에뮬레이터에서 하나씩 시작하면서 세 개의 앱 모두에 대해.
파이어베이스에는 개발 및 프로드를 위해 설정하는 방법을 설명하는 페이지가 있습니다.
https://firebase.google.com/docs/functions/config-env
프로젝트에 대한 환경 구성 설정 환경 데이터를 저장하려면 Firebase CLI에서 firebase functions:config:set 명령을 사용할 수 있습니다.각 키는 마침표를 사용하여 관련 구성을 함께 그룹화할 수 있습니다.키에는 소문자만 사용할 수 있으며 대문자는 사용할 수 없습니다.
예를 들어 "Some Service"에 대한 클라이언트 ID 및 API 키를 저장하려면 다음을 실행합니다.
firebase functions:config:set someservice.key="THE API KEY" someservice.id="THE CLIENT ID"
현재 환경 구성 검색 프로젝트의 환경 구성에 현재 저장된 내용을 검사하려면 firebase 함수:config:get을 사용합니다.다음과 같은 JSON을 출력합니다.
{ "someservice": { "key":"THE API KEY", "id":"THE CLIENT ID" } }
파이어베이스에서 개발 및 생산 환경을 사용하여 토우 프로젝트 생성 3에서 json 파일 다운로드
다음과 같이 SDK를 설정합니다. https://firebase.google.com/docs/android/setup 또는 Crashlytics의 경우 https://firebase.google.com/docs/crashlytics/get-started?platform=android .
먼저 각 빌드에 대해 각각의 google_services.json을 배치합니다.다음 위치를 입력합니다.
app/src/debug/google_services.json
app/src/test/google_services.json
app/google_services.json
참고: 루트 app/google_services.json 빌드 변형에 따라 이 파일이 있어야 합니다. 이 파일은 루트 json 파일의 json 코드를 복사합니다.
이제 앱의 build.gradle에서 몇 가지 gradle 작업을 수행하여 적절한 google_services.json을 app/google_services.json으로 자동 이동합니다.
app/Gradle 파일에 복사
task switchToDebug(type: Copy) {
description = 'Switches to DEBUG google-services.json'
from "src/debug"
include "google-services.json"
into "."
}
task switchToRelease(type: Copy) {
description = 'Switches to RELEASE google-services.json'
from "src/release"
include "google-services.json"
into "."
}
좋습니다. 그러나 앱을 빌드하기 전에 이러한 작업을 수동으로 실행해야 하는 것은 번거롭습니다.assemblyDebug 또는 :assemblyRelease가 실행되기 전에 위의 적절한 복사 작업이 실행되기를 원합니다.다음과 같은 경우 어떻게 되는지 살펴보겠습니다.assemblyRelease를 실행합니다. /gradlew 파일에 복사합니다.
Zaks-MBP:my_awesome_application zak$ ./gradlew assembleRelease
Parallel execution is an incubating feature.
.... (other tasks)
:app:processReleaseGoogleServices
....
:app:assembleRelease
:app:processGoogle 서비스 릴리스 작업을 확인합니다.이 작업은 루트 google_services.json 파일을 처리하는 작업을 담당합니다.올바른 Google_services.json이 처리되기를 원하므로 사전에 복사 작업을 즉시 실행해야 합니다.build.gradle에 추가합니다.평가 후 동봉한 내용을 참고하십시오.
app/Gradle 파일에 복사
afterEvaluate {
processDebugGoogleServices.dependsOn switchToDebug
processReleaseGoogleServices.dependsOn switchToRelease
}
이제 언제든지 :app:processReleaseGoogle 서비스가 호출되면 새로 정의된 :app:switchToRelease가 호출됩니다.debug buildType과 동일한 논리입니다.:app:assemblyRelease를 실행할 수 있으며 릴리스 버전인 google_services.json은 앱 모듈의 루트 폴더에 자동으로 복사됩니다.
환경에 따라 서로 다른 json 키 파일을 생성하는 방법이 있습니다.우리는 구글의 추천에 따라 서비스 계정 기능을 사용했으며 하나의 개발 파일과 다른 개발 파일을 생산용으로 가지고 있습니다.
언급URL : https://stackoverflow.com/questions/37450439/separate-dev-and-prod-firebase-environment
'sourcecode' 카테고리의 다른 글
부트스트랩 버튼 드롭다운 제목에 선택한 항목을 표시하는 방법 (0) | 2023.08.12 |
---|---|
fragment에서 getSupportFragmentManager()에 액세스하려면 어떻게 해야 합니까? (0) | 2023.08.12 |
UI WebView에서 WKWebView로 마이그레이션 (0) | 2023.08.12 |
UI WebView의 쿠키는 어디에 저장됩니까? (0) | 2023.08.12 |
PM2의 클러스터 및 포크 모드 차이 (0) | 2023.08.12 |