במסמך הזה מופיעה רשימת שיטות מומלצות ושיקולים שכדאי לקחת בחשבון לפני השקת אפליקציית Firebase בסביבת הייצור.
שיטות מומלצות כלליות להפצה
לפני שפורסים את השינויים בסביבת הייצור, חשוב לוודא שבדקתם את כל השינויים בFirebase Local Emulator Suite (למוצרים נתמכים). בדיקות יסודיות יכולות לעזור לכם להימנע מטעויות יקרות.
מתחילים לאכוף Firebase App Check לכל שירות שתומך בכך. App Check עוזר לוודא שרק האפליקציות שלכם יכולות לגשת לשירותים ולמשאבים של ה-Backend.
כדאי לעיין ברשימת הבדיקה הכללית של Firebase בנושא אבטחה.
כדאי להשתמש בFirebase Remote Config השקות מדורגות כדי להשיק תכונות חדשות ועדכונים לאפליקציה בצורה בטוחה והדרגתית.
אם עדיין לא עשיתם את זה, כדאי להגדיר את Firebase Crashlytics. זהו כלי קל משקל לדיווח על קריסות בזמן אמת, שעוזר לכם לעקוב אחרי בעיות יציבות שפוגעות באיכות האפליקציה, לתת להן עדיפות ולתקן אותן.
הכרת המגבלות של תוכנית התמחור והתשלומים והגדרת התראות לגבי תקציב
חשוב לוודא שלא תגיעו למגבלות השימוש ולמכסות אחרי שתעברו לשלב הייצור, במיוחד אם אתם משתמשים בתוכנית Spark ללא עלות. כדאי לשדרג למינוי Blaze בתשלום לפי שימוש.
הגדרת התראות לגבי תקציב לפרויקט.
חשוב לציין שהתראות על תקציב לא מגבילות את התקציב, אלא רק שולחות התראות. התראה תשלח לכם הודעות כשאתם מתקרבים לסף שהגדרתם או חורגים ממנו, כדי שתוכלו לפעול באפליקציה או בפרויקט.
מומלץ להגדיר התראות ופעולות מתקדמות, כמו פונקציות שישביתו את החיוב בתגובה להתראות.
אם אתם משתמשים ב-Firebase AI Logic, Firebase App Hosting, Cloud Functions for Firebase ו-Firebase Extensions, מומלץ מאוד להגדיר תקרה להוצאות. אם הפרויקט יגיע לתקציב שהוגדר לשירות הרלוונטי, השירות יושהה.
אפשר לעקוב אחרי השימוש במרכזי הבקרה הספציפיים למוצרים או במרכז הבקרה המרכזי שימוש וחיוב במסוף 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.
הכנה של שירותים ספציפיים שנעשה בהם שימוש באפליקציה
לכל מוצר ושירות שבהם נעשה שימוש באפליקציה שלכם עשויות להיות שיקולים ספציפיים כשמשתמשים בהם בסביבת ייצור.
Firebase AI Logic
- אפשר לעיין ברשימת המשימות להכנה לשימוש ב-Firebase AI Logic.
Google Analytics
מגדירים תנאים לקהל היעד של Google Analytics כדי להתחיל לאסוף נתוני ניתוח החל מההשקה של האפליקציה.
מומלץ להפעיל ייצוא של נתוני Google Analytics אל BigQuery כדי שתוכלו לנתח את הנתונים באמצעות SQL של BigQuery או לייצא את הנתונים לשימוש בכלים משלכם.
כדאי להגביל את מאפייני המשתמש למידע שיהיה רלוונטי למחזור החיים של האפליקציה כולה. יש מגבלה על מספר המאפיינים שאפשר ליצור, ואי אפשר להעביר אותם לארכיון.
בודקים את ההגדרות של Google Analytics התפקידים בנכסים ובחשבונות שלכם ב-Google Analytics. ההרשאות האלה מנוהלות בנפרד מההרשאות והתפקידים של IAM בפרויקט Firebase.
מוודאים שמזהה האפליקציה ב-App Store ומזהה הצוות (אם צריך) נכונים בהגדרות הפרויקט במסוף Firebase.
App Check
חשוב לוודא שמזהה הצוות נכון בהגדרות הפרויקט במסוף Firebase.
אם עדיין לא עשיתם זאת, התחילו לאכוף את Firebase App Check בכל שירות שתומך בכך. App Check עוזר לוודא שרק האפליקציות שלכם יכולות לגשת לשירותים ולמשאבים של ה-Backend.
Authentication
משביתים את כל הספקים שלא משתמשים בהם (במיוחד אימות אנונימי).
אם האפליקציה שלכם משתמשת בכניסה באמצעות חשבון Google, כדאי להתאים אישית את מסך ההסכמה ל-OAuth.
התאמה אישית של הדומיין והשולח עבור Authentication שירות שליחת האימיילים.
אם אתם משתמשים בשירותי אימות ב-SMS של Identity Platform, מומלץ לאכוף Firebase App Check ולהגדיר מדיניות אזורית ל-SMS כדי להגן על האפליקציה מפני שימוש לרעה ב-SMS.
הטמעת טיפול בשגיאות בפלטפורמות של אפל עבור שגיאות Authentication נפוצות.
מוסיפים את הגיבוב SHA-1 של גרסת ההפצה של אישור החתימה של האפליקציה בהגדרות הפרויקט במסוף Firebase. הגיבוב (hash) מסוג SHA-1 נדרש אם האפליקציה שלכם משתמשת בכניסה באמצעות מספר טלפון או בכניסה באמצעות חשבון Google (שדורשת לקוח OAuth).
הוספת בקרת גישה לדומיינים כדי למנוע שימוש לא מורשה. במיוחד, צריך לאפשר גישה לדומיין של הסביבה הפרודקטיבית בקטע Authentication במסוף Firebase (חשוב במיוחד אם משתמשים במוצרים שמסתמכים על Firebase Security Rules).
Cloud Firestore
מגדירים את Cloud Firestore Security Rules כדי למנוע גישה לא מכוונת לנתונים.
כדאי להשתמש ב-ProGuard לכיווץ קוד בגרסת build להפצה. בלי ProGuard, ה-Cloud Firestore SDK והתלויות שלו יכולים להגדיל את גודל ה-APK.
Cloud Messaging
מומלץ להפעיל ייצוא של נתוני Cloud Messaging אל BigQuery כדי שתוכלו לנתח את הנתונים באמצעות SQL של BigQuery או לייצא את הנתונים לשימוש בכלים משלכם.
מעלים את מפתח האימות של APNS עבור Cloud Messaging באפליקציות של אפל במסוף Firebase. אם משתמשים באישור APNS, צריך לוודא שאישור ה-APNS של סביבת הייצור הועלה.
Cloud Storage
- מגדירים את Cloud Storage Security Rules כדי למנוע גישה לא מכוונת לנתונים.
Crashlytics
חשוב לוודא שכל חבר צוות בפרויקט (שנקרא גם "הגורם העיקרי") מגדיר את ההעדפות שלו לקבלת התראות לגבי Crashlytics או מצב הפרויקט (למשל שינויים בתוכנית החיוב או במגבלות המכסה). מידע נוסף זמין במאמר בנושא קבלת התרעות מ-Firebase.
מומלץ להפעיל ייצוא של נתוני Crashlytics אל BigQuery כדי שתוכלו לנתח את הנתונים באמצעות SQL של BigQuery או לייצא את הנתונים לשימוש בכלים משלכם.
(ב-Android וב-iOS בלבד) כדאי להפעיל את העזרה מ-AI ב-Crashlytics כדי להבין מהר יותר למה קרסה האפליקציה ומה צריך לעשות.
מעלים את קובץ ה-dSYM לגרסאות של build לפרסום לשימוש ב-Crashlytics. מוודאים ש-Xcode יכול לעבד באופן אוטומטי קובצי dSYM ולהעלות את הקבצים.
העלאה של מיפוי ProGuard לגרסאות הפקה לשימוש ב-Crashlytics. אפשר להעלות באמצעות Firebase CLI.
קישור Firebase אל Google Play כדי לקבל תמונה מפורטת יותר של תקינות אפליקציית Android. לדוגמה, אפשר לסנן את דוחות הקריסה של האפליקציה לפי Google Play track, כדי להתמקד בגרסאות ספציפיות של האפליקציה בלוח הבקרה.
בגרסאות שמיועדות ל-Android ומשתמשות ב-IL2CPP, חשוב לוודא שאתם מעלים סמלים מקוריים לכל הרצה של בניית גרסה שאתם רוצים שיהיו לה סמלים, בלי קשר לשאלה אם בוצעו שינויים בקוד או בהגדרות.
Dynamic Links
- Dynamic Links הוצא משימוש, ולכן מומלץ להפסיק להשתמש בשירות. מידע נוסף זמין בשאלות הנפוצות בנושא הוצאה משימוש.
Firebase ML
תוכלו להיעזר במאמר בנושא הכנת אפליקציית Firebase ML Apple לסביבת הייצור.
אפשר לעיין במאמר בנושא הכנת Firebase ML אפליקציית Android לסביבת הייצור.
Performance Monitoring
חשוב לוודא שכל חבר צוות בפרויקט (שנקרא גם "בעל עניין") מגדיר את ההעדפות שלו לקבלת התראות לגבי Performance Monitoring או מצב הפרויקט (כמו שינויים בתוכנית החיוב או במגבלות המכסה). מידע נוסף זמין במאמר בנושא קבלת התרעות מ-Firebase.
מומלץ להפעיל ייצוא של נתוני Performance Monitoring אל BigQuery כדי שתוכלו לנתח את הנתונים באמצעות SQL של BigQuery או לייצא את הנתונים לשימוש בכלים משלכם.
Realtime Database
מגדירים את Realtime Database Security Rules כדי למנוע גישה לא מכוונת לנתונים.
מוודאים שאתם מוכנים להרחבה. ל-Realtime Database יש מכסת ברירת מחדל גדולה מספיק לרוב האפליקציות, אבל יכול להיות שאפליקציות מסוימות יזדקקו לקיבולת נוספת.
מגדירים את כללי proguard כדי לעבוד עם Realtime Database.
Remote Config
מוודאים שכללים ניסיוניים Remote Config לא משפיעים על המשתמשים בגרסת ההפצה, ושהגדרות ברירת המחדל המתאימות של השרת ושל האפליקציה מופצות באפליקציה.
כדאי להגדיר פרמטר
minimum_versionב-Remote Config כדי שתוכלו להציג למשתמשים בקשות או דרישות לעדכן את האפליקציה אם גרסאות קודמות לא תואמות או אם הן הוצאו משימוש.