WEBA

CI/CD: מה זה?

צנרת אוטומטית: כל שינוי בקוד נבנה, נבדק, ואם עבר, נפרס לשרת.

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

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

יש כלים נפוצים בתחום הזה, וביניהם GitHub Actions שיושב איפה שהקוד, GitLab CI, CircleCI וגם Jenkins הוותיק. הטעות של הרבה מנהלים היא לחשוב שעצם הנוכחות של אחד הכלים האלה בחוזה מבטיחה שהאתר חסין מבעיות. הכלים האלה הם רק רובוט שמריץ בדיוק את מה שהמתכנתים כתבו לו לבדוק. אם אף אחד לא הגדיר בדיקה אמיתית לתהליך הסליקה, קוד פגום יעלה לאוויר בשקט. לעסק שמזמין פיתוח זו שאלה טובה לספק, איך אתם פורסים, ומה קורה אם משהו נשבר בערב.

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

כלים שהמונח חי בהם