פיתוח במחשב לוקאלי והעלאה לשרת - עם Features?
שאלתי כאן בעבר, והמליצו לי להשתמש במודול Features כדי לפתח ולקנפג על מחשב לוקאלי ולהעלות לשרת.
לפיתוח הראשוני, אני מבין שאפשר להשתמש ב- features בשביל ההגדרות, סוגי תוכן וכו', וב- export בשביל Nodes.
השאלה היא, מה קורה עם שינויים קטנים שאני רוצה לעשות לאחר מכן.
אם אבצע אותם על המחשב הלוקאלי ואז אעלה לשרת, אין בעיה. השאלה היא מה קורה אם אני מבצע את השינויים בשרת ואז רוצה להעלות שוב שינויים מהמחשב הלוקאלי.
כשניסיתי לעשות זאת קצת נדפקו לי הדברים.
כיצד אתם עושים זאת? מישהו יכול להמליץ לי על צורת עבודה נוחה?
תגים:
אם שינויים קטנים לא דרך
אם שינויים קטנים לא דרך features אז צריך לעשות אותם בשרת הלוקאלי במקביל כדי שבפעם הבאה שתעלה feature הם לא ידרסו
yakoub abaya
צריך לעבוד עם ניהול גרסאות.
צריך לעבוד עם ניהול גרסאות. ראה http://en.wikipedia.org/wiki/Revision_control
אתה מתכוון להכניס ה מודול ש
אתה מתכוון להכניס ה מודול ש features מייצר לניהול גרסאות ?
אבל הכוונה איך שהבנתי שלא רוצים להשתמש ב features בכלל בשביל שינויים קטנים
yakoub abaya
כן, זה מה שהתכוונתי, וזה עובד
כן, זה מה שהתכוונתי, וזה עובד מעולה.
היי yhager, אני מניח שחיפשתי
היי yhager,
אני מניח שחיפשתי יותר פרטים לגבי צורת העבודה.
בהתחלה חשבתי שהתכוונתי לניהול גירסאות בעזרת מערכת לניהול קוד.
אני מבין שאתה מדבר על Features.
אם הבנתי נכון, בכל שינוי שאתה מבצע על אחד מהאתרים אתה מייצר גירסת Features וטוען אותה באתר השני לפני שאתה מבצע בו שינויים?
האם זה לא אומר שיש לך עשרות (אם לא מאות) תיקיות Features?
בהתחלה חשבתי שהתכוונתי לניהול
כן, לזה התכוונתי.
מה ש features.module עושה זה מייצר קוד מתוך קונפיגורציה שביצעת בעזרת ממשק המשתמש. את הקוד שהוא מייצר אני מכניס לתוך ניהול הגרסאות (מבצע check in). אח"כ מכל מקום שבו אני רוצה לעדכן את השינויים אני מבצע check out.
הסברתי את עצמי יותר טוב עכשיו?
נראה לי שהפעולה שתיארתה שקולה
נראה לי שהפעולה שתיארתה שקולה לפעולת העתקה פשוטה בלי ci,co
לאחר ביצוע שינויים בשרת זה יהיה באחריות מודול features לעדכן המודול
ואז פשוט מורידים אותו מהשרת ומעתיקים מעל המודול הלוקאלי
אחר כך לוקאלית אפשר להפעיל ניהול גרסאות או לא להפעיל , אני לא
רואה איך זה קשור לתיאום בין השרת ללוקאל
yakoub abaya
נראה לי שהפעולה שתיארתה שקולה
חס וחלילה. ניהול גרסאות נותן לך עוד הרבה דברים חוץ מהעתקת קבצים - הסטוריה, אפשרות חזרה אחורה, התפצלות לענפים, תיאור מה עשה כל שינוי, מי עשה אותו, מתי וכו'.
זה א-ב של פיתוח תוכנה - אני לא ממליץ לאף אחד לכתוב שורת קוד אחת בלי ניהול גרסאות.
נו ברוורררר אני ידוע מזה
נו ברוורררר אני ידוע מזה ניהול גרסאות ... אבל השאלה הראשונה היתה על תיאום בין השרת למחשב לוקאלי ולא הבנתי איך ניהול גרסאות נכנס לכל העניין .
בכל מקרא אני לא משתמש לא ב features , views, cck וכל הדברים האלה , הכל אצלי בקוד וכמובן שמנהל גרסאות אז כנראה יש משהו ב features שאני לא מבין
כמו ש psi אמר : איך נמנעים מלייצר מודולים שונים לכל שינוי קטן
yakoub abaya
ניחשתי שאתה יודע, אבל זה
ניחשתי שאתה יודע, אבל זה פורום ויש עוד שקוראים, ועלולים להבין את הודעתך הקודמת כאילו העתקת קבצים זה יותר פשוט מניהול גרסאות.
אם אתה לא משתמש ב views ולא ב CCK, אז באמת ש features זה לא בשבילך.
חברים, הנה מה שהבנתי: ניתן
חברים, הנה מה שהבנתי:
ניתן להשתמש ב- Features בשתי צורות:
הפשוטה - ייצוא הגדרות ואלמנטים בעזרת הממשק הגראפי לקבצים אותם אפשר לטעון באתר אחר. בצורה זו לא ניתן להעביר Nodes.
המורחבת- שימוש ב- SVN (גם GIT?) ליצירת גירסאות הכוללות אלמנטים וקוד.
במידה רוצה לדבוק בכלים הגראפיים (לא בגלל עצלנות או רשלנות אלא בגלל צורך נוכחי), אני מבין שיש לי שתי אופציות לפיתוח במחשב לוקאלי והעלאה לשרת:
א. ביצוע Backup ו- restore. אני בטוח שלכמה אנשים כאן עברה צמרמורת רק מעצם המחשבה, אבל זו אופציה קיימת ועובדת.
אם כל השינוים נעשים קודם כל במחשב הלוקאלי ורק אז בשרת ה- Webי, נראה לי שזו אפציה שתעבוד.
ב. תיעוד כל השינויים ידנית וביצועם באתר השני.
האם האופציות הנ"ל באמת כ"כ גרועות?
האם אתם מכירים פתרונות אחרים שלא יחייבו אותי להיכנס לעולם ניהול הקוד ויאפשרו לי להישאר (בינתיים) בסביבה הגראפית והסגורה?
האופציה הראשונה לא כ"כ רעה,
האופציה הראשונה לא כ"כ רעה, בתנאי שאין שינויים באתר החי - תגובות משתמשים, תכנים וכו', הכל יידרס עם כל עדכון שלך.
גם האופציה השניה לא רעה בכלל, ואין את בעית הדריסה. הבעיה היא שתמיד תעשה דברים שתשכח, או שלא תתעד, או שבהעברה תהיה טעות. הגורם האנושי הוא הבעיה באפשרות זו.
"יש יותר מדרך אחת לעשות את זה"(tm), אבל התשובות שקיבלת כאן מכוונות אותך לדרך הנכונה שתקח אותך קדימה בצורה טובה. אתה כמובן יכול ללכת בדרך קיצור, אבל תבין מה אתה מקצר, ואיפה אתה מסתכן.
http://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it
אני מתכנן לעבוד בשני
אני מתכנן לעבוד בשני שלבים:
בשלב הפיתוח הראשוני - עד שהלקוח יקבל גישה לאתר - אבצע את כל השינויים לוקאלית ואעלה לשרת.
לאחר שהלקוח יקבל גישה ויוכל לבצע שינויים באתר, אני והוא נבצע את כל השינויים באתר שבאוויר, ודריסה של הנתונים באתר הלוקאלי.
ככה גם יצא לי לבדוק את הגיבויים.
נשמע טוב?
חשוב לי להסביר פה משהו למי
חשוב לי להסביר פה משהו למי שמתעניין בנושא ונתקל בשרשור הזה, ברור לי שהמנוסים מבינכם כבר מבינים את זה אבל אני לא בטוח שזה מספיק ברור בשביל מי שלא עבד עם פיצ'רס\ניהול גרסאות בעבר, במיוחד לאור התגובות האחרונות .
ככה:
המידע באתר מבוסס דרופל מתחלק לשני מאגרים עיקריים - 1. הקוד שמאוחסן בספריית הקבצים 2. בסיס הנתונים (database) שגם אותו מצידו אפשר לחלק לתוכן ולהגדרות פונקציונליות.
כשעובדים על אתר פיתוח כשבמקביל מוזן תוכן ומצטרפים משתמשים באתר החי זה מאוד קל לעדכן משהו שהשתנה בקוד, למשל בערכת העיצוב אבל אחת הבעיות הקשות היא איך להעביר שינויים שנעשו בבסיס הנתונים (בהגדרות הפונקציונליות) של אתר הפיתוח אל האתר החי בלי לדרוס את התוכן שהוזן באתר החי.
מה שפיצ'רס עושה זה להוציא המון הגדרות מתוך בסיס הנתונים אל הקוד, כך שניתן בקלות להעביר אותן, ולנהל אחריהן מעקב, כאן נכנסות לתמונה מערכות לניהול גרסאות שיכולות בקלות לסנכרן בין הקוד של כל הגרסאות השונות של האתר שלי, לשחזר שינויים ולתעד כל מה שקרה בקוד שלי.
מוסר השכל : אין קשר ישיר בין השימוש ב features.module והשימוש במנהל גרסאות, ניתן להשתמש בל אחד מהם ללא השני, אבל שניהם עושים את החיים קלים בהרבה וביחד - שבעתיים.
חשוב גם לציין פה לשם הרגעת המפוחדים שגם בשביל שימוש ב features.module וגם בשביל שימוש במנהל גרסאות אין חובה לקרוא שורה אחת של קוד וניתן לנהל הכל דרך ממשקים גראפיים.
צחי שלידור, לינוויט
תשתיות תוכן קהילתיות
Sasson - Smart Drupal Theming
צחי, הסבר מעולה. לגבי
צחי, הסבר מעולה.
לגבי Features - אמרתי שאני משתמש בממשק הגראפי, אבל הוא לא מאפשר לייצא Nodes. רק הגדרות. לכן שאלתי אם מישהו מכיר פתרון אחר.
יש הרבה פתרונות אחרים, כולם
יש הרבה פתרונות אחרים, כולם בקטגוריה הזו : http://drupalmodules.com/module-finder?c=Import+and+export&v=6.x
כמה אפשרויות ששמעתי עליהן אבל מעולם לא ניסיתי :
deploy.module
yamm.module
שים לב שאין להם גרסה יציבה, אז כדאי להיות זהיר איתם.
צחי שלידור, לינוויט
תשתיות תוכן קהילתיות
Sasson - Smart Drupal Theming
חלוקה לוגית ופיזית בין כל
חלוקה לוגית ופיזית בין כל המידע הקיים באתר.
קודם כל תודה לצחי על ההסבר.
אני עכשיו בדיוק בשלב שבו אני מנסה להבין איך באמת לעבוד אם דרופל במובן של מעקב אחר גירסאות.
ממה שהבנתי עד עכשיו, וזה גם מה שאני הולך להכניס לצוות, שכל המידע בדרופל מתחלק לשלושה חלקים מרכזיים:
סיפריות וקבצים - אשר מכילים מודולים וקבצי PHP - ינוהל באופן ישיר ב SVN
קונפיגורציה - של DB ושל מודולים - את כל הקונפיגורציות עדיף להפוך לפקודות SQL אשר את כולם נכניס לקובץ אחד או יותר (סקריפטים) - אשר ינוהלו גם כן באופן ישיר ב SVN
קונטנט של דרופל (כמו views, panels, menu ועוד..) - יכול להיות מנוהל בfeatures מודול ועל ידי כך כל feature הופך ישירות לקובץ אחד - והוא ינוהל יבאופן ישיר ב SVN
זאת אומרת שאפשר לנהל את כל האתר שלכם ב SVN !!!
האמת שעשיתי חיפוש רב על זה, ולא מצאתי מישהו שאומר את מה שאמרתי בצורה כל כך ברורה (נראה לי),
אז אם למישהו יש הערות, אתם מוזמנים לכתוב פה .. אני אשמח :-)
זה בטוח יעזור לכולם בהמשך הפיתוח ..
רוני.