העלאות גרסה (deployment) לשרת זה לא נושא חד משמעי בעיקר בשל ריבוי השיטות והאמצעים בהם ניתן להשתמש.אני בתור התחלה רוצה לדבר על האיך לפני המה.
Measure Twice. Automate Once
כמו שבפיתוח יש משפט נפוץ “Think twice, code once” כך אותו דבר כשהופכים תהליכים ידניים לאוטומטיים, יש להתחשב בכלל הגורמים כשמתכננים אוטומציה. האם סוגי הקבצים השונים מתאימים לתהליך? האם מתאים לworkflow של הפרויקט? ועוד.
חסרונות בהעלאת גרסה ידנית לעומת יתרונות באוטומציה
You’re either the one that creates the automation or you’re getting automated.
Tom Preston-Werner
בהרבה מחברות בניית האתרים שעבדתי איתם תהליך העלאת הגרסה עבר כך:
- יצירת תיקייה חדשה במחשב
- בחינה והעתקה של קבצים המיועדים לגרסה לתיקייה
- גרירה של הקבצים לFTP client
- בדיקת הגרסה
יש הרבה בעיות בשיטה הזו, אצביע על כמה:
- ללא דרך אוטומטית לזיהוי הקבצים הנדרשים לגרסה סיכויים גבוהים לפספוסים
- חוסר יעילות ובזבוז זמן
- ביצוע rollback מייגע
- חוסר אחידות בקבצים בשרת- אין לנו דרך לדעת שקבצי השרת הם אחד לאחד כמו גרסת הפיתוח אצלנו
אפשר להימנע מכל הבעיות האלו ע”י שימוש בGit בהעלאת גרסה.
הקמת repo בשרת
עכשיו ניצור “bare repository” של Git – ללא קבצים פיזיים. תכל’ס הוא פשוט מכיל את כל מה שיש בתוך תיקיית .git בדרך כלל, אפשר לקרוא לתיקייה זו בכל שם שתרצו אך בדרך כלל כדי לדבוק ב convention עדיף לקרוא לזה בשם הפרויקט עם סיומת של .git ע”מ שנוכל להבין שזה repo:
|
1 |
$ git init --bare ~/project.git |
הוספת hook של post-receive
הקוד הזה יבוצע כל פעם שידחפו לrepo הזה קוד. הקובץ עצמו ממוקם ב project.git/hooks והוא נקרא בשם post-receive, תוכלו להשתמש בעורך החביב עליכם ע”מ ליצור ולערוך אותו.
באופן בסיסי מה שהקוד עושה זה לבדוק שאתם פורסים את הקבצים של הbranch המורשה מבחינתכם לסביבה הנוכחית ובמידה וכן הוא פורש את כל הקבצים הנצרכים לתיקיית הפרויקט שהוגדרה:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
#!/bin/bash TARGET="/home/webuser/deploy-folder" GIT_DIR="/home/webuser/www.git" BRANCH="master" while read oldrev newrev ref do # only checking out the master (or whatever branch you would like to deploy) if [ "$ref" = "refs/heads/$BRANCH" ]; then echo "Ref $ref received. Deploying ${BRANCH} branch to production..." git --work-tree=$TARGET --git-dir=$GIT_DIR checkout -f $BRANCH else echo "Ref $ref received. Doing nothing: only the ${BRANCH} branch may be deployed on this server." fi done |
באופן אישי בסביבות QA אני לא מגביל את הbranch המורשה ופורס כל דבר שדוחפים:
|
1 2 3 4 5 6 7 8 9 10 |
#!/bin/bash TARGET="/home/webuser/deploy-folder" GIT_DIR="/home/webuser/www.git" # get pushed branch read oldrev newrev ref BRANCH=${ref#refs/heads/} echo "Deploying ${BRANCH} branch to website..." git --work-tree=$TARGET --git-dir=$GIT_DIR checkout -f $BRANCH |
לאחר מכן צריך לתת הרשאות הרצה לקובץ:
|
1 |
$ chmod +x post-receive |
יצירת remote במחשב הלוקאלי
אנחנו צריכים לקנפג את הנתיב לrepo בשרת המרוחק בremote:
|
1 |
$ git remote add qa ssh://user@mydomain.com/home/webuser/www.git |
אז עכשיו אנחנו רוצים לשלוח את כל הקבצים שלנו לשרת:
|
1 |
$ git push qa master |
וכך בהגדרות פשוטות ביותר ופקודה אחת אנחנו שולחים גרסאות בקלות לשרתים, שינוי רציני מהעלאות ידניות של קבצים.
continuous delivery means minimizing lead time from idea to production and then feeding back to idea again
Rolf Andrew Russell
יפה מאוד,
נשמע כמו התחלה טובה ובסיס בריא בפיתוח ווב.
כל הכבוד
תגיד מדוע תיקיית הuploades שלך חשופה לעולם…..?
תודה רבה משה 🙂
לא יודע אם זו באמת בעיית אבטחה אבל חסמתי ליתר ביטחון, תודה על הטיפ
כל הכבוד !!!
מדריך מעולה