הערה
גישה לעמוד זה דורשת אישור. אתה יכול לנסות להיכנס או לשנות תיקיות.
גישה לעמוד זה דורשת אישור. אתה יכול לנסות לשנות מדריכים.
שילוב בקרת מקור מאפשר לצוותי פיתוח לסנכרן פתרונות ואובייקטי פתרונות בסביבת Microsoft Dataverse אחת או יותר באמצעות מאגר Git של Azure DevOps. פונקציונליות השילוב של בקרת המקור זמינה באופן מקורי בתוך חוויות הפתרונות, ומבטיחה שמפתחים ללא הכשרה מוקדמת, מפתחים שמתמקדים בקוד ומנהלי מערכת יוכלו להפיק תועלת מבקרת גירסאות, מעקב אחר שינויים ושיתוף פעולה חלק בצוות בין כלים וסביבות שונים. אינטגרציית Git מיועדת לשימוש עם סביבות מפתחים ולא בסביבות בדיקה או ייצור שבהן ניתן לבצע פריסות באמצעות builds כדי ליצור ארטיפקטים של פתרונות וצינורות לצורך פריסה. Power Platform
במאמר זה, נציג כמה ממושגי המפתח והיתרונות לשימוש בבקרת מקור התומכת ב- Git עם פתרונות וסביבות Dataverse. לקבלת מידע על Git ב-Azure DevOps, עברו אל מאגר Git של Azure DevOps.
ALM ב-Power Platform ו-Dataverse
Power Platform מספק יכולות מוכנות לשימוש רבות המאפשרות לארגונים לבצע ניהול מחזור חיים של יישום (ALM) עבור הפתרונות שלהם. כלולים גם היכולת לארוז פתרונות כמכולות עבור סוגים רבים ושונים של אובייקטים בפלטפורמה, לנהל סביבות המעורבות במחזור חיי האפליקציה ולפרוס פתרונות באמצעות **צינורות** ב- . Power Platform ישנן גם מספר דרכים לשלב מאגרי Git עם Power Platform באמצעות בכלי מפתחים. עם שילוב מקורי של Git ב-Dataverse, התהליך פשוט ויעיל המאפשר ליוצרים לעבוד עם הפתרונות שלהם בדרך מוכרת ולקיים אינטראקציה עם בקרת המקור באמצעות ממשקים פשוטים ב-Power Apps (make.powerapps.com).
הטבות
- בקרת מקור כמקור האמת: בארגונים מסוימים, מקור האמת עבור פריסות ב- Dataverse הוא סביבות היוצרים שבהן נבנים פתרונות. המניע העיקרי לאופן פעולה זה הוא שילוב Git שאינו מקורי המשתמש בטכניקות ובכלים מתקדמים, הדורשים מומחיות IT מקצועית כדי להתחיל בעבודה. עם השילוב המקורי של Git ב-Dataverse, ניתן להפעיל בקרת מקור בכמה שלבים בלבד ולספק ממשק מוכר שבו היוצרים יוכלו לעבוד עם הפתרונות שלהם.
- בטיחות, ביקורת ותאימות באמצעות שיטות עבודה מומלצות של SDLC: שיטות עבודה מומלצות למחזור חיי פיתוח תוכנה (SDLC) הן קבוצה של קווים מנחים ותהליכים המסייעים לכם לנהל את פרוייקטי פיתוח התוכנה ביעילות. על-ידי שימוש בשילוב Git ב-Dataverse, אתם פועלים בהתאם לנוהלי SDLC כגון בקרת גרסאות, סקירות קוד וניתוח קוד מקור סטטי כדי להבטיח את האיכות, המהימנות והאבטחה של הפתרונות שלכם. שילוב Git ב-Dataverse מספק גם תכונות כגון ביקורת, תאימות ועקיבות שעוזרות לכם לעקוב אחר שינויים בפתרונות ולשתף פעולה עם חברי צוות אחרים ביעילות.
- סביבות פיתוח קצרות מועד: על-ידי אחסון עותק של ההתאמות האישיות והתצורות של הסביבות שלכם בבקרת מקור, יש לכם אפשרות לחדש סביבות פיתוח מבקרת המקור במהירות ובקלות ב- Dataverse. כך יש לכם אפשרות ליצור סביבות קצרות מועד למטרות פיתוח ובדיקות. סביבות קצרות מועד מאפשרות לכם לפנות שטח אחסון, להתנסות בתכונות חדשות, לבדוק ולחזור על הפתרונות שלכם בלי להסתמך על סביבות קבועות.
- צוותי פיתוח משולבים: צוותי פיתוח משולבים הם צוותים שמורכבים הן ממפתחים והן מיוצרים שעובדים יחד כדי לבנות פתרונות. באמצעות שילוב Git ב-Dataverse, משתמשים אלה יכולים לבנות באופן עצמאי בסביבות נפרדות ולשתף פעולה עם אחרים על-ידי סינכרון עם מאגר בקרת מקור משותף. שילוב בקרת מקור מאפשר לכם להשתמש בכישורים ובמומחיות של מפתחים ויוצרים כאחד כדי לבנות פתרונות באיכות גבוהה העונים על צרכי הארגון שלכם.
- הגנה: שימוש בבקרת מקור כמקור האמת עבור הפתרונות מאפשר לכם להתאושש משינויים לא מכוונים בפתרונות במהירות ובקלות. על-ידי אחסון הפתרונות בבקרת מקור, תוכלו לשחזר למצב או לגירסה קודמים.
מושגים עיקריים
פתרונות מנוהלים לעומת פתרונות לא מנוהלים
כשאתם משתמשים בשילוב Git עם Dataverse, פתרונות המאוחסנים בבקרת מקור מגיעים מפתרונות לא מנוהלים בסביבה של יצרן. פתרונות לא מנוהלים מאפשרים ליוצרים להוסיף, להסיר ולעדכן אובייקטים שמסונכרנים עם בקרת המקור בעת ביצוע commit ודחיפת שינויים. פתרונות מנוהלים נבנים מבקרת מקור ונפרסים בסביבות במורד הזרם, כגון בדיקה או ייצור, ואינם ניתנים לעריכה בסביבות אלה. פתרונות מנוהלים משמשים כדי להבטיח שמקור האמת עבור הפתרונות שלכם הוא תמיד בקרת מקור וששינויים מתבצעים רק בסביבה של יוצר לפני שהם מתווספים לבקרת המקור ונפרסים במקום אחר.
עיצוב קובץ עבור אובייקטי פתרון
עם הצגת אינטגרציית Git ב- Dataverse, ישנם שינויים באופן שבו פתרונות ואובייקטי פתרון מיוצגים בבקרת המקור. כאשר אתה מבצע commit ו-push של שינויים לבקרת קוד המקור, אובייקטי הפתרון מאוחסנים בפורמט ספציפי התואם ל-Git. פורמט זה משמש לייצוג אובייקטי הפתרון בצורה שקל לקרוא ולהבין, וניתן להשתמש בו כדי לעקוב אחר שינויים באובייקטי הפתרון לאורך זמן. פורמט הקובץ עבור אובייקטי פתרון נועד להיות קריא על ידי בני אדם וניתן להשתמש בו כדי להציג שינויים באובייקטי הפתרון בבקרת המקור. בנוסף, כדי לאפשר אחסון של פתרונות מרובים באותו מאגר ותיקייה, אובייקטי הפתרון בבקרת המקור אינם משוכפלים עוד עבור כל פתרון. במקום זאת, אובייקטי הפתרון מאוחסנים במיקום אחד וניתן לשתף אותם על פני מספר פתרונות באותו מאגר ותיקייה.
פיתוח שמתמקד בקוד עם Git
פיתוח שמתמקד בקוד ב- Power Platform מתאפשר באמצעות כלי פיתוח כמו Power Platform CLI, Visual Studio והרחבות Visual Studio Code. שילוב מפתחים המתמקדים בקוד תחילה בתהליך פיתוח הפתרונות קשה ללא שילוב בקרת מקור, מכיוון שאובייקטים כמו בקרות מסגרת רכיבים ותוספים נפרסים בפתרונות כנכסים ארוזים שנבנו מקוד מקור ואינם ניתנים לעריכה ישירה ב-(make.powerapps.com). Power Apps Dataverse Power Apps ללא בקרת קוד (source control) כחלק מתהליך הפיתוח עבור אובייקטים בעלי קוד נמוך (low-code) ואובייקטים בעלי קוד ראשון (code-first), קשה לנהל שינויים בפתרון ולהבטיח מעקב ופריסת שינויים בצורה מבוקרת.
על-ידי הפעלת שילוב Git ב-Dataverse, תוכלו לפגוש מפתחים המתמקדים בקוד במקום שבו הם עובדים ולספק חוויה חלקה הן למפתחים בתכנות פשוט והן למפתחים המתמקדים בקוד. עם זאת, ישנם כמה שיקולים שכדאי לזכור בעת ניהול אובייקטים המבוססים על קוד (code-first) בסביבה דלת קוד.
פיתוח משולב עם שילוב Git ב-Dataverse
Power Platform מספקת יכולות הן לפיתוח בתכנות פשוט והן לפיתוח שמתמקד בקוד. מאמר זה דן בתהליכי פיתוח קוד-ראשון הקשורים לאינטגרציה עם Dataverse וגיט ומספק הדרכה כיצד לנהל אובייקטים קוד-ראשון וקוד-דל בסביבה אחת. אובייקטים כמו Power Apps בקרות מסגרת רכיבים, Dataverse תוספים ופעילויות זרימת עבודה מותאמות אישית הם דוגמאות לאובייקטים המבוססים על קוד שניתן לנהל בבקרת קוד מקור.
אובייקטים בעלי קוד ראשון וקוד נמוך בסביבה אחת
ניתן לכלול אובייקטים המבוססים על קוד (Code-first) בפתרונות באמצעות תהליך בנייה שיוצר פתרון מנוהל או לא מנוהל שניתן לייבא לסביבה Dataverse . עם זאת, ניתן לפרוס אובייקטים המבוססים על קוד ישירות לתוך פתרון לא מנוהל בסביבת יוצר לאחר בנייתם, מבלי להשתמש בתהליך בניית הפתרון כדי לפרוס אותם. יש לקחת בחשבון את תהליך הבנייה, בהתחשב בגמישות זו.
אם אתם פורסים אובייקטים המבוססים על קוד ישירות לפתרון לא מנוהל בסביבת יוצר, כאשר אובייקטים אלה מחויבים לבקרת מקור, רק הגרסה המקומפלת (נבנית) שלהם מאוחסנת בבקרת מקור. לדוגמה, קובץ ה- DLL הבינארי אם הוא תוסף, או חבילת JavaScript המורחבת והממוטבת עבור פקד Power Apps component framework. כתוצאה מכך, מתקבלים שני עותקים של האובייקט בבקרת המקור - אחד המיוצג על ידי הגרסה הבנויה והשני מיוצג על ידי קוד המקור. אחסון קבצים בינאריים במאגר שלך עלול להוביל לבלבול ולסכסוכים פוטנציאליים אם קוד המקור והגרסה הבנויה אינם מסונכרנים. נוהג זה אינו מומלץ מכיוון שקוד המקור צריך להיות מקור האמת היחיד עבור האובייקט ויש לאחסן עותק יחיד בלבד.
הגישה המומלצת היא לבנות אובייקטים המבוססים על קוד (code-first) כחלק מתהליך בניית פתרון ולייבא את הפתרון הלא מנוהל שנוצר לסביבת היוצר. גישה זו מבטיחה שקוד המקור והגרסה הבנויה נשמרים מסונכרנים ושקוד המקור הוא מקור האמת היחיד עבור האובייקט. עם זאת, גישה זו דורשת שיהיה לכם תהליך בנייה כדי ליצור את הפתרון המנוהל או הלא מנוהל לשימוש בתהליך הייבוא ובתהליך הפריסה. לדוגמה, ניתן ליצור זרימות עבודה של Azure Pipelines או GitHub שיוצרות תוצרים לצריכה על ידי קווי צינור ב-Power Platform ותהליכי סנכרון של Git.