רשימת משימות להשקה ב-Firebase

במסמך הזה מופיעה רשימת שיטות מומלצות ושיקולים שכדאי לקחת בחשבון לפני השקת אפליקציית Firebase בסביבת הייצור.

שיטות מומלצות כלליות לפרסום

  • חשוב לוודא שבדקתם את כל השינויים בFirebase Local Emulator Suite (למוצרים נתמכים) לפני הפריסה בסביבת הייצור. בדיקות יסודיות יכולות לעזור לכם להימנע מטעויות יקרות.

  • מתחילים לאכוף Firebase App Check לכל שירות שתומך בכך. ‫App Check עוזר לוודא שרק האפליקציות שלכם יכולות לגשת לשירותים ולמשאבים של ה-Backend.

  • כדאי לעיין ברשימת המשימות הכללית של Firebase בנושא אבטחה.

  • אפשר להשתמש בFirebase Remote Config השקות כדי להשיק תכונות חדשות ועדכונים לאפליקציה בצורה בטוחה והדרגתית.

  • אם עדיין לא עשיתם את זה, כדאי להגדיר את Firebase Crashlytics. זהו כלי קל משקל לדיווח על קריסות בזמן אמת, שעוזר לכם לעקוב אחרי בעיות יציבות שפוגעות באיכות האפליקציה, לתת להן עדיפות ולתקן אותן.

הכרת המגבלות של תוכנית התמחור והגדרת התראות לגבי תקציב

  • חשוב לוודא שלא חורגים ממגבלות השימוש והמכסות אחרי המעבר לייצור, במיוחד אם אתם משתמשים בתוכנית Spark ללא עלות. מומלץ לשדרג לתוכנית התמחור Blaze בתשלום לפי שימוש.

  • הגדרת התראות לגבי תקציב לפרויקט.

    • חשוב לציין שהתראות על תקציב לא מגבילות את התקציב, אלא רק שולחות התראות. התראה תשלח לכם הודעות כשאתם מתקרבים לסף שהגדרתם או חורגים ממנו, כדי שתוכלו לפעול באפליקציה או בפרויקט.

    • מומלץ להגדיר התראות ופעולות מתקדמות, כמו פונקציות שישביתו את החיוב בתגובה להתראות.

  • אפשר לעקוב אחרי השימוש בלוחות הבקרה הספציפיים למוצר או בלוח הבקרה המרכזי שימוש וחיוב במסוף Firebase.

חשוב לוודא שהפרויקטים והאפליקציות שלכם ב-Firebase פועלים בהתאם לשיטות המומלצות

בין אם אתם מפתחים יחידים או צוותים גדולים, חשוב לוודא שהפרויקטים, האפליקציות והמשאבים שלכם ב-Firebase מוגנים ומאובטחים, ושהם יכולים להתפתח בהתאם לשינויים בצוות.

חשוב לזכור שפרויקט Firebase הוא בעצם Google Cloudפרויקט שמופעלים בו שירותים והגדרות של Firebase. המשמעות היא שרבות מהשיטות המומלצות של Google Cloud רלוונטיות גם ל-Firebase.

  • משתמשים בפרויקטים שונים ב-Firebase לפיתוח, לבדיקה ולייצור.

    כדאי לנסות לצמצם את החשיפה הלא צפויה לפרויקט שמשויך לאפליקציה שלכם בסביבת הייצור. מידע נוסף על הגדרת תהליכי עבודה לפיתוח

  • חשוב להגן על הפרויקטים החשובים, ובמיוחד על הפרויקט שמשויך לאפליקציה שלכם בייצור.

  • אם עדיין לא עשיתם זאת, כדאי להגדיר Google Cloud ארגון ולהוסיף אליו את הפרויקטים שלכם ב-Firebase.

  • מומלץ להוסיף יותר מבעלים אחד לפרויקטים ב-Firebase, במיוחד אם הפרויקט לא נמצא בארגון Google Cloud. מידע נוסף על הקצאת בעלים לפרויקט ב-Firebase

  • מוסיפים חברים לפרויקט (שנקראים גם "עקרונות") כקבוצות Google במקום להוסיף אותם בנפרד.

    השימוש בקבוצות מקל על הקצאת תפקידים לחברי הצוות בכמות גדולה, וגם על ניהול הגישה לפרויקט Firebase, במיוחד אם חברי הצוות מתחלפים או עוזבים.

  • מעניקים לכל חבר בפרויקט (שנקרא גם "גורם") את רמת הגישה המתאימה לפרויקטים ולמשאבים שלכם ב-Firebase. מידע נוסף זמין במאמר ניהול הגישה לפרויקט באמצעות Firebase IAM.

  • חשוב לוודא שכל חברי הפרויקט הרלוונטיים (שנקראים גם 'גורמים') מגדירים את ההעדפות שלהם לקבלת התראות לגבי מוצרים ספציפיים או מצב הפרויקט (למשל שינויים בתוכנית החיוב או במגבלות המכסה). מידע נוסף זמין במאמר בנושא קבלת התרעות מ-Firebase.

    אפשר גם להתאים אישית את רשימת אנשי הקשר החיוניים בפרויקט אם רוצים שחברים ספציפיים או נוספים בפרויקט יקבלו התראות. האפשרות הזו שימושית במיוחד כדי לוודא שיותר מאשר רק בעלי הפרויקט יקבלו התראות על שינויים בחיוב, בפרטים משפטיים ובמוצרים.

  • מגבילים את מפתחות ה-API של Firebase רק לממשקי ה-API שצריכים להיות ברשימת ההיתרים של מפתח ה-API. כדאי גם לעיין במידע על מפתחות API ברשימת המשימות לאבטחה של Firebase.

הכנת שירותים ספציפיים שנעשה בהם שימוש באפליקציה

יכול להיות שלכל מוצר ושירות שמשמשים באפליקציה שלכם יש שיקולים ספציפיים כשמשתמשים בהם בסביבת הייצור.

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, ‏ Cloud Firestore SDK והתלויות שלו יכולים להגדיל את הגודל של חבילת ה-APK.

Cloud Messaging

  • מומלץ להפעיל ייצוא של נתוני Cloud Messaging אל BigQuery כדי שתוכלו לנתח את הנתונים באמצעות BigQuery SQL או לייצא את הנתונים כדי להשתמש בהם בכלים משלכם.

  • מעלים את מפתח האימות של APNS עבור Cloud Messaging באפליקציות של אפל במסוף Firebase. אם משתמשים באישור APNS, צריך לוודא שאישור ה-APNS של סביבת הייצור הועלה.

Cloud Storage

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, כדי להתמקד בגרסאות ספציפיות של האפליקציה בלוח הבקרה.

  • בגרסאות build שמיועדות ל-Android ומשתמשות ב-IL2CPP, חשוב לוודא שאתם מעלים סמלים מקוריים לכל הרצה של build שאתם רוצים שיהיו לה סמלים, בלי קשר לשאלה אם בוצעו שינויים בקוד או בהגדרות.

Firebase ML

Performance Monitoring

  • מוודאים שכל חבר צוות בפרויקט (שנקרא גם "גורם") מגדיר את ההעדפות שלו לקבלת התראות לגבי Performance Monitoring או מצב הפרויקט (כמו שינויים בתוכנית החיוב או במגבלות המכסה). מידע נוסף זמין במאמר בנושא קבלת התרעות מ-Firebase.

  • מומלץ להפעיל ייצוא של נתוני Performance Monitoring אל BigQuery כדי שתוכלו לנתח את הנתונים באמצעות BigQuery SQL או לייצא את הנתונים כדי להשתמש בהם בכלים משלכם.

Realtime Database

Remote Config

  • חשוב לוודא שכללים ניסיונייםRemote Config לא משפיעים על המשתמשים בגרסת ההפצה, ושהגדרות ברירת המחדל המתאימות של השרת ושל האפליקציה מופצות באפליקציה.