במסמך הזה מופיעה רשימת שיטות מומלצות ושיקולים שכדאי לקחת בחשבון לפני שמשיקים אפליקציית Firebase בייצור.
שיטות מומלצות כלליות להפצה
חשוב לוודא שבדקתם את כל השינויים בFirebase Local Emulator Suite (למוצרים נתמכים) לפני הפריסה בסביבת הייצור. בדיקות יסודיות יכולות לעזור לכם להימנע מטעויות יקרות.
מתחילים לאכוף Firebase App Check לכל שירות שתומך בכך. App Check עוזר לוודא שרק האפליקציות שלכם יכולות לגשת לשירותים ולמשאבים של ה-Backend.
כדאי לעיין ברשימת המשימות הכללית של Firebase בנושא אבטחה.
כדאי להשתמש בהשקות של Firebase Remote Config כדי להשיק תכונות חדשות ועדכונים לאפליקציה בצורה בטוחה והדרגתית.
אם עדיין לא עשיתם את זה, כדאי להגדיר את Firebase Crashlytics. זהו כלי קל משקל לדיווח על קריסות בזמן אמת, שעוזר לעקוב אחרי בעיות יציבות שפוגעות באיכות האפליקציה, לתת להן עדיפות ולתקן אותן.
הכרת המגבלות של תוכנית התמחור והגדרת התראות לגבי תקציב
חשוב לוודא שלא תגיעו למגבלות השימוש ולמכסות אחרי שתעברו לשלב הייצור, במיוחד אם אתם משתמשים בתוכנית Spark ללא עלות. מומלץ לשדרג לתוכנית התמחור Blaze בתשלום לפי שימוש.
הגדרת התראות לגבי תקציב לפרויקט.
חשוב לציין שהתראות על תקציב לא מגבילות את התקציב, אלא רק שולחות התראות. התראה תשלח לכם הודעות כשאתם מתקרבים לסף שהגדרתם או חורגים ממנו, כדי שתוכלו לפעול באפליקציה או בפרויקט.
מומלץ להגדיר התראות ופעולות מתקדמות, כמו פונקציות שישביתו את החיוב בתגובה להתראות.
אם אתם משתמשים ב-Firebase AI Logic, ב-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.
אפשר גם להתאים אישית את רשימת אנשי הקשר החיוניים בפרויקט אם רוצים שחברים ספציפיים או נוספים בפרויקט יקבלו התראות. האפשרות הזו שימושית במיוחד כדי לוודא שגם אנשים אחרים מלבד בעלי הפרויקט יקבלו התראות על שינויים בחיוב, במוצרים ובעניינים משפטיים.
מגבילים את מפתחות ה-API של Firebase רק לממשקי ה-API שצריכים להיות ברשימת ההיתרים של מפתח ה-API. כדאי גם לעיין במידע על מפתחות API ברשימת המשימות לאבטחה של Firebase.
הכנת שירותים ספציפיים שנעשה בהם שימוש באפליקציה
יכול להיות שלכל מוצר ושירות שבהם נעשה שימוש באפליקציה יש שיקולים ספציפיים כשמשתמשים בהם בסביבת הייצור.
Firebase AI Logic
- מידע נוסף מופיע ברשימת המשימות ליצירת קמפיין באמצעות Firebase AI Logic.
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 עוזר לוודא שרק האפליקציות שלכם יכולות לגשת לשירותים ולמשאבים של ה-Backend.
Authentication
משביתים את כל הספקים שלא משתמשים בהם (במיוחד אימות אנונימי).
אם האפליקציה שלכם משתמשת בכניסה באמצעות חשבון Google, כדאי להתאים אישית את מסך ההסכמה ל-OAuth.
התאמה אישית של הדומיין והשולח בAuthentication שירות שליחת האימיילים.
אם אתם משתמשים בשירותי אימות ב-SMS של Identity Platform, כדאי להתחיל לאכוף Firebase App Check ולהגדיר מדיניות אזורית ל-SMS כדי להגן על האפליקציה מפני שימוש לרעה ב-SMS.
הטמעת טיפול בשגיאות בפלטפורמות של אפל עבור שגיאות Authentication נפוצות.
מוסיפים את הגיבוב SHA-1 של גרסת ההפצה של אישור החתימה של האפליקציה בהגדרות הפרויקט במסוף 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 באפליקציות של אפל במסוף 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 לגרסאות הפקה לשימוש ב-Crashlytics. אפשר להעלות באמצעות Firebase CLI.
מקשרים את Firebase אל Google Play כדי לקבל תמונה מפורטת יותר של תקינות האפליקציה ל-Android. לדוגמה, אפשר לסנן את דוחות הקריסות של האפליקציה לפי Google Play track, כדי להתמקד בגרסאות ספציפיות של האפליקציה בלוח הבקרה.
בגרסאות שמיועדות ל-Android ומשתמשות ב-IL2CPP, חשוב לוודא שאתם מעלים סמלים מקוריים לכל הרצה של בנייה שאתם רוצים שיהיו לה סמלים, בלי קשר לשאלה אם בוצעו שינויים בקוד או בהגדרות.
Dynamic Links
- Dynamic Links יצא משימוש, ולכן מומלץ להעביר את הנתונים מהשירות. מידע נוסף זמין בתשובות לשאלות הנפוצות בנושא הוצאה משימוש.
Firebase ML
אפשר לעיין במאמר בנושא הכנת אפליקציית Firebase ML Apple לסביבת הייצור.
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 לא משפיעים על המשתמשים בגרסת ההפצה, ושהגדרות ברירת המחדל המתאימות של השרת ושל האפליקציה מופצות באפליקציה.