כדי לתמוך בלוח מחוונים של אינטגרציה מתמשכת שניתן להרחבה, ביצועים וגמישים, הקצה האחורי של לוח המחוונים של VTS חייב להיות מתוכנן בקפידה עם הבנה חזקה של פונקציונליות מסד הנתונים. Google Cloud Datastore הוא מסד נתונים NoSQL שמציע ערבויות ACID עסקאות ועקביות בסופו של דבר, כמו גם עקביות חזקה בתוך קבוצות ישויות. עם זאת, המבנה שונה מאוד ממסדי נתונים של SQL (ואפילו Cloud Bigtable); במקום טבלאות, שורות ותאים יש סוגים, ישויות ומאפיינים.
הסעיפים הבאים מתארים את מבנה הנתונים ודפוסי השאילתה ליצירת קצה אחורי יעיל עבור שירות האינטרנט של VTS Dashboard.
ישויות
הישויות הבאות מאחסנות סיכומים ומשאבים מהרצות בדיקה של VTS:
- ישות בדיקה . מאחסן מטא נתונים על ריצות בדיקה של בדיקה מסוימת. המפתח שלו הוא שם הבדיקה והמאפיינים שלו כוללים את ספירת הכשלים, ספירת העוברים ורשימת שברי מקרי הבדיקה מרגע שעבודות ההתראה מעדכנות אותה.
- ישות הפעלת מבחן . מכיל מטא נתונים מהרצות של בדיקה מסוימת. עליו לאחסן את חותמות הזמן של ההתחלה והסיום של הבדיקה, מזהה בניית הבדיקה, מספר מקרי הבדיקה שעברו ונכשלים, סוג הריצה (למשל שליחה מוקדמת, לאחר הגשה או מקומית), רשימה של קישורי יומן, המארח שם המכונה וספירת סיכום הכיסוי.
- ישות מידע על מכשיר . מכיל פרטים על המכשירים שבהם נעשה שימוש במהלך ריצת הבדיקה. הוא כולל את מזהה בניית המכשיר, שם המוצר, יעד הבנייה, הענף ומידע ABI. זה מאוחסן בנפרד מיישות ריצת הבדיקה כדי לתמוך בריצות בדיקה מרובות מכשירים באופן של אחד לרבים.
- ישות הפעלת נקודת פרופיל . מסכם את הנתונים שנאספו עבור נקודת פרופיל מסוימת בתוך ריצת בדיקה. הוא מתאר את תוויות הציר, שם נקודת הפרופיל, הערכים, הסוג ומצב הרגרסיה של נתוני הפרופיל.
- ישות כיסוי . מתאר את נתוני הכיסוי שנאספו עבור קובץ אחד. הוא מכיל את המידע על פרויקט Git, נתיב הקובץ ורשימת ספירות הכיסוי לכל שורה בקובץ המקור.
- ישות הפעלת מקרה מבחן . מתאר את התוצאה של מקרה בדיקה מסוים מהפעלת בדיקה, כולל שם מקרה הבדיקה והתוצאה שלו.
- ישות מועדפי משתמש . כל מנוי משתמש יכול להיות מיוצג בישות המכילה הפניה לבדיקה ומזהה המשתמש שנוצר משירות המשתמש של App Engine. זה מאפשר שאילתה דו-כיוונית יעילה (כלומר לכל המשתמשים הרשומים לבדיקה ולכל הבדיקות המועדפות על ידי משתמש).
קיבוץ ישויות
כל מודול בדיקה מייצג את השורש של קבוצת ישות. ישויות של הפעלת מבחן הן ילדים של קבוצה זו והן הורים עבור ישויות מכשיר, ישויות של נקודות פרופיל, וישויות כיסוי הרלוונטיות לאב הקדמון של הבדיקה והרצת המבחן.
נקודת מפתח: בעת עיצוב קשרי אבות, עליך לאזן בין הצורך לספק מנגנוני שאילתה יעילים ועקביים מול המגבלות שנאכפות על ידי מסד הנתונים.
יתרונות
דרישת העקביות מבטיחה שפעולות עתידיות לא יראו את ההשפעות של עסקה עד שהיא תתחייב, ושעסקאות בעבר יהיו גלויות לפעולות הנוכחיות. ב-Cloud Datastore, קיבוץ ישויות יוצר איים של עקביות קריאה וכתיבה חזקה בתוך הקבוצה, שבמקרה זה היא כל ריצות בדיקה ונתונים הקשורים למודול בדיקה. זה מציע את היתרונות הבאים:
- ניתן להתייחס לקריאה ועדכונים לבדיקת מצב מודול לפי משרות התראה כאטומיות
- מבט עקבי מובטח של תוצאות מקרי הבדיקה בתוך מודולי הבדיקה
- שאילתה מהירה יותר בתוך עצי מוצא
מגבלות
כתיבה לקבוצת ישות בקצב מהיר יותר מישות אחת לשנייה אינה מומלצת מכיוון שחלק מהכתובות עשויות להידחות. כל עוד עבודות ההתראה וההעלאה לא מתרחשות בקצב מהיר יותר מכתיבה אחת בשנייה, המבנה יציב ומבטיח עקביות חזקה.
בסופו של דבר, המכסה של כתיבה אחת לכל מודול בדיקה לשנייה היא סבירה מכיוון שהרצות בדיקה נמשכות בדרך כלל לפחות דקה אחת כולל התקורה של מסגרת VTS; אלא אם כן בדיקה מבוצעת באופן עקבי בו-זמנית על יותר מ-60 מארחים שונים, לא יכול להיות צוואר בקבוק בכתיבה. זה הופך להיות אפילו יותר בלתי סביר בהתחשב בכך שכל מודול הוא חלק מתוכנית בדיקה שלעיתים נמשכת יותר משעה אחת. ניתן לטפל בחריגות בקלות אם מארחים מריצים את הבדיקות בו-זמנית, מה שגורם להתפרצויות קצרות של כתיבה לאותם מארחים (למשל על ידי תפיסת שגיאות כתיבה וניסיון שוב).
שיקולי קנה מידה
הפעלת בדיקה לא חייבת בהכרח שהבדיקה תהיה האב שלה (למשל היא יכולה לקחת מפתח אחר ויש לה שם בדיקה, זמן תחילת הבדיקה כמאפיינים); עם זאת, זה יחליף עקביות חזקה לעקביות בסופו של דבר. לדוגמה, ייתכן שעבודת ההתראה לא תראה תמונת מצב עקבית הדדית של ריצות הבדיקה האחרונות בתוך מודול בדיקה, מה שאומר שהמצב הגלובלי עשוי שלא להציג ייצוג מדויק לחלוטין של רצף ריצות הבדיקה. זה עשוי להשפיע גם על הצגת ריצות הבדיקה בתוך מודול בדיקה בודד, אשר עשויה להיות לא בהכרח תמונת מצב עקבית של רצף הריצה. בסופו של דבר תמונת המצב תהיה עקבית, אך אין ערובה שהנתונים העדכניים ביותר יהיו.
מקרי מבחן
צוואר בקבוק פוטנציאלי נוסף הוא בדיקות גדולות עם מקרי בדיקה רבים. שני האילוצים התפעוליים הם תפוקת הכתיבה המקסימלית בתוך קבוצת ישויות של אחד לשנייה, יחד עם גודל עסקה מקסימלי של 500 ישויות.
גישה אחת תהיה לציין מקרה בדיקה עם הפעלת בדיקה כאב קדמון (בדומה לאופן שבו מאוחסנים נתוני כיסוי, נתוני פרופיל ומידע על המכשיר):
בעוד שגישה זו מציעה אטומיות ועקביות, היא מטילה מגבלות חזקות על בדיקות: אם עסקה מוגבלת ל-500 ישויות, אזי לבדיקה יכולים להיות לא יותר מ-498 מקרי בדיקה (בהנחה שאין כיסוי או נתוני פרופיל). אם בדיקה הייתה חורגת מזה, אז עסקאות בודדות לא יוכלו לכתוב את כל תוצאות מקרה הבדיקה בבת אחת, וחלוקת מקרי הבדיקה לטרנזקציות נפרדות עלולה לחרוג מתפוקת הכתיבה המקסימלית של קבוצת ישויות של איטרציה אחת לשנייה. מכיוון שפתרון זה לא יתקל בקנה מידה טוב מבלי להקריב את הביצועים, הוא לא מומלץ.
עם זאת, במקום לאחסן את תוצאות מקרי הבדיקה בתור ילדים של ריצת הבדיקה, ניתן לאחסן את מקרי הבדיקה באופן עצמאי ולספק את המפתחות שלהם לריצת הבדיקה (ריצת בדיקה מכילה רשימה של מזהים לישויות מקרי הבדיקה שלה):
במבט ראשון, זה עשוי להיראות כדי לשבור את ערבות העקביות החזקה. עם זאת, אם ללקוח יש ישות של הפעלת בדיקה ורשימת מזהי מקרי בדיקה, הוא אינו צריך לבנות שאילתה; הוא יכול במקום זאת לקבל ישירות את מקרי הבדיקה לפי המזהים שלהם, מה שמובטח תמיד להיות עקבי. גישה זו מקלה במידה ניכרת על המגבלה על מספר מקרי הבדיקה שעשויים להיות לריצת בדיקה תוך השגת עקביות חזקה מבלי לאיים על כתיבה מוגזמת בתוך קבוצת ישות.
דפוסי גישה לנתונים
לוח המחוונים של VTS משתמש בדפוסי הגישה הבאים לנתונים:
- מועדפי משתמשים . ניתן לשאול על ידי שימוש במסנן שוויון בישויות המועדפות על המשתמשים עם אובייקט App Engine User המסוים כמאפיין.
- רישום בדיקה . שאילתה פשוטה של ישויות בדיקה. כדי להקטין את רוחב הפס לעיבוד דף הבית, ניתן להשתמש בהקרנה על ספירות עוברות ונכשלות כדי להשמיט את הרשימה הארוכה של זיהויי מקרי בדיקה נכשלים ומטא נתונים אחרים המשמשים את עבודות ההתראה.
- ריצות מבחן . שאילתה עבור ישויות של ריצת מבחן דורשת מיון על המפתח (חותמת זמן) וסינון אפשרי על מאפייני הריצת המבחן כגון מזהה build, ספירה עוברת וכו'. על ידי ביצוע שאילתת קדמון עם מפתח ישות בדיקה, הקריאה עקבית מאוד. בשלב זה, ניתן לאחזר את כל תוצאות מקרי הבדיקה באמצעות רשימת המזהים המאוחסנים במאפיין של ריצת בדיקה; זו גם מובטחת שתהיה תוצאה עקבית מאוד על פי אופי פעולות הקבל של חנות הנתונים.
- נתוני פרופיל וכיסוי . שאילתה עבור נתוני פרופיל או כיסוי הקשורים לבדיקה יכולה להתבצע מבלי לאחזר גם נתוני ריצת בדיקה אחרים (כגון נתוני פרופיל/כיסוי אחרים, נתוני מקרה מבחן וכו'). שאילתת קדמון המשתמשת במפתחות הישות של בדיקת הבדיקה והפעלת המבחן תחזיר את כל נקודות הפרופיל שנרשמו במהלך הפעלת הבדיקה; על ידי סינון גם על שם נקודת הפרופיל או שם הקובץ, ניתן לאחזר ישות אחת לפרופיל או כיסוי. מטבען של שאילתות אבות, פעולה זו עקבית מאוד.
לפרטים על ממשק המשתמש וצילומי מסך של דפוסי נתונים אלה בפעולה, ראה ממשק המשתמש של לוח המחוונים של VTS .