shape_RMS - מקוון בענן

תָכְנִית:

שֵׁם

shape_RMS - מבוא למערכת ניהול הגרסאות shapeTools

תַקצִיר

לעצב rms - הצגת תקציר של פונקציות מערכת ניהול הגרסאות של shapeTools

תיאור

השמיים shapeTools לשחרר ניהול שוטף מערכת (צורת_RMS) עוזר לבנות ולשמור על מעקב
של מהדורות מערכת בפרויקטים מורכבים של פיתוח תוכנה (עם מספר מתכנתים). זה
דף המדריך המבוא נותן סקירה כללית של פונקציונליות shape_RMS ועוזר
תחילת העבודה עם מערכת ניהול הגרסאות. בעת קריאת מבוא זה,
צריך להיות מכיר את יסודות מערכת בקרת הגרסאות של shapeTools ואת ה-
תוכנית ניהול תצורת צורות, או שעליך להשתמש במערכת בקרת הגרסאות של shapeTools
ו לעצב(1) עמודי מדריך בהישג יד. משלים לעמוד מדריך קצר זה,
יש מדריך מבוא לשימוש ב-shapeTools, שמסביר כיצד להציג
ולהשתמש בפונקציונליות של ערכת הכלים של shape בצורה חכמה בפרויקט מרובה מתכנתים.

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

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

כל הפונקציות של shapeTools RMS מבוצעות על ידי לעצב(1) תוכנית. זה
מפרש קובץ תיאור (קובץ Shapefile) ומבצע את הפעולה המשויכת אליו
שם היעד שניתן עם קריאת הצורה. בדרך כלל, ניתן לבצע חבורה של מאקרו
הגדרות יחד עם קריאה לצורה. הגדרות אלו דורסו את ברירת המחדל הפנימית
הגדרות מאקרו. לכן, לקריאות של shape_RMS יש את הצורה הכללית
לעצב יעד [MACRONAME=ערך ...].

בפירוט, shape_RMS מבצע באופן אוטומטי את הפעולות הבאות, שכל אחת מהן היא
מתואר בדף המדריך המצורף.

·
בניית מערכת, התקנה וניקוי (בניית_צורה(1)).

·
יצירת גרסאות קדם-מהדורה של תת-מערכות או של המערכת כולה (שחרור_צורה(1)).

·
יצירת גרסאות של תת-מערכות או של המערכת כולה (שחרור_צורה(1)).

·
בניית תיקונים לגרסאות קיימות (טלאי_צורה(1)).

·
שחזור גרסאות מערכת ישנות (שחרור_צורה(1))

·
יצירת חבילות הניתנות למשלוח (קבצי tar או shar וכו')צורת_זפת(1)).

·
קביעת תלויות קבצים (צורה_תלויה(1)).

בנוסף, הוא מספק

·
כללי בחירת גרסה סטנדרטית (צורת_סטנדרט(7)).

·
רסטר בקרת גרסאות מאוחד לכל הפרויקט (צורה_סטנדרטית(7)).

·
יצירה אוטומטית של זיהויים (לפני)שחרור.

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

·
תבניות עבור קבצי Shapefile ו-Makefile (צורה_טמפל(7)).

השמיים פרויקט מִבְנֶה

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

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

מבנה הפרויקט ומרכיביו מתוארים על ידי מערכת מודל. המערכת
המודל מורכב מאוסף שזור של קבצי Shapefile ו-Makefile. כל צומת הוא
מצויד ב-Makefile אחד וב-Shapefile אחד המכילים מודל מערכת ספציפי לצומת
מידע. מידע נוסף על מודל המערכת (כגון כללי בחירת גרסה סטנדרטיים
או הגדרות גרסאות כלל-פרויקטיות) נשמרות במקום מרכזי כלל-פרויקטי ו
גישה דרך מתקן include של shape.

הפרופיל הפונקציונלי של מודל המערכת משתקף על ידי מאפיינים מוגדרים מראש תֶקֶן מטרות in
קבצי מודל המערכת (Shape- ו-Makefiles). מטרות אלו מוגדרות או ב-
קבצי צורה ו-Makefile בודדים (ספציפיים לצומת) או באחד מקבצי הצורה הכלולים
קטעים שמתוחזקים בקובץ Shapefile ברחבי הפרויקט. סט של תֶקֶן פקודות מאקרו ובמרומז קבוצה
של מוסכמות העומדות בבסיס מאקרו אלה מהוות את ממשק הנתונים בין הגורמים השונים
מודולים של מודל המערכת. תאימות עם המוסכמות הבסיסיות הנדרשות ו
הנחות יסוד מתאפשרות על ידי תבניות עבור קבצי Shape ו-Makefiles המסופקות ל-
מתכנתים של חלקי המערכת השונים (ראה צורה_טמפל(7)). שימוש בתבניות אלו יגרום
מידע על מודל מערכת כתיבה כמעט טריוויאלי.

לפי התבניות, רכיבי Makefile מכילים את רוב הגדרות המאקרו, ה-
הגדרות תלות רכיבים רגילות ורוב כללי הטרנספורמציה המפורשים.
מערכת Makefiles תוכננה בקפידה להיות עצמאית מספיק כדי שניתן יהיה להשתמש בה ללא
לעצב(1). זה הכרחי כדי לספק נוהל בנייה להידור והתקנה
מערכת תוכנה מחוץ לאזור הפיתוח (כאשר לעצב(1) בדרך כלל אינו זמין).

רכיבי ה-Shapefile מכילים מידע הקשור ספציפית לצורות
תכונות מיוחדות שאינן זמינות ב-make (למשל בחירת גרסה, טיפול בווריאציות).
המערכת המלאה של קבצי Shape ו-Makefiles נטולת יתירות, מה שמקל על התפעול שלהם.
תחזוקה. קבצי הצורה, על מנת לייצג מודל מערכת שלם, מכילים include
הנחיות לכלול את כל מידע משמעותי על מודל המערכת המאוחסן במקומות אחרים
אובייקטים, כלומר קבצי include המתוחזקים באופן מרכזי וקבצי Makefile.

עבודת הפיתוח מתרחשת בדרך כלל אצל המפתחים פְּרָטִי מקומות עבודהעם
התוצאות שנאספו במקום מרכזי, הפרויקטים מָקוֹר מאגרהמקור
מאגר הוא עץ ספריות שלם (שלם במובן של שילוב כל אחד מהם)
צומת מערכת מפותח) המייצג את כל הפרויקט. סביבות עבודה פרטיות ו
ספריות המשנה המתאימות במאגר המקור מקושרות זו לזו באמצעות קוד משותף AtFS
תת-ספריות (ראה וי סינטרו(1)) מחזיק את כל תוצאות העבודה השמורות (גרסאות). מנגנון זה
גורם לקבצים מסביבת עבודה פרטית להיות גלויים במאגר המקור, ברגע ש-
מפתח שומר עותק של קובץ באמצעות מערכת בקרת הגרסאות shapeTools.
עבודה עשויה להתרחש גם במאגר המקור. במקרה זה, אפילו הגרסה העמוסה של כל אחד מהם
חומר העבודה גלוי במאגר המקור, שאינו מפריע.

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

לצד סביבות עבודה פרטיות ומאגר מקורות, לפרויקט יש חלקית לשחרר אזור ו
a לשחרר אזורשני האזורים מסוגלים להחזיק עותק מלא של קובץ המקור של הפרויקט.
עץ כקבצי UNIX (ללא בקרת גרסאות). ה חלקית לשחרר אזור מחזיק הכי הרבה
גרסה (קדם-) חדשה של כל צומת מערכת. בכל פעם, צומת מערכת מקבל גרסה מוקדמת או
לאחר שוחרר, עותק של גרסאות המקור המעורבות נכתב לאזור השחרור החלקי.
השמיים לשחרר אזור מכיל קדם-מהדורות ומהדורות של המערכת כולה. הוא מלא רק,
כאשר הליך בניית (קדם-)מהדורה מופעלת מהצומת העליון של המקור
מאגר. תוכלו למצוא פרטים נוספים בנושא זה ב שחרור_צורה(1) דף ידני.

השמיים פיתוח התַהֲלִיך

תהליך הפיתוח הכללי המוטל על ידי מערכת ניהול שחרור הצורות הוא
מתואר על ידי התבנית הבאה.

1)
פיתוח ובדיקה מקומיים בסביבות עבודה פרטיות עם גרסאות מקומיות (להציל)

2)
פרסום מקדים אישי של מערכת צומת יחידה (צומת קדם-הפצה)

3)
אינטגרציה גלובלית ובדיקות אינטגרציה (חלק עליון קדם-הפצה)

4)
שילוב בקשות שינוי מאינטגרציה גלובלית במערכות צומת יחיד ו
פרסום סופי של מערכות צמתים (צומת לשחרר)

5)
שחרור עולמי (חלק עליון לשחרר)

6)
הטמעה מקומית של תיקוני באגים במערכת שפורסמה (צומת תיקון קדם-הפצה).

7)
אינטגרציה גלובלית של תיקונים ובדיקות אינטגרציה (חלק עליון תיקון קדם-הפצה).

8)
מהדורות מקומיות של מהדורות מערכת צמתים מתוקנות (צומת תיקון לשחרר).

9)
יצירת גרסה גלובלית עם תיקון (חלק עליון תיקון לשחרר).

כמובן, ייתכנו מספר לולאות ברשימה הנ"ל. ראשית, בניית צומת
(קדם)הפצות קורה באופן רקורסיבי מעלי עץ המקור של המערכת ועד לראש הדף.
שנית, מספר איטרציות של ה- צומת/עליון קדם-הפצה בדרך כלל יהיה צורך במנגנון,
כדי להגיע לגרסה סופית יציבה.

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

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

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

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

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

הגדרת up a פרויקט

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

רשימת בדיקה להתקנה ראשונית:

A1)
צור משתמש (UNIX) שיהיה פּרוֹיֶקט בעליםזה צריך להיות משתמש קונספטואלי, לא
ספריית הבית של משתמש זה תהיה הטבעית. פּרוֹיֶקט בית.

A2)
הגדר א פּרוֹיֶקט קבוצה (ב / וכו '/ קבוצה) ולהוסיף את כל משתתפי הפרויקט לקבוצה זו.

A3)
הגדר את הפרויקט המרכזי מָקוֹר מאגר בביתו של בעל הפרויקט.

· צור פיתוח בספרייה

· צור אלף, lib ו לכלול ספרייה בספריית פיתוח.

· התקנת עץ מקור המערכת עם src ספרייה בספריית הפיתוח בתור
שורש.

· צור ספרייה בשם AtFS בכל ספרייה של עץ מקור המערכת.

A4)
הגדר אזורי שחרור ושחרור חלקי על ידי יצירת הספריות לשחרר ו
שחרור חלקי בביתו של בעל הפרויקט.

A5)
לעשות את כל ספריות שנוצרו בעבר הניתנות לכתיבה קבוצתית.

A6)
צור ספרייה בשם לעצב ב- development/lib ולהעתיק את התבניות shape_RMS ו-
לכלול קבצים לתיקייה זו.
אלו הם Shapefile.tmpl, Makefile.tmpl, Release.tmpl, release.c.tmpl, stdconf,
stdtargets, stdrules ו-stdvar.

A7)
התאמת ערכי ברירת מחדל של מאקרו ב Makefile.tmpl ו קובץ צורה.tmpl in
development/lib/shape בהתאם להתקנה המקומית. ה- צורה_טמפל(7) עמוד מדריך
נותן לך מידע על הסמנטיקה של כל הגדרת מאקרו. ה-Makefile
תבנית מגדירה

· נתיבי בסיס עבור מאגר המקור, אזור שחרור חלקי, אזור שחרור, ו
מיקומי התקנת המערכת.

· תיאור של סביבת מערכת המארח.

· כלים ואפשרויות כלים לשימוש.

· ספריות לשימוש.

· פעולות ברירת מחדל של בנייה והתקנה.

A8)
בדוק את קובץ ה-stdvar (הגדרות גרסאות כלל-פרויקטיות). ראה צורה_סטנדרטית(7) עבור
מידע נוסף על זה.

אם תידבקו בקפדנות למודל המבנה והשחרור כפי שהוא מיושם בתבניות
ו-shape include קבצים שניתנו בהפצת shapeTools, העבודה שלך הסתיימה כעת.
התאמות נוספות דורשות ביצוע שינויים ידני בקבצים ב-shape/lib.
לפני שתעשו זאת, אנו ממליצים לקרוא תחילה את מדריך shapeTools. במיוחד את
תבנית Makefile עליך להגדיר בזהירות רבה. כמו רוב לעשות(1) יישומים עושים
לא תומך בהכללת רכיבים חיצוניים לתוך Makefiles, Makefiles מקומיים (נגזרים מה-
תבנית) מכילה הרבה מידע שעדיף שיהיה ניתן לשמור אותו באופן מרכזי.
שינויים בתבנית Makefile שבוצעו לאחר שכבר גזרו Makefiles מקומיים
ממנו, דורש תיקון השינויים בכל Makefile מקומי. זהו תהליך יקר ו
עבודה מועדת לטעויות. אנו ממליצים להשתמש תיקון(1) בשביל זה, וזה בהחלט לא מה שאתה
הייתי רוצה, אבל עדיין אין פתרון טוב יותר.

A9)
הגדרת כללי בחירת גרסאות

A10)
ליישם פעולות נוספות ב יעדי תקן or stdconf.

A11)
להגדיר מחדש את המדיניות כלל-פרויקטית ב Makefile.tmpl, קובץ צורה.tmpl, או stdconf.

אל תנסו למצוא תיעוד נוסף שידריך אתכם בנקודות A9-A11. יש
עדיין לא.

רשימת בדיקה למפתחים, בעת התחברות לפרויקט קיים:

D1)
הקפידו להיות חברים בקבוצת הפרויקט

D2)
צור ספריית/י פיתוח פרטית/ים

D3)
התחבר למרכז מָקוֹר מאגר על ידי יצירת קישור בשם AtFS משלך
ספריית פיתוח מקומית לספרייה המתאימה במקור המרכזי
מאגר. זה צריך להיות קישור סמלי לספריית AtFS שם, או, על
מערכות בהן אין אפשרות קישור סמלי זמין, קובץ עם המאפיינים המתאימים
שם הנתיב כתוכן. האחרון יתפרש על ידי בקרת הגרסאות של shapeTools
מערכת כתחליף לקישור סמלי.

D4)
העתק Makefile.tmpl מ-project_home/lib/shape בתור קובץ Makefile להתפתחות שלך
ספרייה ומלא את הגדרות המאקרו הדרושות על ידי עריכת הקובץ. אם אתה
כבר יש לך Makefile, אל תנסה להשתמש בו יותר. יהיה לך הרבה יותר מזל.
עם Makefile שנגזר מהתבנית.

D5)
העתק קובץ צורה.tmpl as קובץ צורה לספריית הפיתוח שלך. בדרך כלל, לא
אמורים להיות שינויים נחוצים שם.

D6)
העתק אחד מ שחרור.tmpl or release.c.tmpl כ-Release, בהתאמה. release.c לקובץ המקומי שלך
במדריך.

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

D8)
הפעלה לעצב rms (1) כדי לקבל תקציר של הפונקציות שמספקים shapeTools
מערכת ניהול שחרור.

פרטטורים

מכיוון שלערכת הכלים לצורות יש מיוחס מערכת קבצים (AtFSראה אפינטרו(3)) כאחסון נתונים
base, shape_RMS מאחסן את מידע הניהול הפנימי שלו כתכונות המצורפות ל-
רכיבי מערכת. מאפיינים מורכבים משם ורשימת ערכים. תצורה
תכונות הקשורות לניהול הן

__שם סמלי__
כל גרסת רכיב במערכת נושאת סט של שמות סמליים ייחודיים
זיהוי ה(קדם)מהדורה(ות) שהיא חלק מהן. רשימה זו עשויה להיות ריקה, כאשר
הגרסה מעולם לא הוכרזה כחלק מ(קדם-)הפצה. __שם סימבולי__ הוא
תכונה בעלת משמעות מיוחדת בכל התוכניות ב-shapeTools. למידע נוסף
מידע ראה את -סִמלִי אופציה של vl(1) ו vadm(1).

שם צומת
הוא שם מערכת הצמתים, אליה שייכת גרסת הרכיב כפי שמוגדר ב-
NODENAME מאקרו בקובץ Makefile של תת-המערכת. רק קובץ מחולל מספרי השחרור
נושא את התכונה הזו.

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

השתמש ב-shape_RMS באופן מקוון באמצעות שירותי onworks.net