במסמך הזה מופיעה רשימת משימות עם שיטות מומלצות ושיקולים שחשוב להביא בחשבון לפני השקת אפליקציה של 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.
אם אתם רוצים שאנשים ספציפיים או אנשים נוספים בפרויקט יקבלו התראות, תוכלו גם להתאים אישית את 'אנשי הקשר החיוניים' בפרויקט. האפשרות הזו שימושית במיוחד כדי לוודא שגם משתמשים אחרים מקבלים התראות על שינויים בחיוב, בנושאים משפטיים ובמוצרים.
מגבילים את מפתחות ה-API של Firebase רק לממשקי ה-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. אפשר להעלות באמצעות Firebase CLI.
מקשרים את Firebase ל-Google Play כדי לקבל תמונה עשירה יותר של סטטוס האפליקציה ל-Android. לדוגמה, תוכלו לסנן את דוחות הקריסות של האפליקציה לפי מעקב Google Play, כדי להתמקד טוב יותר בלוח הבקרה בגרסאות build ספציפיות.
לגבי גרסאות build שמטרגטות Android ומשתמשות ב-IL2CPP, חשוב לוודא שאתם מעלים סמלים מקומיים לכל הפעלה ספציפית של build שאתם רוצים לקבל עבורה סמלים, גם אם לא היו שינויים בקוד או בהגדרות.
Dynamic Links
- Dynamic Links הוצא משימוש, לכן מומלץ להפסיק להשתמש בשירות. מידע נוסף זמין בתשובות לשאלות הנפוצות בנושא הוצאה משימוש.
Firebase ML
למידע נוסף, ראו הכנת אפליקציית Firebase ML ל-Apple לסביבת הייצור.
למידע נוסף, ראו הכנת אפליקציית Android של Firebase ML לסביבת הייצור.
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 לא משפיעים על המשתמשים בגרסה היציבה, ושערכים ברירת המחדל המתאימים לשרת ולאפליקציה מופצים באפליקציה.