כמה מילים על המרה מערכת לניהול גרסאות קוד

בשנה האחרונה ביצעתי מספר פרויקטים הקשורים להמרת מערכת לניהול גרסאות קוד, ממערכות שונות למערכות מבוססות GIT (כמו GitLab, או Bit Bucket ואחרים), ורציתי לשתף עם הקוראים כמה תובנות בנושא.

אם יש סוג מסויים של עסקים בהם אין עבודה כזו, אלו הם הסטארטאפים. אני לא מכיר ולא שמעתי אפילו על סטארטאפ אחד שלא משתמש בפתרון מבוסס GIT (בין בשימוש שרת GIT, שימוש בשרותי GIT של ספקי הענן וכו'). בדרך כלל עניין ההמרה מתרחש אצל חברות ותיקות, ושם אצל אותן חברות ותיקות יש כל מיני פתרונות לניהול קוד, בין אם מדובר ב-TFS (או VSS), ב-Subversion או Mercurial, וכן .. יש גם חברות שמשתמשות ב-CVS. כמעט בכל חברה, מעבר למערכת ניהול קוד אחרת זה תהליך לא קל (בירוקרטית וניהולית, טכנית ניתן להמיר את הדברים ביום או יומיים, תלוי בכל מיני פרמטרים).

ככל שעובר הזמן, עניין המעבר ל-GIT נהיה פחות "אופציה" ויותר "צורך". חברות שחושבות לעבור להשתמש במערכות מבוססות קונטיינרים (בין אם זה Kubernetes, OpenShift, CaaS, Rancher, Mesos ועוד) יצטרכו להבין עוד בהתחלה שמבחינה טכנית ניתן איכשהו לעבור עם מערכת ניהול קוד הנוכחית שיש להן, אבל אם מכניסים מערכת קונטיינרים ל-Enterprise, הצורך לעבור ל-GIT יהיה יותר דחוף.

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

  • המרת קוד ממערכת קיימת למערכת GIT חדשה (מקומית, מכונה בענן, שרות GIT של ספק הענן) כולל היסטוריה ורוויזיות.
  • התאמת הכלים המקומיים שלהם לעבוד מול מערכת ה-GIT.
  • ביצוע "פרישה" (Retire) של מערכת הקוד הנוכחית.
  • תמיכה שוטפת.

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

  • אם אתם חברה גדולה ומסודרת, ואני אוריד את מערכת הקוד הנוכחית ואמחק אותה, והמחלקה המשפטית שלכם תשמע את זה, הם ירדפו אחריי עם נבוטים. קוד ישן ומערכות ישנות צריכות להיות זמינות במקרה שהחברה נתבעת על העתקת קוד או הפרת פטנטים. ישנה חשיבות קריטית לזמנים (תאריכים, כולל שעה מדוייקת) של הכנסת קוד והדברים האלו יוצגו בבית משפט/דיונים מול התובעת כדי להראות סתירות בתביעה. לכן, מה שעושים לגבי מערכות ניהול קוד קיימות (לאחר מעבר לעבודה עם GIT) – הוא שמירת גיבוי, כיבוי המכונה אך לא למחוק אותן.
  • העברת היסטוריה מלאה של קוד קיים ממערכות ניהול קוד אחרות ל-GIT: זה אפשרי בחלק מהמקרים (לדוגמא: mercurial או TFS) אך בעייתי במקרים כמו CVS או Subversion, ולכן בדרך כלל ההמלצה היא להעביר קוד נוכחי ולשמור קוד/Branches ישנים במערכת הקודמת. מיקרוסופט בעבר הבטיחו ללקוחות כי הם יעבירו בקלות קוד מ-SVN ל-GIT כולל היסטוריה מלאה, ורק אחרי שהם התחילו את הפרויקט, הם ראו כמה זה לא ממש ריאלי (במיוחד אם יש קוד ענק של מספר שנים) ומאז הם ירדו מכך.
  • האם להשתמש בשרותי Code Repository של ספק הענן שאיתו אתם עובדים או להרים VM עם אפליקציית שרת GIT (כמו GitLab, BitBucket, GitHub Enterprise)? זה תלוי בכם. אם חתמתם עם ספק הענן על חבילת תמיכה רצינית, אז אולי כדאי להשתמש בשרות (שימו לב, שתצטרכו לשלם תשלום חודשי על כך. באמזון AWS ה-5 משתמשים ראשונים הם בחינם). לעומת זאת, אפשר להקים Instance ולהקים מערכת GIT כמו אלו שציינתי במחירים נוחים:
    • מערכת GitLab היא חינמית כל עוד אינכם צריכים תמיכה מסחרית מהחברה.
    • מערכת BitBucket היא חינמית ל-5 משתמשים ראשונים, 2$ לאחר מכן (מינימום 10 משתמשים) ואתם מקבלים גם אינטגרציה עם Jira.
      שימו לב: ב-2 המקרים אתם מקבלים גם תמיכת Pipelines כדי לבצע אוטומציה לקימפולים, קונטיינרים וכו'.
  • עבודה עם מערכת ניהול קוד נוכחית יחד עם GIT: אם יש לכם מערכת ניהול קוד ישן מבוססת Subversion, ניתן להקים מערכת (היא בתשלום אם יש יותר מ-10 משתמשים) המאפשרת לעבוד מול ה-Subversion והמערכת המסחרית תמיר מיידית את הקוד למערכת ה-GIT שלכם ולהיפך, כך שניתן להמיר את המפתחים לעבודה ב-GIT ואת האוטומציה (Jenkins, Team City וכו') בהדרגה ולא במכה אחת.
  • תמיכה והדרכה – חשוב לסגור את העניין במסגרת חוזה הפרויקט. קל מאוד לעשות שטויות מצד אחד ובמקרים רבים גם לא מנצלים את היתרון של מערכות מבוססות GIT מצד שני – וחבל.

לסיכום: אם לא עברתם בחברה ל-GIT, סביר להניח שתעברו בהמשך לעבוד מול GIT ולכן כדאי להכיר מה זה GIT. אתם יכולים להקים מערכת נחמדה שאני מריץ ב-LAB שנקראת GOGS שהיא מערכת מיניאטורית עם ממשק וובי לניהול GIT (דרישות החומרה שלה מאוד קטנות, היא רצה על כל מערכת הפעלה באופן טבעי וגם כקונטיינר, אבל היא לא מיועדת לארח פרויקטי קוד גדולים, היא יותר לדברים קטנים או סתם להתנסות מה זה Git עם ממשק וובי נחמד). אם אתם מעוניינים בפרויקט המרה, קחו בחשבון את הנקודות שציינתי לעיל.

מבוך מבלבל בהבטחות

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

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

נעבור לספקי שרתי VPS: יש כאלו המציעים "ניהול מלא", אבל הם מתכוונים בעצם לכל מה שמוצע בפאנל, אולי גם בדיקת תקשורת ו-Boot, אבל כל דבר מעבר לכך – זה בתשלום נוסף. שיטה אחרת היא "הגדרות כלול בחבילת ניהול", אך בעצם מדובר בהגדרות ראשוניות, כך שאם לדוגמא השרת שלך צריך לקבל 10,000 איש ליום, אותן הגדרות אינן נכללות במחיר החבילה ויש לשלם עבור שינויי הגדרות בנפרד. נדפקו הגדרות? הקמת הגדרות חדשות בתשלום נוסף בלבד.

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

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

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

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

בהצלחה

Exit mobile version