5 צעדים לאוטומציה בפיתוח תוכנה

למה לעשות אוטומציה?

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

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

1. זהה את השגרה

הצעד הראשון הוא לבחון לעומק את תהליך הפיתוח ולמצוא מה באמת חוזר על עצמו ואפשר להפוך לאוטומטי, ובשביל זה כדאי לשאול את השאלות הבאות:

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

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

2. תעדף משימות

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

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

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

3. כלים

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

• שפות סקריפט: Python, Bash, PowerShell. גמישות ומתאימות למגוון רחב של משימות: עיבוד קבצים, עבודה מול API, ניתוח לוגים, יצירת קוד ועיבוד נתונים.
• מערכות CI/CD: Jenkins, GitLab CI/CD, GitHub Actions, CircleCI. אלה הכלים המקובלים לאוטומציה של צינורות בנייה, בדיקה ופריסה שרצים מעצמם בכל שינוי במאגר.
• כלי ניהול תצורה: Ansible, Chef, Puppet. משמשים להגדרת שרתים ולפריסת אפליקציות באופן אוטומטי, ושומרים על סביבות פיתוח וייצור זהות.
• כלי בדיקה: Selenium (בדיקות ווב), JUnit/NUnit (בדיקות יחידה), Postman (בדיקות API). בדיקות אוטומטיות מקצרות את הזמן שהולך על אימות הפונקציונליות ועל בדיקות רגרסיה, וזה אחד מסוגי האוטומציה עם ה-ROI הגבוה ביותר בפיתוח תוכנה.
• כלי linting ועיצוב קוד: ESLint, Prettier, Black. הכלים האלה אוכפים את סטנדרט הקוד מעצמם, כך שאין צורך לתקן סגנון ידנית ולבזבז על זה זמן בסקירת קוד.
• מתזמני משימות: Cron (Linux), Task Scheduler (Windows). מריצים סקריפטים ותוכניות לפי לוח זמנים קבוע, בלי שמישהו יצטרך להפעיל אותם.

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

4. הטמע אוטומציה

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

1. בנו את הפתרון המינימלי שעובד: פתרון שעושה רק את מה שנדרש, למשל סקריפט בסיסי אם מדובר באוטומציה בסקריפטים או צינור בסיסי אם מדובר ב-CI/CD. כשמגבילים את ההיקף בשלב הזה, לא נופלים להנדסת יתר שמעכבת את הפריסה.
2. בדקו היטב: לפני שמכניסים את הפתרון לתהליך העבודה הראשי, ודאו שהוא עובד נכון במגוון תרחישים, עם קלטים שונים ובמקרי קצה. תקלה שנמצאת עכשיו זולה בהרבה לתיקון מתקלה שמתגלה אחרי השילוב.
3. שלבו בתהליך העבודה: הכניסו את הסקריפטים לבקרת גרסאות וודאו שכל מי שצריך בצוות יכול להגיע אליהם. בצינורות CI/CD בדקו את החיבור למאגר ואת התנאים שמפעילים את הצינור.
4. תעדו: כתבו איך התהליך האוטומטי עובד, אילו פרמטרים הוא מקבל, מה הוא מפיק ואיך מתחזקים אותו. תיעוד טוב מוזיל את התחזוקה ומקצר את הזמן שלוקח לחברי צוות חדשים להיכנס לעניינים.
5. הדריכו את הצוות: ודאו שכולם יודעים להשתמש בכלי או בתהליך החדש, בעזרת מפגש קצר או הוראות כתובות צעד אחר צעד. ככל שיותר אנשים משתמשים בו, כך גדל החלק מהחיסכון הפוטנציאלי שמתממש בפועל.

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

5. תחזוקה

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

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

מאמרים קשורים:

על הגישה של Agile לניהול פרויקטים וצוותים, קראו את ניהול פרויקטים Agile: טיפול יעיל בפרויקטים.

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

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

מסקנה

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