המסמך הזה מכיל רשימת משימות מומלצות ושיקולים לפני להשיק אפליקציית Firebase בסביבת הייצור.
שיטות מומלצות כלליות לשחרור
יש לוודא שבדקתם את כל השינויים Firebase Local Emulator Suite (למוצרים נתמכים) לפני הפריסה בסביבת הייצור. בדיקה יסודית יכולה למנוע טעויות יקרות.
מתחילים לאכוף את Firebase App Check בכל שירות שתומך בכך. App Check עוזר לוודא שרק לאפליקציות עצמן תהיה גישה ושירותים לקצה העורפי.
כדאי לעיין ברשימת המשימות הכללית לאבטחה ב-Firebase.
שימוש Firebase Remote Config השקות ל- לפרסם תכונות ועדכונים חדשים לאפליקציה באופן בטוח ובהדרגה.
אם עוד לא עשיתם זאת, מומלץ להגדיר הגדרה Firebase Crashlytics. זהו כלי קל משקל לדיווח על קריסות בזמן אמת, שעוזר לכם לעקוב אחרי בעיות יציבות שמשפיעות על איכות האפליקציה, לתת להן עדיפות ולתקן אותן.
הכרת המגבלות של תוכנית התמחור והתשלומים והגדרת התראות לגבי התקציב
חשוב לוודא שלא תחרגו מהמכסות וממגבלות השימוש אחרי שתעבירו את הפרויקטים לסביבת הייצור, במיוחד אם אתם משתמשים בתוכנית Spark ללא עלות. מומלץ לשדרג לתוכנית התמחור Blaze בתשלום לפי שימוש.
מגדירים התראות לגבי תקציב לפרויקט.
שימו לב: התראות לגבי תקציב הן לא מכסות של תקציבים. תקבלו התראות כשאתם מתקרבים לסף שהגדרתם או חורגים ממנו, כדי שתוכלו לבצע פעולות באפליקציה או בפרויקט.
כדאי להגדיר את התכונה התראות ופעולות מתקדמות, כמו פונקציות שישביתו את החיוב בתגובה להתראות.
לעקוב אחר השימוש שלכם במרכזי בקרה ספציפיים למוצר, או במרכז לוח הבקרה שימוש וחיוב במסוף Firebase.
חשוב לוודא שהאפליקציות והפרויקטים ב-Firebase תואמים לשיטות המומלצות
לא משנה אם את/ה מפתח/ת יחיד/ה או צוות בגודל ארגון, חשוב לוודא שהפרויקטים, האפליקציות והמשאבים ב-Firebase מוגנים, מאובטחים ויכולים להתפתח בהתאם לשינויים בצוות שלכם.
כדאי לזכור שפרויקט Firebase הוא רק Google Cloud פרויקט שמופעלים בו השירותים וההגדרות של Firebase. כלומר הרבה שהשיטות המומלצות ש-Google Cloud ממליצה רלוונטיות גם הן Firebase.
שימוש בפרויקטים שונים ב-Firebase לפיתוח, לבדיקה ולייצור.
כדאי להגביל את החשיפה הבלתי צפויה לפרויקט שמשויך לאפליקציה בסביבת הייצור. מידע נוסף זמין במאמר הגדרת תהליכי עבודה לפיתוח.
חשוב להגן על הפרויקטים החשובים, במיוחד על הפרויקט שמשויך לאפליקציה בסביבת הייצור.
שימוש במנעולים למניעת מחיקה של פרויקטים כדי להגן מפני מחיקה בטעות של פרויקטים.
החלת "Prod" את בתוך מסוף Firebase כדי שיהיה קל יותר לזהות את המסלול לסביבת הייצור הסביבה.
אם עדיין לא עשיתם זאת, מומלץ להגדיר Google Cloud ארגון ולהוסיף אליו את הפרויקטים ב-Firebase.
מוסיפים יותר מבעלים אחד לפרויקטים ב-Firebase, במיוחד אם הפרויקט לא שייך לארגון Google Cloud. מידע נוסף על מתי ואיך להקצות בעלים לפרויקט Firebase.
הוספת חברים בפרויקט (שנקראים גם 'עקרונות') כקבוצות Google במקום בנפרד.
שימוש בקבוצות מאפשר להקצות תפקידים לחברי צוות בכמות גדולה, וגם לנהל את הרשאות הגישה לפרויקט ב-Firebase, במיוחד אם חברי הצוות מתחלפים או עוזבים.
מעניקים לכל חבר בפרויקט (כלומר 'עיקרון') רמת גישה מתאימה לפרויקטים ולמשאבים שלכם ב-Firebase. מידע נוסף זמין ב- ניהול הגישה לפרויקט באמצעות Firebase IAM.
חשוב לוודא שכל חבר בפרויקט (נקרא גם 'חשבון משתמש') מגדיר את ההעדפות שלו לקבלת התראות על מוצרים ספציפיים או על סטטוס הפרויקט (למשל, שינויים בתוכנית החיוב או מגבלות מכסות). מידע נוסף זמין ב- קבלת התראות של Firebase.
להגביל את מפתחות Firebase API רק לממשקי ה-API צריכים להיות רשימת ההיתרים של ה-API של המפתח. בנוסף, אפשר לקרוא את המידע על מפתחות API ב רשימת המשימות לאבטחה של Firebase.
הכנת שירותים ספציפיים באפליקציה
לכל מוצר ושירות שמשתמשים בהם באפליקציה יכולים להיות שיקולים ספציפיים כשמשתמשים בהם בסביבת הייצור.
Google Analytics
מגדירים תנאי קהל ל-Google Analytics כדי להתחיל לאסוף נתוני ניתוח החל מהשקת האפליקציה.
מומלץ להפעיל את הייצוא של נתוני Google Analytics אל BigQuery כדי שתוכלו לנתח את הנתונים באמצעות BigQuery SQL או לייצא את הנתונים כדי להשתמש בהם בכלים משלכם.
כדאי להגביל את מאפייני המשתמש למידע שיהיה רלוונטי לכל מחזור החיים של האפליקציה. יש מגבלה על המספר שאפשר ליצור, ואי אפשר להעביר אותם לארכיון.
בדיקת ההגדרות עבור Google Analytics תפקידים עבור הנכסים והחשבונות שלך ב-Google Analytics. ההרשאות האלה מנוהלות בנפרד מההרשאות והתפקידים ב-IAM בפרויקט Firebase.
בודקים את המזהה ב-App Store ואת מזהה הצוות (אם צריך) נכונות הגדרות הפרויקט במסוף Firebase.
App Check
מוודאים שמזהה הצוות נכון בקטע הגדרות הפרויקט במסוף Firebase.
אם עדיין לא עשיתם זאת, כדאי להתחיל לאכוף את Firebase App Check בכל שירות שתומך בכך. App Check עוזר לוודא שרק לאפליקציות עצמן תהיה גישה ושירותים לקצה העורפי.
Authentication
משביתים את כל האפשרויות ספקים שאתם לא משתמשים בהם (במיוחד אימות אנונימי).
אם באפליקציה שלכם נעשה שימוש בכניסה באמצעות חשבון Google, תוכלו להתאים אישית את מסך ההסכמה ל-OAuth.
מתאימים אישית את הדומיין והשולח בשירות השליחה של Authentication.
אם אתם משתמשים בשירותי אימות ב-SMS של Identity Platform, כדאי להתחיל לאכוף את Firebase App Check ולהגדיר מדיניות אזור ל-SMS כדי להגן על האפליקציה שלכם מניצול לרעה של SMS.
מטמיעים טיפול בשגיאות בפלטפורמות של Apple לשגיאות Authentication נפוצות.
מוסיפים גיבוב SHA-1 של הגרסה המשוחררת לאישור החתימה של האפליקציה בקטע Project settings במסוף Firebase. הגיבוב SHA-1 נדרש אם האפליקציה שלך משתמשת כניסה באמצעות מספר טלפון או כניסה באמצעות חשבון Google (שמוגדר בו לקוח OAuth דרישה).
להוסיף בקרת גישה לדומיינים כדי למנוע לשימוש בלתי מורשה. באופן ספציפי, מתן גישה לדומיין הייצור שלך ב: ה הקטע Authentication של מסוף Firebase (חשוב במיוחד אם אתם משתמשים במוצרים מסתמכים על Firebase Security Rules).
Cloud Firestore
מגדירים את Cloud Firestore Security Rules כדי למנוע גישה לא מכוונת לנתונים.
שימוש ProGuard לכיווץ קוד ב-build של הגרסה. בלי ProGuard, ערכת ה-SDK של Cloud Firestore ויחסי התלות שלה עלולים להגדיל את גודל ה-APK.
Cloud Messaging
מומלץ להפעיל את הייצוא של נתוני Cloud Messaging אל BigQuery כדי שתוכלו לנתח את הנתונים באמצעות BigQuery SQL או לייצא את הנתונים כדי להשתמש בהם בכלים משלכם.
מעלים את מפתח האימות של APNS עבור Cloud Messaging לאפליקציות של Apple במסוף Firebase. אם משתמשים באישורי APNS, צריך לוודא שאישור ה-APNS לסביבת הייצור .
Cloud Storage
- מגדירים את Cloud Storage Security Rules כדי למנוע נתונים לא מכוונים גישה.
Crashlytics
חשוב לוודא שכל חבר בפרויקט הרלוונטי (נקרא גם 'חשבון משתמש') מגדיר את ההעדפות שלו לקבלת התראות לגבי Crashlytics או לגבי סטטוס הפרויקט (למשל, שינויים בתוכנית החיוב או מגבלות מכסות). מידע נוסף זמין ב- קבלת התראות של Firebase.
מומלץ להפעיל את הייצוא של נתוני Crashlytics אל BigQuery כדי שתוכלו לנתח את הנתונים באמצעות BigQuery SQL או לייצא את הנתונים כדי להשתמש בהם בכלים משלכם.
(מכשירי Android ו-iOS בלבד) מומלץ להפעיל עזרה עם AI ב-Crashlytics האצת הזמן שנדרש כדי להבין למה קרתה תאונה מה לעשות בעניין הזה.
מעלים את קובץ ה-dSYM של גרסאות build לשימוש ב-Crashlytics. חשוב לוודא ש-Xcode יכול לעבד קובצי dSYM ולהעלות את הקבצים באופן אוטומטי.
העלאה מיפוי של ProGuard לגרסאות build של גרסאות לשימוש ב-Crashlytics. ניתן להעלות סרטונים באמצעות CLI של Firebase.
קישור Firebase אל Google Play כדי לקבל תמונה עשירה יותר לגבי מצב הבריאות של האפליקציה ל-Android. לדוגמה, אפשר: לסנן את דוחות הקריסה של האפליקציה לפי מסלול Google Play, שמאפשר למקד את מרכז הבקרה בגרסאות build ספציפיות.
עבור גרסאות build שמטרגטות את Android ומשתמשים ב-IL2CPP: עליך לוודא שהבנת העלאת סמלים מותאמים לכל גרסת build שאתם מקווים שיהיו לכם סמלים, האם חלו שינויים בקוד או בהגדרות האישיות.
Dynamic Links
- Dynamic Links הוצא משימוש, לכן מומלץ לבצע העברה מ לאחר השיפור. מידע נוסף זמין בתשובות לשאלות הנפוצות בנושא הוצאה משימוש.
Firebase ML
למידע נוסף, ראו הכנת אפליקציית Firebase ML ל-Apple לסביבת הייצור.
מידע נוסף צריך להכין את אפליקציית Firebase ML ל-Android לסביבת הייצור.
Performance Monitoring
חשוב לוודא שכל חבר בפרויקט הרלוונטי (נקרא גם 'חשבון משתמש') מגדיר את ההעדפות שלו לקבלת התראות לגבי Performance Monitoring או לגבי סטטוס הפרויקט (למשל, שינויים בתוכנית החיוב או מגבלות מכסות). מידע נוסף זמין במאמר קבלת התראות מ-Firebase.
נקודות שכדאי להעלות הפעלת הייצוא של נתוני Performance Monitoring אל BigQuery כך שתוכלו לנתח את הנתונים עם BigQuery SQL או לייצא את נתונים לשימוש בכלים משלכם.
Realtime Database
מגדירים את Realtime Database Security Rules כדי למנוע נתונים לא מכוונים גישה.
חשוב לוודא שאתם מוכנים להתאמה לעומס. ל-Realtime Database יש מכסת ברירת המחדל גדולה מספיק לרוב אבל ייתכן שחלק מהאפליקציות יצטרכו קיבולת נוספת.
מגדירים את כללי ProGuard כך שיפעלו עם Realtime Database.
Remote Config
- חשוב לוודא שכללים Remote Config ניסיוניים לא משפיעים על המשתמשים בגרסה היציבה, ושברירת המחדל המתאימה לשרת ולתכונות באפליקציה מופצת באפליקציה.