WEBVTT

00:00:00.000 --> 00:00:07.660
נוכנים למד מינוס עשרה ימים של Microsoft 365, Copilot, בינה מלאכותית, Azure והאנשים שמעצבים את עתיד העבודה.

00:00:07.840 --> 00:00:12.320
בינואר הקרוב, M365Con חוזרת, ואנחנו הולכים בגדול.

00:00:12.500 --> 00:00:18.600
הצטרפו אלינו למפגשים חיים, הדגמות מהעולם האמיתי וידע מעשי ממומחי MVP ומומחים בתעשייה מכל העולם.

00:00:18.820 --> 00:00:21.880
בלי מצגות גנריות, בלי מילים חלולות ללא הפסקה.

00:00:22.040 --> 00:00:29.420
אנחנו מתמודדים עם האתגרים האמיתיים, Copilot Studio, סוכני בינה מלאכותית, פבריק, הבטחה, ממשל ואוטומציה.

00:00:29.420 --> 00:00:35.060
בין אם אתם אנשי איט, מפתחים או מובילים עסקיים, יש מפגשים שתוכננו במיוחד עבורכם.

00:00:35.460 --> 00:00:40.340
עם עשרה ימים מלאים, תוכלו לחקור טכנולוגיות רבות ולהתחבר לקהילה גלובלית.

00:00:40.760 --> 00:00:44.740
צפו בשידור חי וקחו תובנות מעשיות בחזרה לארגון שלכם.

00:00:45.000 --> 00:00:49.340
ינואר 2027, עשרה ימים, קהילת מייקרוסופט אחת.

00:00:49.500 --> 00:00:50.920
ההרשמה פתוחה עכשיו.

00:00:53.070 --> 00:00:54.630
הבטיחו את מקומכם היום.

00:00:56.270 --> 00:00:59.370
זה קורה ב-m365con.net.

00:00:59.370 --> 00:01:04.990
הצטרפו עכשיו ב-m365con.net ונתראה בשידור חי בינואר.

00:01:05.110 --> 00:01:08.270
מרגישים לעתים שהפריסות בפאוור פלטפורם הן קופסה שחורה.

00:01:08.470 --> 00:01:13.730
האם אתם משחררים עדכון, עוצרים את הנשימה ומקווים שזה יעבוד בסביבות הפיתוח, הבדיקות והייצור?

00:01:13.910 --> 00:01:21.310
מה אם הייתם יכולים לשלוט ולראות כל שלב בתהליך העולם שלכם באמצעות GitHub Actions ללא ניחושים או תלאים ידניים?

00:01:21.310 --> 00:01:28.330
בואו נרים את המסך על האופן שבו כל רכיב, בקרת מקור, אוטומציה ומשתנים מאובטחים באמת מתחברים.

00:01:28.650 --> 00:01:30.090
זה לא עוד סתם מדריך מעבר.

00:01:30.330 --> 00:01:34.990
זה הלמה שרוב המדריכים משמיטים כדי שהפריסה הבאה שלכם לא תשאיר אתכם מנחשים.

00:01:35.190 --> 00:01:38.250
אז למה העולם של Power Platform מרגיש כמו מבוך?

00:01:38.410 --> 00:01:45.930
אם אי פעם ניסיתם לפרוס Power App והרגשתם את חוסר הוודאות הזוחל הזה, כאילו משהו חשוב בטח חמק מבין האצבעות, אתם לא לבד.

00:01:45.930 --> 00:01:53.310
על הנייר, Power Platform מבטיחה פיתוח אפליקציות קל, אבל מאחורי החזית הידידותית הזו, העולם הוא כל דבר חוץ מפשוט.

00:01:53.430 --> 00:01:59.690
אפליקציית ווב נפרסת מבקורת מקור, נבנית בצינור פיתוח ונוחתת בייצור עם התנהגות צפויה.

00:01:59.850 --> 00:02:08.090
Power Platform, לעומת זאת, מכביעה חצי מהלוגיקה בתוך ממשקי גרירה ושחרור, מסקי מחברים ונוסחאות שלא ניתן לראות באף מאגר גי.

00:02:08.090 --> 00:02:17.150
אז, גם אם תעקבו אחרי כל שלב במדריכי הניהול ברמה הגבוהה האלה, עדיין תיתקלו בתקלות מוזרות וקשות להבחון ברגע שאפליקציות קריטיות לעסק עוזבות את הפיתוח.

00:02:17.370 --> 00:02:19.910
בואו נסתכל על מדריכי העולם שמסתובבים בחוץ.

00:02:20.090 --> 00:02:24.170
רובם יובילו אתכם בייצור של קובץ זיפ של פתרון ואיבוש שלו למקום אחר.

00:02:24.330 --> 00:02:27.510
פשוט מספיק, נכון, אבל האיך הוא רק שכבה אחת.

00:02:27.690 --> 00:02:29.330
מה שהם מדלגים עליו זה הלמה.

00:02:29.330 --> 00:02:34.010
למה פריסה של Power Platform נשברת בדרכים שקוד רגיל לעולם לא נשבר בהן.

00:02:34.010 --> 00:02:35.850
זה מה שגורם לבלבול אין סופי.

00:02:36.170 --> 00:02:41.650
שורש הבעיה הוא שלוגיקה, חיבורים והגדרות בפאור אפס לא נשמרים כמו קוד קלאסי.

00:02:42.250 --> 00:02:45.250
אתה לא רק משכפל מאגר וצופה בבדיקות היחידה.

00:02:45.370 --> 00:02:54.350
אז כשאתה מנסה להעביר את האפליקציה שלך, כל התעלויות הנסתרות האלו, חיבורים לאטלוק, לשארפוינט או לאפי איי מותאמים אישית לא תמיד עוברים בצורה מסודרת בתוך קובץ הזיפ.

00:02:54.350 --> 00:02:55.270
הנה התרחיש.

00:02:55.470 --> 00:02:58.310
יש לך אפליקציה חדשה ונוצצת שעובדת בסביבת הפיתוח.

00:02:58.310 --> 00:03:01.870
אתה מייצא פתרון, מייבא לבדיקות ופתאום התהליך מפסיק לעבוד.

00:03:02.050 --> 00:03:03.930
זו לעיתים רחוקות רק בעיה בקובץ.

00:03:04.110 --> 00:03:11.850
במקום זאת, חיבורים מצביעים למקום הלא נכון, הרשאות לא תואמות ומדיניות נתונים חוסמת חיבורים שנראו בסדר גמור לפני רגע.

00:03:11.850 --> 00:03:21.410
עכשיו, דמיין לעשות זאת על פני שלוש סביבות, פיתוח, בדיקות וייצור, כשכל אחת משתמשת בחיבורים, מדיניות הגנת נתונים, מאשרים ושומרי סף שונים.

00:03:21.610 --> 00:03:24.030
אתה לא יכול לצאת מזה בעזרת העתק הדבק.

00:03:24.030 --> 00:03:27.750
המחקר מגבה את מה שמנהלי מערכות ומפתחים רואים מדי שבוע.

00:03:27.950 --> 00:03:34.170
רוב הקשלים בפריסות Power Platform נובעים מהפניות חסרות למחברים או מניהול שגוי של משתני סביבה.

00:03:34.170 --> 00:03:40.190
הפנייה חסרה למחבר פשוט אומרת שהתהליך לא מוצא את חיבור האטלוק או הדטאברס שלו.

00:03:40.310 --> 00:03:46.850
אז, ברגע שאתה מנסה להריץ את האפליקציה או התהליך בסביבה אחרת, אתה מקבל שגיאות זמן ריצה.

00:03:46.850 --> 00:03:55.350
ומכיוון שמשתני סביבה עובדים אחרת בפאוור פלטפורם בהשוואה למוצרי מייקרוסופט 365 אחרים, הם מפילים גם מפתחים מנוסים.

00:03:55.530 --> 00:03:59.950
משתנים אמורים לטפל בנקודות קצה, מפתחות או הגדרות ספציפיות לדייר.

00:04:00.090 --> 00:04:06.430
אבל, אם מישהו שוכח להדכן אותם לאחר ייצוא פתרון, אפילו שינוי שנראה תמים עלול לשבור אפליקציה חיה.

00:04:06.650 --> 00:04:09.050
רבים מאיתנו נופלים לאותו מלכודת בהתחלה.

00:04:09.050 --> 00:04:14.610
אולי תחשוב שייצוא פתרון בזיפ אורז את כל מה שצריך, אבל הוא למעשה מדלג על הפניות דינמיות למחברים.

00:04:14.830 --> 00:04:19.870
לדוגמה, נניח שיש לך אפליקציה שמשתמשת במחבר HTTP עבור שירות צד שלישי בסביבת פיתוח.

00:04:20.050 --> 00:04:24.010
כשאתה מייבא לבדיקות או לייצור, אותו מופע של מחבר לא יהיה קיים.

00:04:24.450 --> 00:04:28.030
הפניית המחבר בתוך האפליקציה מצביעה על אובייקט חסר,

00:04:28.290 --> 00:04:34.250
ותהליכים בתוך הפתרון נשברים בשקט עד שמשתמש או מנהל יוצר וממפה מחדש חיבורים ידני.

00:04:34.250 --> 00:04:40.790
אם יש לך יותר מיוצר או מנהל אחד, קל עוד יותר לאבד מעקב איזו הפנייה שייכת לאן,

00:04:41.050 --> 00:04:44.010
ואף אחד לא רוצה את ניתוח הזה עבד בפיתוח הזה.

00:04:44.270 --> 00:04:47.370
סיבוך נוסף, מנהלי שירות, Service Principles.

00:04:47.550 --> 00:04:53.250
רוב האנשים מתחילים להשתמש בחשבונות משתמש כדי לייצא ולייבא פתרונות כי זה מהיר יותר להתחלה.

00:04:53.410 --> 00:04:57.030
אבל כשאתה מנסה להפוך את זה לאוטומטי עם GitHub Actions או כל מערכת C,

00:04:57.310 --> 00:05:00.030
שימוש בפרטי התחברות של אדם מוביל במהירות למבואי סתום.

00:05:00.030 --> 00:05:04.050
אתה תתקל בקירות של הרשאות, לפעמים ללא הודעות שגיאה ברורות,

00:05:04.230 --> 00:05:10.170
או אפילו תפעיל ביקורות ציות כי אתה מריץ פריסות קריטיות תחת חשבון אישי במקום משהו שמיועד לאוטומציה.

00:05:10.570 --> 00:05:14.870
Service Principles, שהם למעשה זהויות אפליקציה שנוצרו ב-Azure AD,

00:05:15.210 --> 00:05:19.030
מטפלים בכל ההרשאות, הרישום והביקורת שהצינור שלך הצריך.

00:05:19.210 --> 00:05:23.690
בלעדיהם, שרשרת האוטומציה שלך הופכת לתלאים של העברות מיד ליד,

00:05:23.950 --> 00:05:25.350
ולעולם לא תדע משינה מה.

00:05:25.350 --> 00:05:28.110
גם בקרת המקור הופכת לסימן שאלה גדול.

00:05:28.270 --> 00:05:31.850
בקוד רגיל, יש לך היסטוריה תקומית וכלי מעקב אחר שינויים.

00:05:32.030 --> 00:05:35.110
קבצי פתרון של Power Platform מייצגים רק תמונות מצב,

00:05:35.330 --> 00:05:37.390
מה שאומר שחסר לך מעקב שינויים מפורט.

00:05:37.570 --> 00:05:40.630
לוגיקה שחבויה בנוסחאות מסך של אפליקציית קנבס,

00:05:40.850 --> 00:05:44.010
או בזרימות עבודה עם טיעוד דל, לא גלויה עד שתייצא שוב.

00:05:44.170 --> 00:05:46.450
מי שהוא משנה הגדרת זרימה בממשק המשתמש,

00:05:46.450 --> 00:05:49.950
ובהצלחה אם לנסות להבין למה סביבות המשך מתנהגות פתאום אחרת.

00:05:50.110 --> 00:05:54.210
התוצאה הסופית היא שניהול אום עבור Power Platform מרגיש כמו פתרון פאזל

00:05:54.210 --> 00:05:57.590
כשחצי מהחלקים חסרים, או לפחות מוסתרים מתחת לקופסה.

00:05:57.690 --> 00:05:58.890
תלויות בלתי נראות,

00:05:59.090 --> 00:06:02.710
מחברים ספציפיים לסביבה ומשתנים שלא ניתן לראות בקוד,

00:06:03.030 --> 00:06:05.930
כולם משבשים את זרימת העבודה הרגילה של המפתח.

00:06:05.930 --> 00:06:11.910
וזה עוד לפני שמתמודדים עם העובדה שבסביבות ייצור יש כמעט תמיד הרשאות מחמירות יותר,

00:06:12.250 --> 00:06:16.510
מדיניות נתונים שונה ודרישות ביקורת שלא בולטות בפיתוח או בבדיקות.

00:06:16.930 --> 00:06:18.430
אבל הנה הצד החיובי.

00:06:18.550 --> 00:06:20.370
המורכבות הזו אינה מקרית.

00:06:20.750 --> 00:06:24.250
יש סיבה מעשית לכך שPower Platform מטפלת במקור,

00:06:24.490 --> 00:06:27.050
במשתנים ובמחברים בצורה כל כך ייחודית.

00:06:27.430 --> 00:06:32.010
היא מנסה לאפשר למשתמשים עסקיים לבנות אפליקציות עוצמתיות בלי לדאוג לקוד.

00:06:32.010 --> 00:06:34.050
עמם, תופעת הלוואי היא שאתה,

00:06:34.050 --> 00:06:38.730
כאדם שמגדיר את האוטומציה, צריך לעקוב אחר מה שמסתתר מתחת למכסי המנוע.

00:06:38.890 --> 00:06:41.610
אם תדע איפה עוברים החוטים הבלתי נראים האלה,

00:06:41.850 --> 00:06:46.470
תוכל לתקן או להימנע מרוב המוקשים שמשבשים את האולם בפאוור פלטפורם.

00:06:46.630 --> 00:06:49.970
עכשיו, אם כל זה נשמע כמו הרבה להטותים, אתה לא טועה.

00:06:50.050 --> 00:06:53.890
אבל יש ארבעה עמודי תווך של אום שעוזרים באמת לעשות סדר בבלגן הזה.

00:06:54.030 --> 00:06:56.050
מקור, בנייה, בדיקה ופריסה.

00:06:56.050 --> 00:06:59.090
לכל אחד מהם יש את המוזרויות שלו בפאוור פלטפורם,

00:06:59.090 --> 00:07:02.030
אבל יחד הם מחזירים מבנה למה שמרגיש אחרת כמו קאוס.

00:07:02.230 --> 00:07:05.670
מערכת האולם המרכזית, מקור, בנייה, בדיקה, פריסה.

00:07:05.790 --> 00:07:10.010
בכל פעם שמישהו מבקש צינור עבודה של פאוור פלטפורם שפשוט עובד,

00:07:10.250 --> 00:07:13.290
הדבר הראשון שעולה לראש הם ארבעת עמודי האולם האלה,

00:07:13.470 --> 00:07:15.390
מקור, בנייה, בדיקה, פריסה.

00:07:15.530 --> 00:07:18.990
בעולם הפיתוח המסורתי, היית יכול כמעט להריץ אותם מתוך שינה.

00:07:18.990 --> 00:07:21.630
פאוור פלטפורם לא עושה לך חיים קלים כאלה.

00:07:21.630 --> 00:07:23.750
פתאום, מקור לא אומר קוד.

00:07:24.110 --> 00:07:26.130
זה אומר להיאבק עם קבצי פתרון,

00:07:26.390 --> 00:07:29.050
לייצא חבילות מחובצות עמוסות באפליקציות,

00:07:29.250 --> 00:07:29.970
זרימות עבודה,

00:07:30.290 --> 00:07:33.070
ולפעמים מחברים שמתחזים להיות חלק מהמקור.

00:07:33.390 --> 00:07:34.490
בואו נתחיל מהבסיס,

00:07:34.710 --> 00:07:38.050
ואז ננתח מה הופך כל עמוד תווך לקצת מוזר בעולם הזה.

00:07:38.250 --> 00:07:40.350
יש לך את קובץ הזיפ של הפתרון שלך.

00:07:40.510 --> 00:07:41.990
זה לא קוד במובן הרגיל שלו.

00:07:41.990 --> 00:07:45.030
פיתחו את הקובץ ותפגשו קבצי XML וJSON,

00:07:45.030 --> 00:07:48.450
לא את הלוגיקה שהייתם מצפים לראות בטייפסקריפט או ב-CASH,

00:07:48.630 --> 00:07:50.890
אבל זהו המקור של פאוור פלטפורם.

00:07:51.050 --> 00:07:52.870
צוותים נופלים כאן לעיתים קרובות.

00:07:53.070 --> 00:07:55.490
זה נראה נייד עד שמבינים שרוב השינויים,

00:07:55.810 --> 00:07:58.650
כמו עדכון נוסחה במסך או כבנון לוגיקה של זרימה,

00:07:58.970 --> 00:08:01.070
אינם ניכרים עד שמייצאים קובץ פתרון,

00:08:01.250 --> 00:08:01.470
זיפ,

00:08:01.650 --> 00:08:02.090
חדש.

00:08:02.250 --> 00:08:05.370
אז כן, אפשר לנהל גרסאות לקבצי הפתרון האלה בג'ית,

00:08:05.370 --> 00:08:08.370
אבל אלא אם מקפידים לייצא אחרי כל עריכה רלוונטית,

00:08:08.370 --> 00:08:10.590
בהיסטוריה שלכם יהיו פערים משמעותיים.

00:08:10.770 --> 00:08:12.030
עכשיו מגיעה ההגדרה.

00:08:12.230 --> 00:08:13.370
באפליקציות רגילות,

00:08:13.590 --> 00:08:17.110
אולי תשמרו מחרוזות חיבור בקובץ קונפיגורציה ותסיימו עם זה.

00:08:17.290 --> 00:08:21.410
פאוור פלטפורם מבריחה נתונים ספציפיים לסביבה בתוך הפתרונות האלה.

00:08:21.530 --> 00:08:23.050
אלו לא רק משתני סביבה,

00:08:23.250 --> 00:08:24.450
אלא הפניות למחברים,

00:08:24.730 --> 00:08:26.010
נקודות קצי דינמיות,

00:08:26.290 --> 00:08:29.370
תפקידים והרשאות ערוזים יחד עם הלוגיקה העסקית.

00:08:29.670 --> 00:08:33.430
אם לא תעדכנו אותם לפני הייצוא מפיתוח או בדיקות,

00:08:33.430 --> 00:08:35.810
אתם נועלים מצביעים למקום הלא נכון.

00:08:36.210 --> 00:08:39.510
ראיתי צוותים ששומרים בעדיקות את קבצי הזיפ של הפתרון,

00:08:39.770 --> 00:08:45.890
רק כדי לגלות אחרי הפרסה שחצי מהאפליקציה עדיין מדברת עם הדטאברס של הפיתוח במקום עם הייצור,

00:08:45.990 --> 00:08:47.930
כי אף אחד לא מפעם מחדש את החיבורים.

00:08:48.070 --> 00:08:49.750
אחר כך יש לנו את ה-ביילד.

00:08:49.930 --> 00:08:55.770
המילה בילד מעלה בדרך כלל תמונות של הידור קוד וצפייה בסימוני ויירוקים בתהליך C.

00:08:55.950 --> 00:08:59.770
בפאוור פלטפורם, תהליך ה-ביילד עוסק בהכסון חבילות הזיפ,

00:08:59.770 --> 00:09:02.190
בדיקה כפולה של הסכימה ואימות פלויות.

00:09:02.310 --> 00:09:03.930
בפייפליין של GitHub Actions,

00:09:04.130 --> 00:09:06.650
משימת בילד לוקחת את קובץ הפתרון ששמרתם,

00:09:06.850 --> 00:09:09.810
ואז משתמשת ב-CLI של Power Platform כדי לפרוק,

00:09:09.990 --> 00:09:11.670
לאמת ולהירוז מחדש את הפתרון.

00:09:11.890 --> 00:09:14.810
שלב האימות הוא המקום שבו מתרחש הקסם או הקאוס.

00:09:14.810 --> 00:09:17.970
הוא עשוי לזהות הפניות שבורות או פעולות שאינן נתמחות.

00:09:18.110 --> 00:09:23.590
גרוע מכך, אם שינוי בזרימה שלכם יסתמך על מחבר מותאם אישית שלא הגיע לבקרת המקור,

00:09:23.590 --> 00:09:26.310
הביילד שלכם יערוז בשקט משהו לא שלם.

00:09:26.470 --> 00:09:28.250
כאן העניינים הופכים למסובכים.

00:09:28.870 --> 00:09:35.210
עבודות הביילד האלה עוסקות פחות בהידור ויותר בתזמור ייצוא אמין ובדיקה שמה שבפנים ניתן להפצה.

00:09:35.630 --> 00:09:40.810
צוותים שמדלגים על זה או ממהרים מגיעים מהר מאוד למצבים שבהם הביילד מצליח טכנית,

00:09:41.050 --> 00:09:44.750
אבל מה שמגיע ל-UAT או ליצור חסר חצי מהתכונות המיועדות לו.

00:09:44.890 --> 00:09:48.810
מייקרוסופט ממשיכה להפיץ את המסר שכבצי פתרון הופכים את העולם לנייד,

00:09:48.810 --> 00:09:50.370
אבל תמיד יש הערת שוליים.

00:09:50.530 --> 00:09:54.970
הניידות תלויה במיפוי תקין של מחברים ובהגדרת תפקידים בכל הסביבות.

00:09:55.170 --> 00:09:56.790
בדיקות הן הכפתור הבא במקור.

00:09:56.990 --> 00:10:02.330
בפייפליין של אפליקציית ווב, בדיקות אוטומטיות עשויות להריץ בדיקות יחידה או בדיקות ממשק משתמש.

00:10:02.490 --> 00:10:06.250
עבור Power Platform, השאלה מה נחשב לבדיקה נתונה לוויכוח.

00:10:06.430 --> 00:10:11.810
לפעמים זה אימות פתרון, במילים אחרות, האם הפתרון נפתח והאם תלויות מפתח נפטרות.

00:10:11.810 --> 00:10:17.910
פעמים אחרות זה הרצת זרימות בדיקה או בדיקה שהמחברים מגיבים בסביבת בדיקות.

00:10:18.210 --> 00:10:25.190
פעמים רבות הבדיקות הן ידניות, כיוון שאימות לוגיקה עסקית בתוך אפליקציית קנבס עדיין לא מחובר לצינורות עבודה אוטומטיים.

00:10:25.350 --> 00:10:33.590
אבל אפשר להפוך בדיקות לאוטומטיות כדי לזהות מחברים חסרים, לעמת זרימות קריטיות או אפילו לבצע פינג לסביבת בדיקות רק כדי לוודא שההרשאות עובדות.

00:10:33.690 --> 00:10:35.990
הפריסה היא השלב שבו הכאב הופך לממשי.

00:10:35.990 --> 00:10:39.950
כשפורסים אפליקציה סטנדרטית, אולי פשוט תדחפו ארטיפקט ווב לאזר.

00:10:40.090 --> 00:10:49.810
בפאור פלטפורם אתם צריכים למפות חיבורים, להקצות הרשאות, להדכן סודות, להחליף משתני סביבה ולבסוף להפעיל ייבו באמצעות סרוויס פרינסיפל לעולם לא עם חשבון רגיל.

00:10:50.010 --> 00:10:52.730
אחרת, תיתקעו עם ביקורות וסירובי הרשאה.

00:10:53.190 --> 00:11:00.010
גיטהאב אקשונס יכול לחבר את התהליך הזה, אבל רק אם כל משימה יודעת לאיזו סביבה להתמקד ובאילו סודות להשתמש.

00:11:00.010 --> 00:11:10.510
ראיתי צוותים מנסים לקצר דרכים על ידי שימוש בסט הרשאות יחיד עבור פיתוח וייצור, מה שמהווה מתכון לתו ובוהו, דליפות מידע, שגיאות הרשאה ותכונות שבורות שמופיעות רק בסביבה אחת.

00:11:10.630 --> 00:11:13.590
קחו צוות מהעולם האמיתי שעבדתי איתו לפני כמה חודשים.

00:11:13.790 --> 00:11:18.450
הם עשו את רוב הדברים נכון, מאגרי גיט סטנדרטיים, קבצי סולושון בגרסאות וענפי עבודה ברורים.

00:11:18.570 --> 00:11:21.010
אבל הצינור שלהם תמיד נשבר בשלב הפריסה.

00:11:21.010 --> 00:11:26.750
למה? הם מעולם לא תרחו להחליף משתני סביבה או לעדכן הפניות למחברים לפני העיבו לסביבת הייצור.

00:11:26.970 --> 00:11:31.670
זה השאיר זרימות מפתח מצביעות על נקודות קצה שגויות עם מידע שזולג למערכות הלא נכונות.

00:11:31.850 --> 00:11:37.990
הפתרון? שלבים מתוסרטים בצינור הג'יפאב שלהם שהחליפו משתנים ומיפו מחדש כל מחבר בעת העיבו.

00:11:38.130 --> 00:11:40.770
ההנחיות של מייקרוסופט עצמה בעניין הזה בוטות.

00:11:40.770 --> 00:11:48.010
השתמשו בגבצי סולושון להעברת דברים בין סביבות, אך תמיד טפלו בהפניות למחברים ובמיפוי תפקידים כחלק מהצינור שלכם.

00:11:48.150 --> 00:11:54.490
הם מציינים שדילוג על השלבים האלה הוא הדרך מספר אחת לשבור אפליקציות, במיוחד ככל שהסביבות הופכות למאובטחות וסגורות יותר.

00:11:54.710 --> 00:12:00.690
ברגע שמתייחסים למקור, לבנייה, לבדיקה ולפריסה כאל חלקים נעים מחוברים ולא רק כשלבים מבודדים,

00:12:00.690 --> 00:12:06.450
קל יותר לראות מדוע כל כך הרבה ניסיונות אום נכשלים ואיך אפשר באמת לפתור בעיות במקום רק לקוות לטוב.

00:12:07.070 --> 00:12:17.270
בהמשך, נצלול לאיך GitHub Actions מתאם את הריקוד הזה, טריגרים, ענפי עבודה והפרדת משימות ששומרים על אוטומציית הפאור פלטפורם שלכם גם גמישה וגם מאובטחת.

00:12:17.390 --> 00:12:20.790
GitHub Actions מחברים את הנקודות עם טריגרים ומשימות.

00:12:20.950 --> 00:12:28.810
אם חיכיתם שצינור GitHub Actions יסתיים אחרי עדכון הפאור אפ שלכם, אתם כבר יודעים שאוטומציה לא אומרת מידית ובוודאי לא אומרת קסם.

00:12:28.810 --> 00:12:34.070
רוב הצוותים פוגעים בקיר הזה מיד אחרי ההתרגשות שבראיית הרצת הוורקפלו הראשונה שלהם.

00:12:34.190 --> 00:12:41.190
אתם מגדירים סקריפט, מחברים אותו למאגר שלכם ומצפים שכל קומית חדש יפרוס בצורה נקייה בכל הסביבות.

00:12:41.410 --> 00:12:43.310
ואז המציאות תופחת על הפנים.

00:12:43.550 --> 00:12:50.830
במקום רק להפעיל סקריפט, GitHub Actions משתמש בשרשרת לוגית הבנויה סביב טריגרים, משימות ומעברים בין סביבות.

00:12:51.010 --> 00:12:56.510
הסדר והמבנה הזה הם שמונעים מהפריסות להפוך לסווח של שלבים שנכשלו שגיעות מוזרות.

00:12:56.510 --> 00:12:59.350
נקודת ההתחלה במערכת הזו היא הטריגר.

00:12:59.510 --> 00:13:07.930
רוב המשתמשים החדשים יוצרים תהליך עבודה שמופעל בכל דחיפה, פוש, או בכל פעם שבקשת משיכה, פול ריקווסט, מגיעה לענף הראשי.

00:13:08.030 --> 00:13:10.290
על פניו זה נראה כמו השיטה הטובה ביותר.

00:13:10.410 --> 00:13:12.790
למה לא להריץ את הפייפליין בכל פעם שהעבודה משתנה?

00:13:12.910 --> 00:13:13.830
כאן תמון הקץ.

00:13:14.010 --> 00:13:17.250
כשמגדירים טריגר רק על המן, הכל מנותב דרך מסלול אחד בלבד.

00:13:17.390 --> 00:13:19.250
מה אם שינויים צריכים להגיע לסביבת הפיתוח?

00:13:19.250 --> 00:13:20.930
דב, אבל לא לבדיקות או לייצור.

00:13:21.070 --> 00:13:24.530
מה אם אתם מוכנים לדחוף לייצור, אבל הבדיקות עדיין מריצות עימות?

00:13:24.650 --> 00:13:32.030
צוותים שנצמדים לטריגרים אחידים לכל מצב נוטים להתעכל בבעיות שבהן פיצ'רים המיועדים לסביבות פיתוח זולגים לייצור,

00:13:32.330 --> 00:13:34.950
או שפריסות בדיקה דורסות פתאום הגדרות ייצור.

00:13:35.310 --> 00:13:42.090
ניתן לפצל תהליכי עבודה לכל סביבה פיתוח, בדיקות וייצור, ולהגדיר טריגרים ספציפיים מאוד לכל אחת.

00:13:42.090 --> 00:13:50.210
למשל, הגדירו תהליך עבודה שרץ רק על דחיפות לענף פיתוח, או הפעילו תהליך שונה כשמישהו מבצע מזוג לענף הייצור.

00:13:50.390 --> 00:13:54.950
גישה זו נותנת יותר שליטה ויוצרת גדר ברורה בין עבודה בתהליך לבין שינויים פעילים,

00:13:55.210 --> 00:13:59.010
אך צוותים רבים לעולם לא בוחנים מחדש את הטריגרים שלהם לאחר שיצרו אותם.

00:13:59.230 --> 00:14:05.210
כך סודות מסביבה אחת יכולים לחמוק לאחרת, והגדרות שמיועדות לפיתוח מגיעות לייצור בטעות.

00:14:05.210 --> 00:14:10.610
צוות אחד שעבדתי איתו ניסה להריץ את כל תהליך העולם שלהם מתוך תהליך עבודה יחיד.

00:14:10.750 --> 00:14:18.050
לזמן מה זה נראה בסדר, עד שמישהו שם לב שמחרוז את החיבור של מסד הנתונים של הייצור הופיע בסביבת הפיתוח.

00:14:18.230 --> 00:14:24.890
הם לא הבינו שהסודות שלהם משותפים בין המשימות, וברגע שהקוד עבר בין סביבות, אותם סודות דלפו יחד איתו.

00:14:25.050 --> 00:14:26.830
זו לא הייתה קריסה או שגיאה ברורה.

00:14:26.830 --> 00:14:35.070
זה היה שקט, סוג כזה של דליפת נתונים נפוץ יותר ממה שחושבים, במיוחד אם לא מגדירים את תהליכי העבודה להפרדה בין סודות למשתני סביבה.

00:14:35.190 --> 00:14:39.850
כל משימה בתהליך העבודה של GitHub Actions מטפלת בחלק ברור של התהליך.

00:14:40.330 --> 00:14:51.690
משימה אחת עשויה לטפל בייצור הפתרון מסביבת המקור, בעוד משימה אחרת דואגת לאימות, פריקה, שריקת מטאדאטה, בדיקת כל התעלויות ובידוש שקיימות הפניות למחברים.

00:14:51.690 --> 00:14:58.630
לאחר מכן מגיעה המשימה שמכינה את משתני הסביבה הספציפיים ומתאימה את הפתרון לסביבת היעד.

00:14:58.810 --> 00:15:05.150
המשימה האחרונה מפעילה את תהליך העיבור באמצעות הרשאות שירות, Service Principles, כדי לכתוב את השינויים לסביבה הנכונה.

00:15:05.150 --> 00:15:11.990
אולי תחשבו על משתני סביבה וסודות כעל מקומות שמירה בסיסיים, אבל בפועל הם הדבק שמחזיק את הכל יחד.

00:15:11.990 --> 00:15:20.010
מחרוזות חיבור, מפתחות API וסיסמאות משותפות צריכים לעבור בין משימות, אך אסור להם לדלוף אל מחוץ לגבולותיהם.

00:15:20.010 --> 00:15:29.250
בפאור פלטפורם אום ייתכן שתזדקק לחיבור Dataverse שונה לכל סביבה או להחליף נקודות קצה בהתאם לזרימת העבודה או לאפליקציה שאתה מפעיל.

00:15:29.610 --> 00:15:36.710
אם תשתמש מחדש במשתנים או תטמיע סודות בקוד, תסיים עם צינור עבודה שברירי או גרוע מכך עם סיכוני הבטחה משמעותיים.

00:15:36.710 --> 00:15:44.410
תהליך היבוא מסתמך על משיכת סודות אך ורק מהכספת הנכונה כדי שסביבת הייצור לא תחשף עקב תקלות בסביבת הפיתוח או הבדיקות.

00:15:44.530 --> 00:15:53.110
מודל מנטלי טוב לסודות בג'פאב אקשונס הוא לדמיין שלכל סביבה יש כספת דיגיטלית משלה, תיבה נעולה שרק המשימות המתאימות יכולות לראות.

00:15:53.270 --> 00:15:55.710
גיטהאב מספקת לך בקרות מדויקות.

00:15:55.710 --> 00:16:02.150
ניתן להגדיר סודות לפי סביבות, כך שמשימה שרצה בפיתוח לא תוכל לגשת לאישורי הייצור ולהפך.

00:16:02.150 --> 00:16:09.770
הגדר את הכספות הללו, וגם אם מישהו שמכוון את הצינור מנסה משהו מסוכן, כללי הגנת הסביבה ימנעו מהטעות לחצות גבולות.

00:16:09.970 --> 00:16:13.730
התיעוד של מייקרוסופט ושל גיטהאב מדגיש את הנקודה הזו שוב ושוב.

00:16:13.930 --> 00:16:20.210
הם ממליצים על כללי הגנת סביבה ותיחום סודות קפדני כדי לעצור דליפות בין סביבות עוד לפני שהן מתחילות.

00:16:20.210 --> 00:16:25.010
ללא הגנה מהסוג הזה, גם זרימות עבודה מתוכננות היטב של אום עלולות להתפרק.

00:16:25.010 --> 00:16:32.730
דמיין זרימת עבודה שמבצעת פריסה לייצור בזמן שהיא עדיין מחזיקה מחרוז את חיבור של פיתוח או סביבת בדיקות עם גישה פתאומית לנתוני ייצור.

00:16:32.930 --> 00:16:34.890
זה לא תמיד גורם לנזק נראה לעין.

00:16:35.090 --> 00:16:40.870
לפעמים זה רק אומר שדגלי תאימות מופעלים או שהלוגים מתמלאים בשגיאות דקות שמצטברות לאט לבעיות גדולות יותר.

00:16:40.870 --> 00:16:45.030
זו הסיבה שזרימות עבודה מסועפות ותיחום סודות הם לא רק נוסעים למתקדמים.

00:16:45.210 --> 00:16:48.770
הם רשת הביטחון שמונעת מהאוטומציה שלך להתפרק בשקט.

00:16:48.770 --> 00:16:53.910
יש ערך גם בפיצול זרימות עבודה לא רק לפי סביבה אלא גם לפי תחומי אחריות.

00:16:54.390 --> 00:16:59.450
קוד שמייצא ומאמת פתרונות לא אמור אפילו לדעת איך לבצע פריסה או להחליף סודות.

00:16:59.450 --> 00:17:08.190
אם כל משימה מטפלת בחלק אחד מהפאזל, קל הרבה יותר לזהות היכן דברים משתבשים, לבצע שחזור ולבקר שינויים בדיעבד.

00:17:08.370 --> 00:17:16.110
סודות נשארים בכספות שלהם, משימות עוקבות אחר הרשאות מתוחמות היטב ווכשלים בצינור מצביעים ישירות על החלק שצריך תיקון.

00:17:16.110 --> 00:17:24.010
הבנת האופן שבו GitHub Actions מעביר עבודה ממשימה אחת לאחרת תוך שמירה על סודות מתחומים היטב וטריגרים מוגדרים,

00:17:24.330 --> 00:17:28.650
היא מה שהופך אום מניסוי של תקווה לפרקטיקה אמינה, מאובטחת וצפויה.

00:17:29.190 --> 00:17:33.110
פילוח זרימות העבודה הזה הוא לא רק עניין של עמידה בשיטות עבודה מומלצות.

00:17:33.870 --> 00:17:36.990
זה מה שחוסם דליפות הבטחה שקטות ודריסות מקריות,

00:17:37.330 --> 00:17:42.310
וזה עוצר סוג שלם של שגיאות בלתי נראות לפני שהן מתחילות להעיק על הסביבות שלך.

00:17:42.310 --> 00:17:46.430
עכשיו, כשהחלקים עובדים יחד דרך אוטומציה מתוחמת כראוי,

00:17:46.670 --> 00:17:49.190
הגיע הזמן שנטפל בנקודת חיכוך נוספת.

00:17:49.310 --> 00:17:52.030
מחברים, עקרונות שירות והמכשולים הקטנים,

00:17:52.150 --> 00:17:56.690
אך הקריטיים שיכולים לעצור את הפריסות שלכם בדיוק כשאתם מרגישים בטוחים.

00:17:57.130 --> 00:17:59.830
עקרונות שירות סודיים והבעיות עם מחברים.

00:18:00.110 --> 00:18:05.250
אם אי פעם ניסיתם להעביר Power App of Law מפיתוח לייצור, אתם מכירים את הסיפור.

00:18:05.250 --> 00:18:13.170
דברים עובדים ללא דופי בסביבה אחת, אבל ברגע שעוברים, הכל נעצר או שאתם מקבלים את שגיאות החיבור המסתוריות האלה.

00:18:13.710 --> 00:18:15.430
זה לא ייחודי לצוות ספציפי.

00:18:15.630 --> 00:18:19.230
כל מנהל Power Platform נתקל בסופו של דבר בקיר הזה.

00:18:19.850 --> 00:18:24.450
שורש הבעיה תמון באופן שבו מחברים וסודות מתנהגים מאחורי הקלעים.

00:18:24.670 --> 00:18:30.210
אי אפשר פשוט לייצא קובץ פתרון, זיפ, מהפיתוח ולצפות שהוא יעבוד במקום אחר,

00:18:30.490 --> 00:18:33.110
כי החיבורים שהוא תלוי בהם משתנים בכל סביבה.

00:18:33.110 --> 00:18:34.990
קחו למשל הפניות למחברים.

00:18:35.210 --> 00:18:40.570
בפאוור פלטפורם, מחבר הוא לעולם לא רק פיסת מידע סטטית שנערזה בתוך האפליקציה שלכם.

00:18:40.730 --> 00:18:43.770
הוא דינמי, ניתן לשינוי ולרוב ייחודי לכל סביבה.

00:18:43.890 --> 00:18:48.310
כשאתם מייצאים את הפתרון שלכם, הפניות למחברים מתפקדות כמעט כמו סימניות.

00:18:48.450 --> 00:18:52.290
הן מצביעות על אובייקטי חיבור שקיימים רק בסביבה שבה הם נוצרו.

00:18:52.290 --> 00:19:01.090
לכן, כשמייבים לבדיקות או לייצור, נקודת הקצה של ה-HTTP או הקישור לדטאברס לא בהכרח נוצרים מחדש באותו אופן או בכלל.

00:19:01.250 --> 00:19:02.330
כאן צוותים נופלים.

00:19:03.890 --> 00:19:09.630
אם הפיתוח משתמש במחבר לנתוני בדיקה והתצורה המדויקת הזו לא משתקפת בייצור,

00:19:09.890 --> 00:19:14.290
הפלו או האפליקציה שלכם יקשלו בשקט או ייתקעו בניסיון הראשון להתחבר.

00:19:14.290 --> 00:19:20.830
אנשים רבים מנסים לעקוף זאת על ידי שיתוף אישורי משתמש בין סביבות.

00:19:21.010 --> 00:19:27.290
הם חושבים שאם ישתמשו באותו חשבון או סיסמה שיצרו את החיבור בפיתוח, אולי זה פשוט יעבוד בייצור.

00:19:27.470 --> 00:19:32.710
המציאות היא שזה מזמין שורה של בעיות, הכל החל מדחיית הרשאות ועד להפעלת ביקורות ציו.

00:19:32.870 --> 00:19:38.890
ההנחיות של מייקרוסופט ברורות, שימוש באישור משתמש פרטני לפריסות אוטומטיות אינו מעשי או מאובטח.

00:19:38.890 --> 00:19:44.990
זה מפקיר את האוטומציה שלכם לחסדי איפוס סיסמאות ויכול להשאיר עקבות בעייתיים ביומני הביקורת שלכם.

00:19:45.390 --> 00:19:52.630
אין אחריות ברורה ובסופו של דבר הרשאות חוסמות את הצינור כשהמשתמש המקורי מסומן, מוסר או מאבד גישה.

00:19:52.810 --> 00:19:55.390
היכנסו עקרונות שירות, Service Principles.

00:19:55.590 --> 00:20:01.510
אם לא עבדתם איתם, תארו לעצמכם עקרון שירות כזוג ידיים דיגיטלי נוסף שנבנה במיוחד לאוטומציה.

00:20:01.510 --> 00:20:08.250
בשונה ממשתמש רגיל, עקרון שירות קשור לרישום אפליקציה ב-Azure AD לא לאדם אמיתי.

00:20:08.490 --> 00:20:12.690
אתם מעניקים לו את הרשאות המינימום הנדרשות להרצת משימות הפריסה שלכם.

00:20:12.890 --> 00:20:14.970
זה נשמע פשוט, אבל התמורה גדולה.

00:20:14.970 --> 00:20:21.990
במקום להסתמך על משתמש שעלול לעזוב את הארגון או לשנות תפקיד, הפריסות נשארות עקביות, בנות ביקורת וניתנות למעקב.

00:20:22.130 --> 00:20:28.370
כל סביבה מקבלת גישה אך ורק לחיבורים ולמשאבים הנכונים וכל שינוי מתועד תחת חשבון הבוט הזה.

00:20:28.370 --> 00:20:34.670
כשמה שהוא נכשל, יש לך נתיב ביקורת ברור ואתה לא נשאר עם תהליכי עבודה יתומים שאף אחד לא יכול לתקן.

00:20:35.330 --> 00:20:39.950
בנושא מיפוי מחברים, שכל מה קורה כשהסביבות מתחילות להשתנות זו מזו.

00:20:39.950 --> 00:20:43.550
אולי צוות הפיתוח קיבל אישור עבור מחבר מותאם אישית חדש.

00:20:43.690 --> 00:20:46.410
נניח שהוא ניגש לאפי-איי של סביבת ארגז חול.

00:20:46.570 --> 00:20:52.770
כשמגיע הזמן לעבור ליצור, המחבר הזה לא רק חסר, הוא עשוי אפילו להיות אסור לפי מדיניות הנתונים הארגוני.

00:20:52.770 --> 00:20:58.270
אם תשכח לבצע מיפוי מחדש, האפליקציה תפנה לנקודת קצה שגויה או תקרוס לחלוטין.

00:20:58.430 --> 00:21:01.430
ראיתי את זה קורה בצורה קשה בקבוצת בריאות לאחרונה.

00:21:01.430 --> 00:21:07.230
מיפוי מחברים אחד שפוספס הוביל לשימוש בנתוני בדיקה בסביבת הייצור וכמעט יצר אירוע הבטחת מידע.

00:21:07.350 --> 00:21:10.230
צינור האיבוד האוטומטי שלהם ייצא הכל כמתוכנן.

00:21:10.230 --> 00:21:19.510
אך הפנייה למחבר בתוך הפתרון עדיין הצביעה על מסד נתונים ישן של בדיקות שלא סומן על ידי פאוור פלטפורם עד שינטונים אמיתיים החלו לזרום בצינורות הלא נכונים.

00:21:19.770 --> 00:21:23.350
משתני סביבה נכנסים לתמונה כדי להקל על חלק מהקשיים הללו.

00:21:23.390 --> 00:21:30.870
בניגוד לקידוד קשיח של נקודות קצה או מפתחות API, משתני סביבה מאפשרים לך להפריד בין מה שמשתנה בין סביבות לבין מה שנשאר קבוע.

00:21:30.870 --> 00:21:37.510
ניתן להחליף נקודות קצה, מפתחות API או סודות אחרים בכל פריסה מבלי לשכתב את האפליקציה או התהליך.

00:21:37.650 --> 00:21:47.910
למשל, תהליך שעובד עם טבלת Dataverse של פיתוח ניתן להגדרה מחדש בעת האיבוק כך שישתמש בטבלת הייצור פשוט על ידי שינוי משתנה הסביבה בתהליך הפריסה שלך.

00:21:48.070 --> 00:21:50.590
צינורות GitHub Actions הופכים את זה למעשי.

00:21:50.730 --> 00:21:53.710
כל משימה יכולה להזין את הערך הנכון בזמן הנכון.

00:21:53.870 --> 00:21:55.910
אבל גם כאן, משמעת היא המפתח.

00:21:55.910 --> 00:22:02.450
שכח לעדכן משתנה או תן לסודות לדלוף בין סביבות ופתאום תהליך העבודה שלך נכסף.

00:22:03.230 --> 00:22:08.950
מייקרוסופט מדגישה את הצורך לתחם סודות בזהירות ולמפות הפניות למחברים באופן מכוון.

00:22:09.450 --> 00:22:18.270
מדיניות מניעת אובדן נתונים, DRP, שלהם קיימת מסיבה מסוימת כדי למנוע ממידע רגיש לנדוד בין סביבות או לצוף במקום הלא נכון.

00:22:18.270 --> 00:22:26.090
אם תנסה לעקוף זאת על ידי שיתוף משתנים או חיבורים, אתה תתקל בבעיות מול בקרות הבטחה או ציות ארגוניות.

00:22:26.690 --> 00:22:33.190
חשוב מכך, אתה מאבד יכולת חיזוי כי אין יותר קו מפריד בין מה שמיועד לפיתוח לעומת בדיקות או ייצור.

00:22:33.410 --> 00:22:36.770
קשה להפריז בחשיבות התועלת כשעושים את כל זה נכון.

00:22:36.770 --> 00:22:42.790
עקרונות שירות בשילוב עם משתני סביבה מנוהלים היטב ומחברים ממופים כראוי משנים את צינור העיבוד שלך.

00:22:42.910 --> 00:22:44.670
הפריסות שלך הופכות לצפויות.

00:22:44.870 --> 00:22:49.090
כשדברים נשברים, יש לך שרשרת אחריות ברורה ואתה יודע בדיוק איפה לחפש.

00:22:49.250 --> 00:22:52.690
האם זה היה מיפוי מחבר, משתנה או הרשאה שפוספסה.

00:22:52.830 --> 00:22:57.750
מבקרים יכולים לעקוב אחר שינויים ואין שום מתח כשמישהו עוזב את הארגון או משנה סיסמאות.

00:22:57.750 --> 00:23:02.590
הכל מסתכם בהתייחסות לסודות, למחברים ולעקרונות שירות כאילו יש להם חשיבות.