שאלה טכנית למתכנתים

[teeto]

היי

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

1. אילו כלים מתאימים יש לאותן בדיקות אוטומטיות? מה הנפוץ ביותר שאתם מכירים?
2. unittestים. מה הם קשורים? האם הם תשובה מלאה/חלקית/ממש לא לשאלה 1?

תודה תודה

 

[paskar]

אפשר להתחיל במה שמשולב כבר בתוך ה-IDE.

ואולי גם דברים כאלה הם בכיוון שאתה מדבר עליו:
https://en.wikipedia.org/wiki/Travis_CI
https://en.wikipedia.org/wiki/Continuous_delivery

 

[c881]

שפה ספציפית?

 

[teeto]

אפשר להתחיל במה שמשולב כבר בתוך ה-IDE.

ואולי גם דברים כאלה הם בכיוון שאתה מדבר עליו:
https://en.wikipedia.org/wiki/Travis_CI
https://en.wikipedia.org/wiki/Continuous_delivery

אכן נראה שזה הכיוון.
גוגל מראה ש jenkins היא התשובה.
אכן כך?

שפה ספציפית?

כן, python.

תודה

 

[half-solid]

לא איש פייתון, אבל הקונספט דומה:
ניתן להשתמש בג'נקינס בתור build server

כלומר, להגדיר job שבעקבות דחיפה של קוד ל- source control (מאמין שאתה משתמש ב-svn/git?)
מיד יבוצע build (שיבדוק שגיאות קומפילציה ובניה של הפרוייקט)
ולאחר מכן job של unit tests למשל (רצף בדיקות שאתה כותב מראש)

כמובן שתוכל לקבל התראה על תוצאות ה-jobs

ניתן גם להגדיר שבמידה ואחד השלבים נכשל, ה-commit/push יידחה.

 

[לארוצה]

משתמש בגיטהאב?

 

[123W]

יש פודקאסט שנקרא 'מפתחים חסרי תרבות'. חפש את הפרק עם רן בר זיק על ci cd

 

[kalore]

בפייתון יש את pytest שאיתו אפשר לממש טסטים שירוצו אוטומטית בג'נקינס וייצרו סביבת CI/CD שזה מה שאתה בעצם מחפש

 

[teeto]

לא איש פייתון, אבל הקונספט דומה:
ניתן להשתמש בג'נקינס בתור build server

כלומר, להגדיר job שבעקבות דחיפה של קוד ל- source control (מאמין שאתה משתמש ב-svn/git?)
מיד יבוצע build (שיבדוק שגיאות קומפילציה ובניה של הפרוייקט)
ולאחר מכן job של unit tests למשל (רצף בדיקות שאתה כותב מראש)

כמובן שתוכל לקבל התראה על תוצאות ה-jobs

ניתן גם להגדיר שבמידה ואחד השלבים נכשל, ה-commit/push יידחה.

תודה רבה, עשית לי סדר.

משתמש בגיטהאב?

כן. git / github.

יש פודקאסט שנקרא 'מפתחים חסרי תרבות'. חפש את הפרק עם רן בר זיק על ci cd

אשמע. תודה.

בפייתון יש את pytest שאיתו אפשר לממש טסטים שירוצו אוטומטית בג'נקינס וייצרו סביבת CI/CD שזה מה שאתה בעצם מחפש

בודק, תודה.

 

[dread]

כן. git / github.

אם אתה משתמש בגיטהאב והטסטים שלך פשוטים (לא צריכים setup מיוחד שיוצר deviceים במכונה או משהו בסגנון) כנראה שהכי קל יהיה להריץ עם github actions, סביר להניח שיש גם מפלייטים מוכנים לפייתון עם pytest

 

[לארוצה]

https://lab.github.com/githubtraining/github-actions:-continuous-integration

 

[minimizer]

א) עוד סיבה לא לכתוב בפיית'ון
ב) טסטים, טסטים, טסטים. נראה שזה יכול לעזור לך:
https://www.techiediaries.com/python-unit-tests-github-actions/

 

[s0lid]

בגדול שווה שתנסה לעקוב אחרי העקרונות הבאים:

1. ה-branch המרכזי שלך (במקרה שלך main) צריך להיות נעול לpush (כלומר שאפילו לא תוכל לדחוף לשם קוד ככה סתם גם אם תרצה)
2. דחיפת קוד חדש ל-main תתבצע אחרי השלמת Pull Request (מעין בקשה לשינוי, באותה בקשה אתה יכול לבקש מאנשים אחרים שיסתכלו על הקוד שלך, להריץ כלים אוטומטים וכו' - ברגע שאתה מסיים את ה Pull Request רק אז הקוד נכנס אל ה main
3. כחלק מהקריטריונים בכלל להיות מסוגל לסיים את ה Pull Request אתה צריך להגדיר Build שרץ על Build Server שרק אם הוא מסתיים בהצלחה אתה מקבל אישור להיות מסוגל לסיים את ה Pull Request

בקשר לכלים נפוצים כבר הגיבו לך,
הקשר ל unit tests הוא שה-Build הזה בסעיף 3 הולך להריץ אותם ולצפות שהם יעברו בשביל לתת את ה OK להמשיך הלאה. ככל שיהיו לך טסטים יותר מקיפים ואיכותיים כך יש סיכוי יותר קטן שאתה או מישהו אחר יצליח להכניס קוד ששובר את הלוגיקה.

יש עוד הרבה בדיקות אחרות שאפשר להריץ ברמה של ה Pull Request שיבדקו עוד דברים אחרים (אבטחה, איכות קוד, כיסוי קוד ועוד)
שווה לך לקרוא על CI CD, release gating

בהצלחה!

 

[teeto]

יש פודקאסט שנקרא 'מפתחים חסרי תרבות'. חפש את הפרק עם רן בר זיק על ci cd

האזנתי. היה מלמד ומעניין, תודה.
אגב, עוד המלצות על פרקים ספציפיים?

א) עוד סיבה לא לכתוב בפיית'ון

פיספסתי אותך. מה הסיבה?
(גילוי נאות: חולה על פייתון)

 

[minimizer]

פיספסתי אותך. מה הסיבה?
(גילוי נאות: חולה על פייתון)

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

 

[DERONDA]

עצה שלי: לפני שאתה מתחיל לעבוד תפתח מחיצה חדשה ותעתיק אליה את כל הקוד,באמצעות XCOPY, ותן לה שם יחודי

אחרי כל התיקונים תיצור עוד מחיצה ותשווה את המחיצות בעזרת DIFFMERGE

ההשוואה תראה לך את כל הקוד ששינית
=================================
אם תכין סקריפטים זה אמור לקחת חלקיק שניה

 

[ofrine]

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

כמות הטסטים (אמורה) להיות דומה/זהה בין השפות, אבל בשפה דינמית הכתיבה/קריאה של הקוד עצמו הרבה יותר נעימה.

 

[מתכנת]

עצה שלי: לפני שאתה מתחיל לעבוד תפתח מחיצה חדשה ותעתיק אליה את כל הקוד,באמצעות XCOPY, ותן לה שם יחודי

אחרי כל התיקונים תיצור עוד מחיצה ותשווה את המחיצות בעזרת DIFFMERGE

ההשוואה תראה לך את כל הקוד ששינית

אני עושה את הפרקטיקה הזו אבל דרך git branchs, יש כלים להשוות בין branches, הרבה יותר נקי ובטוח מאשר להתעסק עם hard copy של תיקיות

הייתי שמח אילו עם כל דחיפה של שינויים לmain (או כל branch אחר)
יתבצעו מספר בדיקות אוטומטיות, לוודא שלא שברתי שום דבר בקוד.

אתה עובד לבד עם עם צוות ? יש devops ?

א) עוד סיבה לא לכתוב בפיית'ון

לא הבנתי אותך, מהם הסיבות מעבר למה שענית על dynamic types ?

 

[roneng]

עצה שלי: לפני שאתה מתחיל לעבוד תפתח מחיצה חדשה ותעתיק אליה את כל הקוד,באמצעות XCOPY, ותן לה שם יחודי

אחרי כל התיקונים תיצור עוד מחיצה ותשווה את המחיצות בעזרת DIFFMERGE

ההשוואה תראה לך את כל הקוד ששינית
=================================
אם תכין סקריפטים זה אמור לקחת חלקיק שניה

למה לא לעשות פשוט git diff?
כל הרעיון של עבודה עם מערכות ניהול קוד (גיט ודומיו) זה בדיוק לדעת מה שינית בכל פעם. למה לעבוד בצורה עקומה עם תיקיות?

 

[minimizer]

לא הבנתי אותך, מהם הסיבות מעבר למה שענית על dynamic types ?

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