לאחרונה יצא לי להיות שותף לפיתוח אינטנסיבי של אתר אינטרנט יש מאין (ללא שימוש במערכת ניהול תוכן). במהלך התכנון והמימוש נתקלנו בבעיות שונות הקשורות לניהול מאגר הקבצים ולשמירת הסדר והסנכרון מול אתר האינטרנט ה"אמיתי", ובנינו פתרון משלנו לכל הבעיות הנ"ל. כעת אני שמח לחלוק ולשתף הן את הבעיות והן את הפתרונות.
המאמר יחולק ל- 2 חלקים:
חלק א' (להלן): קונספט – בעיות נפוצות ופתרונן
חלק ב' (בעוד שלושה שבועות): פרקטיקה, כלים וטיפים
חלק א'
למרות שיש שיחלקו על כך, פיתוח ועיצוב אתרי אינטרנט די דומה במהותו לפיתוח תוכנה "רגיל": ישנן דרישות מהלקוח, תכנון מפרט, מימוש, בדיקות אינטגרציה ושחרור לאויר העולם. ישנו מאגר קבצים שמכיל את כל הקבצים והמסמכים הרלבנטים. וכמובן – איך אפשר בלי התיקונים? לאחר השחרור ישנם תיקונים הנעשים ע"פ הלקוח, וכמובן תמיכה שוטפת.
במה בכל זאת השוני הבולט?
במיידיות ובזמינות. בכל רגע ומכל מחשב בעולם ניתן להעלות שינויים לאתר האמיתי, והשינוי יכנס לתוקף בצורה מיידית. דבר זה קורץ לרבים ממפתחי האתרים ומעצבי האתרים ("למה לא לעשות קופי-פייסט מהמחשב שלי אל השרת???") . הדבר מקבל משנה תוקף משום ששימוש במהדרים (קומפיילרים) לא נפוץ בפיתוח אתרי אינטרנט, ולכן הנטייה להעלאה מיידית של הקבצים אל השרת האמיתי – אם לבדיקה ואם לשחרור הקבצים – מתעצמת עוד יותר ("איך אני אבדוק את העיצוב החדש לבאנר? אני חייבת להעלות את זה לאתר!")
נקודה זו גורמת לבעיות רבות: חוסר סנכרון בין סביבת הפיתוח לסביבה האמיתית שעל השרת, חוסר סנכרון בסביבת הפיתוח במידה וישנה יותר מסביבת פיתוח אחת, ועוד.
להלן כמה תובנות ופתרונות שהגענו אליהם לאחר הקזת דם (וירטואלי):
הקמת סביבות פיתוח למפתחים
זוהי סביבה המדמה את השרת האמיתי, ומכילה כלים נוחים למפתחים.
בדומה לפיתוח "רגיל", מומלץ שימוש במערכת בקרת תצורה כלשהי. אפשר להסתפק גם בכלים חינמים ופשוטים (פירוט טכני על כלים – בחלק ב'). מערכת כזו צריכה לספק את המינימום ההכרחי: אפשרות ליצור גירסאות עבור כל קובץ (check-in check-out) , אפשרות להשוות בין גירסאות הקבצים, אפשרות לעטוף ולסמן גירסת שחרור (label) ואפשרות לחזור לגירסאות ישנות (לכל הפחות ברמת קובץ בודד, אך רצוי גם ברמת label ).
הקמת סביבת בדיקות
תפקיד סביבת הבדיקות הוא לדמות את הסביבה האמיתית. מכיוון שהסביבה האמיתית היא שרת web אמיתי, חשוף לכל העולם, רצוי שגם סביבת הבדיקות תהיה כזו, אך ללא חשיפה למשתמשים לא מורשים.
כדאי לזכור שכל מחשב PC ביתי יכול לשמש כסביבת בדיקות, לכן לא כדאי לוותר בקלות על בניית סביבה כזו. מנסיון – שווה את ההשקעה ויחסוך לכם באגים ואי-נעימויות מול לקוחות ומשתמשים.
יתרון מובהק ונוסף בשימוש כזה – יש לכם העתק מושלם של הסביבה האמיתית, ללא צורך בהשקעה בגיבוי נוסף. חשוב מאוד למי שהאתר שלו מתארח בחברה עלומה אי-שם מעבר לאוקיינוס.
פירוט טכני – בחלק ב'.
סנכרון בין סביבת הפיתוח לבין סביבת הבדיקות, ובין סביבת הבדיקות לבין הסביבה האמיתית (האתר עצמו)
אמר מי שאמר שתמונה שווה אלף מלים. אכן כן.
בתרשים רואים 2 סביבות פיתוח על 2 מחשבים שונים (iMac) , המעבירים את המידע הלאה אל סביבת הבדיקות. מכיוון שיש 2 סביבות פיתוח, ישנו גם סנכרון חזרה – מסביבת הבדיקות אל סביבת הפיתוח השניה.
בפרק הבא – פרקטיקה, כלים וטיפים.
תמיר גפן על ניהול תצורה ומחזור חיי תוכנה 
