תיאור כללי
מערכת CI/CD (או Continuous Integration/Continuous Deployment) היא מערכת שמבצעת פעולות כשעושים push לקוד חדש אל תוך הפרויקט שלנו.
מה ההצעה כוללת?
- הרצת הבדיקות לכל קוד שנכנס, כדי לבדוק שהבדיקות לא שוברות את הפרויקט.
- הרצה אוטומטית של flake8, כדי לוודא שכל הקוד שנכנס לפרויקט תואם ל־PEP 8 ונראה טוב.
- פרסום סטטיסטיקות coverage ב־PR כתגובה באופן אוטומטי – כדי לוודא שה־coverage לא ירד בעקבות ה־PR.
- אם הקוד עובר merge לענף main – העלאה של הקוד לשרתים שלנו, כדי שנוכל לראות את השינויים שהתרחשו.
כולל שינויים בקוד? אם כן, איפה?
לא ישירות בקוד הפרויקט, אבל כן בקוד שמעליו.
אני הולך להשתמש בטכנולוגיה שנקראת GitHub Actions שמתועדת פה.
השימוש ב־GitHub Actions לצורך CI/CD מתועד פה.
לצורך פרסום סטטיסטיקות ה־Coverage, אני הולך להשתמש ב־Codecov, כיוון שיש לי ניסיון חיובי באינטגרציה שלהם ל־GitHub ב־LMS.
לצורך העלאת הקוד המוכן לשרת, אני הולך להקים לנו שרת ב־Google Cloud, להקצות Static IP למכונה ולנתב את הכתובת calendar.pythonic.guru בעזרת A Record בשירות Route 53 של AWS, שם רשום כרגע הדומיין Pythonic.guru.
האם יהיו שינויים במסד הנתונים? אם כן, איפה?
לא, השינוי הזה לא תלוי במסד הנתונים ולא יגרור בו שינוי.
האם יהיה שינוי ב־frontend? אם כן, איפה?
לא, השינוי הזה לא תלוי ב־frontend ולא יגרור בו שינוי.
אילו טסטים יגרמו לטיקט להיחשב כ"עובד", ויאפשרו לנו לסגור את הטיקט ולהגדיר את המשימה כהושלמה?
לצערי אין unittests ששווה לכתוב עבור הטיקט הזה.
עם זאת, יהיה אפשר להגיד שסיימתי את המשימה כאשר:
- בכל דחיפת קוד ל־master, יראו את השינויים מיידית ב־https://calendar.pythonic.guru.
- בכל דחיפת קוד לכל branch בפרויקט, נוכל לראות תגובה של הבוט של codecov עם אחוזי ה־coverage לפרויקט.
- בכל דחיפת קוד לכל branch בפרויקט, ירוצו הבדיקות של הפרויקט ו־flake8. אם אחד מהם נכשל, יהיה סימון ברור של הכישלון ב־PR ולא יהיה אפשרי לעשות merge ל־PR.
