מתחילים עם Travic-CI

Alonisser ,22/07/2013

בעקבות שתי מפגשים בILTechTalks שבהם Wix וOutbrain הציגו את הגרסה שלהם לפיתוח מוטה CI/CD (אינטגרציה והקמה מתמדת) החלטתי להתנסות בעצמי בטכנולוגיה המלהיבה הזו ולכתוב על שרת הקוד פתוח Travis-CI - שרת הCI שמשרת רבים מהפרוייקטים בקוד פתוח כחלק מסדרת כלי הDevops שאנחנו עושים פה.

מה זה בכלל שרת CI ?

על איזה צורך הוא עונה בעצם? CI == Continuous Integration או "אינטגרציה מתמשכת" בשפת הקודש. כלומר כלי/שירות שמסייע לנו לשחרר כל הזמן קוד איכותי. החלופה? לחכות לשחרור "גרסאות" גדולות או מינוריות. לpush מרכזי לdeployment וכו'. שרת CI מאפשר לנו תמונה בפידבק קצר יחסית של מה הקוד שכתבנו עושה/לא עושה. הוא גם מאפשר להפעיל סדרה אוטומטית של פעולות בהתאם לתוצאות תהליך האינטגרציה (הBuild), כמו להעלות את הקוד לאתר/שירות וכו'. הוא גם נדרש במיוחד בפרוייקטים שבהם אנחנו מקבלים קוד מממפתחים/צוותים אחרים שלאו דווקא עובדים במשותף או במסונכרן. למשל בפרוייקטים של קוד פתוח שמקבלים Pull request ממפתח שעבד על הפרוייקט שלנו. איך נבדוק שהcommits שלו לא שוברים את הקוד? בדיוק! עם שרת אינטגרציה שיריץ עבורנו אוטומטית את הבדיקות הנדרשות מול כל commit.

עוד תסריט הוא זה שאנחנו מפתחים עם גרסאות תוכנה מסויימות שמותקנות במחשב שלנו: למשל גרסת פייטון כזו וכזו, גרסה מסויימת של הספריות וכו'. האם הקוד שלנו יעבוד גם אצל משתמש/מפתח שהספריות אצלו בגרסה אחרת? על שרת שמותקנת בו גרסת פייטון ישנה יותר? בלי שרת אינטגרציה אנחנו יכולים או לנחש או להתקין סביבות מקבילות על מחשב הפיתוח שלנו עם הגרסאות השונות (וזה מסובך בפני עצמו שמדובר על גרסאות שונות של קומפיילר או אינטרפטר של שפת תכנות) ולבדוק כל commit על כל הסביבות האלו. טרחני למדי וסביר שלא נעשה את זה. נסתפק בלכתוב שנבדק רק עם גרסה כזו וכזו.. מה שמעביר את הסיכון למשתמשים (שאולי יבחרו שלא לקחת אותו). שרת אינטגרציה שבונה סביבה "נקייה" מאפשר לסמלצ סביבות שונות ואפשרוית שונות ולראות מתי הקוד עובד ואיפה נשבר.

וטראוויס החביב? הוא בדיוק שרת CI כזה. רק עם גרסה פתוחה וחינמית לפרויקטים של קוד פתוח שמתוחזקת ע"י תרומה של הקהילה והworkers שמניעים אותה נתרמים ע"י חברות טכנולוגיה שונות מהשרתים בתת ניצול שלהם (וזה גם אומר שאל תבזבזו את המשאבים האלו סתם, יש פירוט בהמשך). גם Travis-CI הוא פרוייקט קוד פתוח (וכן, עם פאצ' קטנטן שלי). travis ci

איך מתחילים

1.בדיקות. איך מה לעשות עם שרת אינטגרציה אם אין Build. נכון, טכנית בשפות דינאמיות אין Build כי אין קמפול אבל למעשה אנחנו מתייחסים כאן לבדיקות האוטומטיות של הקוד כ Build, כמו גם לעצם שרשרת ההתקנות והתלויות (Dependencies). כל אלו יכולים להצליח או להכשל ומכאן ששרת האינטגרציה יכול לבדוק אותם

2.פותחים חשבון ומגדירים Repo עושים לוגין עם החשבון GitHub שלכם ל Travic-CI ואחרי שרשימת הrepos שלכם מתרעננת בוחרים מהגדרות החשבון repo (או רבים) שטראוויס ינטר. טראוויס יסדר אוטומטית את הגדרות הhooks המתאימות בGithub. כמובן שאתם יכולים גם לשלוט בזה ידנית. (שימו לב שבחלק מהמדריכים הישנים מוסבר שצריך ללכת לGithub ולהגדיר את זה ידנית, זה כבר לא נכון)

travis add repo 3..travis.yml. מוסיפים לבסיס (root) של הפרוייקט שלכם קובץ .travis.yml שמכיל את ההגדרות לשרת האינטרגציה. איזו שפה בודקים? ובאיזה גרסאות שלה?, מה משתני המערכת הנוספים (למשל גרסאות שונות של התלויות). מה צריך להתקין בשביל להריץ את הקוד? ומה סקריפט הבדיקה הרצוי.

language: python
python:
  - "2.6"
  - "2.7"
 env:
  - DJANGO=Django==1.5.1
  - DJANGO=Django==1.4.3
  - DJANGO=https://www.djangoproject.com/download/1.6b1/tarball/
matrix:
  # since isn't a Django release
  allow failures:
  - env: DJANGO=https://www.djangoproject.com/download/1.6b1/tarball/
 #the only version of django that's supposed to support 3.3
 #Note we are adding another test to the matrix this way.
 #we could also exclude a test from the matrix this way
  include:
  - python: "3.3"
    env: DJANGO=https://www.djangoproject.com/download/1.6b1/tarball/
install:
  - pip install -q $DJANGO --use-mirrors
  - pip install -r requirements.txt --use-mirrors
  - pip install -q django-setuptest --use-mirrors
script:
  - python setup.py test

בואו נפרק את זה רגע:
אנחנו מגדירים שפה (אם לא נגדיר ברירת המחדל תהיה ruby), אנחנו מגדירים משתני סביבה בenv שישתנו בין הבדיקות. אנחנו מגדירים מה להתקין לפני הבדיקה ואיזה סקריפט בדיקה בדיוק להריץ. שימו לב שיש לא מעט אמצעי בדיקות וסביבות שבאים מותקנים מראש בruntime של travis אבל אם אין אז צריך להתקין אותם ברירת המחדל היא מטריקס בדיקות שכולל את כל ההצלבות השונות בין הגרסאות שפה לגרסאות משתני הסביבה, אבל אפשר לקסטם גם את זה.
למשל נוכל להגדיר (כמו בדוגמא) שיש הצלבות שלא נרצה לעשות כי הן לא שימושיות. או בדיקות שנרצה לעשות כדי לדעת מה התוצאה אבל לא להחשיב את התוצאה שלהם בעובר/לא עובר.

4.אחרון חביב מוסיפים קישור לתמונה של "עובר"/"לא עובר" לReadme או לאתר שלכם. כדי שכולם ידעו מה מצבכם בעצם.

שימו לב! גם אם הגדרתם הכל, עד שתעשו Git push השרת לא יתחיל להריץ את סט הבדיקות.

מה עכשיו?

עכשיו תתחילו לקבל דיווחים במייל או באתר עצמו על מצב הbuild. travis build status כל Job שמוצג בMatrix הוא ההצלבה בין המשתנים השונים שהגדרנו בקובץ ואפשר בלחיצה עליו לראות את הconsole ממש (וככה להבין אם עשינו שגיאה בהגדרות, כמו שקרה לי לפחות לא מעט)

travis job console

טיפים ודגשים

  • בדיקת סינטקס: כלי נוסף שיכול לסייע הוא הLinter של Travic-ci . בעצם בודק תקפות של ה.travis-ci יש גרסה וובית וגרסת gem שיודעת לעשות את זה משורת הפקודה. האמת שהוא לא תמיד "תופש" את כל השגיאות עדיין (והוביל אותי כך לטעות די מביכה) אבל אני בטוח שזה ישתפר בקרוב.
  • קירות שקופים כל מי שיושב ובוהה במסך של טראוויס יכול לראות את הBuild שלכם נבנה. אם אתם בStealth mode עם הפרוייקט שלכם (אפילו עם פרוייקט קוד פתוח סודי) כדאי שלא תלכו לכיוון הזה (או אם אתם מתחזקים פרוייקט קוד פתוח חשוב במיוחד שיש סיבה שיהיה סודי עד ההשקעה צרו איתם קשר, אני מכיר מקרה אחד לפחות, שזה עבד). אבל אני חושב שעצם ההתנסות בשרת כזה היא חשובה ותתן לכם/לכן כלים להטמיע כזה אח"כ בתוך הארגון שלכם. בכל מקרה, אם העניין שדורש פרטיות וסודיות הוא מפתחות הפעלה כאלו ואחרים אז Travis כן מאפשר להצפין מחרוזות כאלו אם תתקינו את הGem שלו ולהשתמש במחרוזות האלו ב.travis.yml שלכם. אגב, אם יש לכם Private repo (אבל לא Github enterprise מקומי) יש אפשרות לשירות בתשלום שלא יהיה גלוי.

  • לדווח אחורה אפשר להגדיר ב.travis.yml אמצעי יצירת קשר שונים. ברירת המחדל היא שתקבלו אימייל עם עדכון לאימייל שמחובר לחשבון github שלכם, אבל אפשר להגדיר עוד אימיילים, IRC, webhooks שיגעו בurl מיוחד שבניתם וכו'

  • no ci לא כל קומיט צריך להריץ בדיקה. לפעמים זה סתם תיקון בטקסט של האתר שלא משנה כלום. לפעמים זה קומיט אחרי שינוי קוד גדול שאנחנו עוד רוצים להריץ בדיקות מקומיות לפני הטראוויס. סתם אנחנו רוצים לחסוך משאבים לקהילה (וכאמור, מדובר במשאבים שהקהילה מממנת) במקרה הזה נוסיף להודעת הcommit את הצירוף: [no ci]. חוץ מזה: בדיקות סינטקס פשוטות וlint בסיסי אולי כדאי לעשות בתוך git pre-commit hook ולא כחלק מחבילת הבדיקות הכללית. איך? זה כבר עניין לפוסט אחר.
  • אין עבר טראוויס מבודד את הבדיקות זו מזו, אין קשר בינהם, אין מידע שנשמר, אין תלויות שמותקנות לכמה בדיקות. הכל מחדש בכל פעם. בדרך כלל זה משרת אותנו מצויין ומונע מאיתנו ליפול בטעות שנובעת מState שנשמר על המכונה שלנו. אם נרצה יותר state נצטרך שהסקריפטים של הבדיקות ישדרו תוצאות לשירות אחר וידעו למשוך משם את הstate הקודם.

דוגמא

הפרוייקט לדוגמא שהוספתי לו בדיקה בTravis-ci הוא Django-localflavor-il (בפורק שלי) חבילת הקסטום לעברית של הולידטורים של טפסי Django. פייטוניסטים יכולים להעזר במדריך להוספת סביבת בדיקות עצמאית מול Travis-ci (בלי התקנת django מלאה מסביב) לdjango app שאפשר למצוא כאן שמתבסס על STUB שמשלים את הנתונים החסרים לdjango להרצת הבדיקות.

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

Tags:

תגובה