אחד הפחדים הגדולים ביותר של כל מפתח הוא לפתח פיצ’ר חדש ואז, למרות הצער, להחזיר אותו מיד לאחר מכן למצב הקודם מאחר והוא גרם למשהו בקוד להישבר.
גם כשאתה כותב מבחנים מצוינים ומוודא הכל מקומית, לפעמים זה פשוט לא מספיק, ובשילוב – משהו נשבר (וגם, הלב הרגיש שלך).
במאמר זה אציג כיצד פתרנו את הכאב הזה כאן ב-Soluto על ידי שימוש בסביבות בדיקה E2E.
מהי סביבת בדיקות E2E?
תאר לעצמך שאתה יכול לארוז את כל 100+ שירותי המיקרו שלך בחבילה אחת, כולל backend, frontend, DB, תורים ותשתית ענן, ולאחר מכן לפרוס את הכל יחד עם הקוד של התכונה החדשה שלך בסביבה נקייה. זה נקרא סביבת בדיקות E2E. אתה יכול להשתמש בסביבה הזו כדי לחקות ייצור, ובמקביל, להרגיש חופשי להרוס אותה. מבחני אינטגרציה אוטומטיים יפעלו על הסביבה, ותוכלו גם לאמת באופן ידני ששום דבר לא נשבר בתמונה הגדולה יותר.
נשמע נפלא נכון? מעולה, מכאן עולה השאלה- איך אני יכול ליישם דבר כזה?
ישנן מספר דרכים ליישם סביבות בדיקות E2E (כמו בכל מושגי פיתוח התוכנה). בפסקאות הבאות, אני הולך להסביר כיצד יישמנו את זה כאן ב- Soluto:
Which practice did we choose and why?
How to deploy Kubernetes clusters and AWS tools in one machine?
Configuring and deploying an environment
באיזה פרקטיקה בחרנו ולמה?
כשחשבנו על איך לפרוס את סביבת הבדיקה שלנו, המחשבה הראשונה הייתה, “למה לא להשתמש באותו תהליך פריסה כמו שאנחנו משתמשים לייצור היום?”, אבל מהר מאוד הבנו שזה לא בסדר מבחינתנו. פריסת מאות שירותי מיקרו, למבדות, DBs, תורים וכו’, אורכת זמן רב מאוד ועולה הרבה. קשה גם לנהל תשתית כזו עבור כל סביבת בדיקה.
אז החלטנו לנסות לבסס את כל המערכת האקולוגית על מכונת EC2 אחת. חיפשנו כלי שיאפשר לנו לפרוס ולנהל את המערכת האקולוגית שלנו תחת מכונה אחת ומצאנו את Tilt. Tilt מאפשר להגדיר את תהליך הפריסה בקוד ועובד עם תמונות docker קיימות. עם Tilt, קל לנהל מספר סביבות, לפרוס במהירות ולהשתמש באותה שפה עבור כל תהליכי הפריסה.
Tilt מספקת גם ממשק משתמש ידידותי שעוזר לראות את המצב של כל רכיב בסביבה, לקרוא יומנים ולהפעיל מחדש חלק אחד מבלי להפעיל מחדש את כל השירותים בסביבה.
כיצד לפרוס אשכולות Kubernetes וכלי AWS במכונה אחת?
בייצור, אנו פורסים את שירותי המיקרו שלנו באמצעות Kubernetes, ולכלי תשתית אחרים כגון תורים, למבדות, DBs ועוד, אנו משתמשים ב-AWS.
E2E אילוסטרציה לסביבת בדיקות (נוצר בעזרת io.Draw) קרדיט: Soluto
אנחנו צריכים למצוא חלופות לכלים אלה כאשר אנו פועלים על מכונה אחת.
להפעלת אשכולות Kubernetes שלנו על מכונה אחת, בחרנו להשתמש ב-Kind. Kind הוא כלי להפעלת אשכולות Kubernetes מקומיים באמצעות צמתי קונטיינר של Docker, והוא פשוט לשימוש.
אנחנו עדיין צריכים למצוא כלי לפריסת תשתית ה-AWS שלנו על מחשב אחד. לשם כך, בחרנו להשתמש ב-Localstack. Localstack הוא אמולטור שירותי ענן הפועל בקונטיינר בודד במכונה אחת. Localstack אינו זהה לכלי ייצור של AWS, אך מכיוון שאנו בודקים את הקוד שלנו ולא את תשתית AWS, אנו מרגישים בנוח להשתמש בכלי תשתית מדומה עבור AWS.
הגדרה ופריסה של סביבה
הגדרנו קבצי YAML שמתארים את סביבות הבדיקה של E2E, כך שכל קובץ YAML מתאר סביבה אחת באופן הבא:
- version: Used to determine which version of the environment to deploy.
- description: Describes what the environment is going to test.
- projects: A list of all the projects on Github that we want to run and from which branch.
- flags: Flags that are injected as environment variables on each run.
- deployment: Contains some parameters about the deployment flow.
לאחר דחיפה של שינויים לקובץ YAML, פעולת Github תבצע את תהליך פריסת הסביבה. תחילה, סקריפט AWS CDK מקים מופע AWS EC2 חדש. בהגדרת המופע של EC2, נמשוך מ-Github את כל הפרויקטים שהגדרנו בקובץ YAML. לאחר מכן, סקריפטי ההטיה שיצרנו יפרוס את השירותים באמצעות תמונות ה-Docker שלהם. Kind יריץ את אשכולות Kubernetes, ו-Localstack תפרוס את תשתית ה-AWS.
השוואה בין AWS לבין Tilt) נוצר בעזרת Slides Google)
קרדיט: Soluto
השוואה בין AWS לבין Tilt) נוצר בעזרת Slides Google)
קרדיט: Soluto
תרשים זרימה של פריסת Aws וגם Kubernetes (io.Draw נוצר בעזרת)
קרדיט: Soluto
לוגו של Kind (Github)
קרדיט: Soluto
לוגו של Localstack( Github )
קרדיט: Soluto
דוגמה לקובץ YAML (צילום מסך)
קרדיט: Soluto
תרשים זרימה של פריסת סביבה חדשה ) נוצר בעזרת io.Draw)
קרדיט: Soluto
הפעלת בדיקות E2E אוטומטיות
כל השירותים שלנו פועלים, ועכשיו הגיע הזמן להפעיל כמה בדיקות.
השלב הראשון הוא לוודא שכל השירותים הנדרשים עבור כל זרימת בדיקה קיימים ופועלים בסביבה הספציפית (אין חובה להגדיר את כל השירותים בכל e2e testing env). אנחנו יכולים לעשות את זה באמצעות תצורת הטיה:
k8s_deploy(‘lambda-save-to-mongo-db-test’, ‘3000:3000’, resource_deps=[‘mongodb’, ‘create-aws-resources’])
הבדיקה שלמעלה תפעל רק לאחר ביצוע שלבי `mongodb` ו`create-aws-resources`, וימנע כשלים כגון DB או lambda בלתי ניתן להשגה.
שי טובול, Software Senior Engineer at Soluto (Asurion)
קרדיט: שי טובול
בדיקות אלו פועלות באופן אוטומטי בכל הגדרת סביבת בדיקה של e2e ומבטיחות שכולן פועלות יחד כמצופה.
לסיכום, יצירת סביבות בדיקה של e2e עוזרת לבחון תכונות הכוללות מספר שירותים ומאפשרת לנו להיות חסויים עם הקוד שלנו לפני פריסתו.
חיוני לפתח תשתית שתקל על המשתמשים ליצור סביבה (אם לא, כנראה שאף אחד לא ישתמש בכלי שלך). כחלק מסביבת הבדיקות שלך e2e, נסו לכלול ממשק משתמש שישקף את הסטטוס של כל שירות בסביבה, כך שיהיה קל לזהות ולפתור בעיות. השתמשו בדוגמניות עבור חלקים בארכיטקטורה שאינם נחוצים כדי להיבדק על ידכם (תשתית AWS, DB וכו’). בצע כמה בדיקות e2e אוטומטיות שיוודאו שהזרימות הראשיות פועלות כהלכה, וזה יעזור למנוע כמה באגים קטלניים.
