WEBVTT

00:00:00.300 --> 00:00:07.540
Готові до 10-х днів Microsoft 365, Co-Pilot, She, Azure та людей, які формують майбутні роботи.

00:00:07.680 --> 00:00:12.340
Цього січня M365Con повертається, і ми стаємо ще масштабнішими.

00:00:12.500 --> 00:00:18.480
Приєднуйтесь до нас для живих сесій, реальних демо-версій та практичних знань від MVP та галузевих експертів з усього світу.

00:00:18.660 --> 00:00:22.040
Жодних загальних слайдів, жодних нескінчених модних слів.

00:00:22.200 --> 00:00:29.200
Ми вирішуємо реальні завдання Co-Pilot Studio, She-агенти, Fabric, безпека, управління та автоматизація.

00:00:29.200 --> 00:00:34.940
Незалежно від того, чи ви IT-фахівець, розробник чи бізнес-лідер, для вас знайдуться сесії.

00:00:35.340 --> 00:00:40.540
За 10 повних днів ви зможете дослідити різні технології та приєднатися до глобальної спільноти.

00:00:40.900 --> 00:00:44.680
Дивіться наживо та принесьте практичні ідеї у свою організацію.

00:00:44.680 --> 00:00:51.000
Січень 2027 – 10 днів, одна спільнота Microsoft. Реєстрація вже відкрита.

00:00:52.860 --> 00:00:54.880
Забронюйте своє місце сьогодні.

00:00:54.880 --> 00:01:04.600
Приєднуйтесь на M365Con.net і побачимося в січні.

00:01:04.740 --> 00:01:08.400
Ви коли-небудь відчували, що ваші розгортання Pava Platform – це чорна скринька.

00:01:08.400 --> 00:01:13.900
Ви випускаєте оновлення, затамовуєте подих і сподіваєтесь, що воно запрацює у розробці, тестуванні та продакшені.

00:01:14.020 --> 00:01:21.100
А що, якби ви могли контролювати кожен етап процесу ELM за допомогою GitHub Actions без припущень та ручних правок?

00:01:21.100 --> 00:01:28.480
Давайте відкриємо завісу того, як компоненти, контроль версій, автоматизація та безпечні змінні насправді взаємодіють.

00:01:28.640 --> 00:01:35.080
Це не просто черговий огляд. Це те, про що мовчать більшість інструкцій, щоб ваше наступне розгортання було передбачуваним.

00:01:35.240 --> 00:01:38.340
Отже, чому ELM у Pava Platform здається лабіринтом?

00:01:38.640 --> 00:01:45.540
Якщо ви хоч раз намагалися розгорнути Pava App і відчували невпевненість, ніби щось важливе вислизнуло, ви не одні.

00:01:45.540 --> 00:01:52.880
На папері Pava Platform обіцяє легку розробку додатків, але за цим дружнім фасадом ELM зовсім непроста.

00:01:53.100 --> 00:01:59.780
Веб-додаток розгортається з контролю версій, збирається в конвоїрі та потрапляє у продакшен з передбачуваною поведінкою.

00:02:00.500 --> 00:02:07.560
Pava Platform, навпаки, ховає логіку в інтерфейсах, екранах підключень та формулах, які не видно в репозиторіях DIT.

00:02:07.560 --> 00:02:16.840
Тож, навіть якщо ви виконуєте всі кроки з інструкцій для адміністраторів, ви все одно стикаєтеся зі збоями, коли важливі для бізнесу додатки залишають розробку.

00:02:17.040 --> 00:02:19.900
Давайте поглянемо на ELM-посібники, які існують сьогодні.

00:02:20.060 --> 00:02:24.100
Більшість з них показують лише експорт в ZIP-архіву рішення та його імпорт в інше місце.

00:02:24.280 --> 00:02:27.380
Досить просто, чи не так? Але це лише технічний бік справи.

00:02:27.380 --> 00:02:29.760
Вони пропускають відповідь на питання «Чому?»

00:02:29.760 --> 00:02:33.720
Чому розгортання Pava Platform ламається там, де звичайний код працює бездоганно?

00:02:33.720 --> 00:02:35.960
Ось що спричиняє нескінченну плутанину.

00:02:36.140 --> 00:02:41.920
Корінь проблеми в тому, що логіка, підключення та конфігурації в Pava Apps зберігаються не так, як класичний код.

00:02:42.080 --> 00:02:45.540
Ви не просто клонуєте репозиторі і спостерігаєте за модульними тестами.

00:02:45.700 --> 00:02:54.360
Тож, коли ви намагаєтеся перенести свій додаток, усі ці приховані залежності, підключення до Outlook, SharePoint, власні ARRI не завжди акуратно вміщуються в цей ZIP-файл.

00:02:54.360 --> 00:02:55.360
Ось такий сценарій.

00:02:55.360 --> 00:03:01.880
Ви запускаєте новий блискучий додаток у середовищі розробки, експортуєте рішення, імпортуєте в тестування і раптом потік перестає працювати.

00:03:02.040 --> 00:03:04.080
Це рідко буває, просто проблемою з файлом.

00:03:04.260 --> 00:03:11.600
Натомість підключення вказують не туди, права доступу не збігаються, а політики даних блокують з'єднання, які ще хвилину тому працювали нормально.

00:03:11.600 --> 00:03:21.160
Тепер уявіть, що ви робите це для трьох середовищ – розробки, тестування та продуктового, де кожне використовує різні підключення, політики захисту даних, схвалювачів та адміністративні обмеження.

00:03:21.320 --> 00:03:24.220
Ви не зможете просто скопіювати та вставити рішення, щоб усе запрацювало.

00:03:24.380 --> 00:03:27.800
Дослідження підтверджують те, що адміністратори та розробники бачать щотижня.

00:03:27.960 --> 00:03:34.260
Більшість невдалих розгортань у Pava Platform стаються через відсутні посилання на конектори або неправильне керування змінними середовища.

00:03:34.260 --> 00:03:40.260
Відсутність посилання на конектор означає лише те, що потік не може знайти своє підключення до Outlook чи Dataverse.

00:03:40.420 --> 00:03:46.820
Тому, як тільки ви намагаєтеся запустити додаток чи потік в іншому середовищі, ви отримуєте помилки під час виконання.

00:03:47.000 --> 00:03:55.400
І оскільки змінні середовища в Pava Platform працюють інакше, ніж в інших продуктах Microsoft 365, вони ставлять у глухий кут навіть досвідчених розробників.

00:03:55.580 --> 00:04:00.000
Змінні мають обробляти кінцеві точки, ключі або конфігурації, специфічні для орендаря.

00:04:00.000 --> 00:04:06.360
Але якщо хтось забуде оновити їх після експорту рішення, навіть безневинна на вигляд зміна може зламати робочий додаток.

00:04:06.520 --> 00:04:09.080
Багато хто з нас спочатку потрапляє в ту саму пастку.

00:04:09.280 --> 00:04:14.820
Можна подумати, що експорт зі IP-файлу рішення містить усе необхідне, але насправді він пропускає динамічні посилання на конектори.

00:04:14.920 --> 00:04:19.700
Наприклад, припустімо, у вас є додаток, який використовує HTTP-конектор для стороннього сервісу в розробці.

00:04:19.840 --> 00:04:24.160
Коли ви імпортуєте його в тестування чи продуктив, саме цей екземпляр конектора буде відсутній.

00:04:24.160 --> 00:04:30.040
Посилання на конектор у вашому додатку вказує на відсутній об'єкт, і потоки в рішенні тихо ламаються,

00:04:30.200 --> 00:04:34.700
доки користувач чи адміністратор вручну не відтворить і не перепризначить підключення.

00:04:34.880 --> 00:04:40.560
Якщо у вас більше одного розробника чи адміністратора, ще легше втратити розуміння, яке посилання куди веде,

00:04:40.680 --> 00:04:44.020
і ніхто не хоче розбору польотів у стилі, а в розробці все працювало.

00:04:44.260 --> 00:04:47.300
Ще одна складність – суб'єкти служби – сервіс принципал.

00:04:47.300 --> 00:04:53.340
Більшість починають із використання облікових записів користувачів для експорту та імпорту рішень, бо так швидше розпочати.

00:04:53.520 --> 00:04:57.340
Але коли ви намагаєтеся автоматизувати це через GitHub Actions або будь-яку CI-систему,

00:04:57.480 --> 00:04:59.960
використання особистих облікових даних швидко веде в глухий кут.

00:05:00.060 --> 00:05:03.480
Ви зіткнетеся з обмеженнями прав доступу, іноді без чітких повідомлень про помилки,

00:05:03.580 --> 00:05:08.360
або навіть спровокуєте перевірки відповідності, оскільки виконуєте критичні розгортання через персональний аккаунт,

00:05:08.360 --> 00:05:10.420
а не через спеціально створений для автоматизації.

00:05:10.420 --> 00:05:18.920
Сервісні принципалі, по суті ідентифікатори додатків, створені в Azure ID, опрацьовують усі дозволи, логування та аудит, необхідні вашому конвоєру.

00:05:19.140 --> 00:05:25.480
Без них ваш ланцюжок автоматизації перетворюється на клаптик передачі завдань між людьми, і ви ніколи не знаєте, хто і що змінив.

00:05:25.620 --> 00:05:28.020
Контроль версій також стає непередбачуваним.

00:05:28.200 --> 00:05:31.980
У звичайному коді у вас є історія комітів та інструменти відстеження змін.

00:05:31.980 --> 00:05:37.260
Файли рішень Pava Platform – це лише знімки стану, що означає відсутність детального відстеження змін.

00:05:37.260 --> 00:05:44.180
Логіка, прихована у формулах екранів Canvas-додатків або в погано задокументованих потоках, невидима, доки ви не експортуєте її знову.

00:05:44.320 --> 00:05:49.980
Хтось змінює налаштування потоку в інтерфейсі і спробуйте зрозуміти, чому подальші середовища раптом поводяться інакше.

00:05:50.140 --> 00:05:57.460
У підсумку, управління ALM для Pava Platform нагадує складання пазла, де половини частин не вистачає або вони заховані під коробкою.

00:05:57.460 --> 00:06:06.040
Невидимі залежності, специфічні для середовища конектори та змінні, які неможливо побачити в коді, порушують звичний робочий процес розробника.

00:06:06.220 --> 00:06:16.680
І це ще до того, як ви зіткнетеся з тим, що продуктивні середовища майже завжди мають суворіші дозволи, інші політики даних та вимоги аудиту неочевидні під час розробки чи тестування.

00:06:16.940 --> 00:06:18.460
Але ось у чому перевага.

00:06:18.600 --> 00:06:20.220
Ця складність не випадкова.

00:06:20.700 --> 00:06:26.460
Є практична причина, чому Pava Platform обробляє джерела, змінні та конектори таким унікальним способом.

00:06:26.460 --> 00:06:32.080
Вона намагається дозволити бізнес-користувачам створювати потужні додатки, не переймаючись кодом.

00:06:32.240 --> 00:06:38.760
Побічним ефектом є те, що вам, як людині, яка налаштовує автоматизацію, потрібно стежити за тим, що приховано під капотом.

00:06:38.920 --> 00:06:46.200
Якщо ви знаєте, де проходять ці невидимі зв'язки, ви зможете виправити або уникнути більшості проблем, що гальмують ALM у Pava Platform.

00:06:46.480 --> 00:06:50.120
Якщо все це звучить як занадто багато справ одночасно, ви маєте рацію.

00:06:50.120 --> 00:06:53.780
Але є чотири стовпи ALM, які дійсно допомагають розплутати цей хаос.

00:06:53.780 --> 00:06:56.160
Джерело, збірка, тестування та розгортання.

00:06:56.320 --> 00:07:01.960
Кожен з них має свої особливості в Pava Platform, але разом вони повертають структуру в те, що інакше здається хаосом.

00:07:02.100 --> 00:07:05.700
Основна система ALM – джерело, збірка, тестування, розгортання.

00:07:05.920 --> 00:07:15.260
Щоразу, коли хтось просить конвейер Pava Platform, який просто працює, на думку спадають ці чотири старі стовпи ALM, джерело, збірка, тестування, розгортання.

00:07:15.260 --> 00:07:18.880
У традиційній розробці ви могли б робити це майже з заплющеними очима.

00:07:19.000 --> 00:07:21.620
Pava Platform не дозволяє вам так легко відбутися.

00:07:21.620 --> 00:07:24.040
Раптом, джерело вже не означає код.

00:07:24.380 --> 00:07:32.700
Це означає роботу з файлами рішень, експорту архівних пакетів із додатками, потоками та іноді конекторами, що вдають із себе частину джерела.

00:07:33.400 --> 00:07:38.160
Почнемо з основ, а потім розберемо, що робить кожен стовп таким дивним у цьому світі.

00:07:38.320 --> 00:07:40.120
Ви маєте свій ZIP-файл рішення.

00:07:40.300 --> 00:07:42.000
Це не код у звичному розумінні.

00:07:42.000 --> 00:07:48.420
Відкрийте його, і ви побачите файли XML та JSON, а не логіку, яку ви очікували б знайти в TypeScript чи C.

00:07:48.540 --> 00:07:50.680
Але це і є вихідний код для Pava Platform.

00:07:50.900 --> 00:07:52.960
Команди часто припускаються тут помило.

00:07:53.200 --> 00:07:58.760
Він здається портативним, доки ви не зрозумієте, що більшість змін, як от оновлення формули чи логіки потоку,

00:07:58.880 --> 00:08:02.080
стають помітними лише після експорту свіжого ZIP-архіву рішення.

00:08:02.080 --> 00:08:08.280
Тож так, ви можете версію оновити ці файли рішень у GIT, але якщо ви не будете дисципліновано експортувати їх після кожної важливої правки,

00:08:08.420 --> 00:08:10.280
ваша історія матиме серйозні прогалини.

00:08:10.440 --> 00:08:12.240
Тепер переходимо до конфігурації.

00:08:12.480 --> 00:08:17.040
Для звичайних програм ви можете зберегти рядки підключення у файлі конфігурації і на цьому завершити.

00:08:17.200 --> 00:08:21.580
Pava Platform приховано переносить дані, специфічні для середовища, всередину цих рішень.

00:08:21.580 --> 00:08:29.340
Це не лише змінні середовища, це посилання на конектори, динамічні кінцеві точки, ролі та дозволи, зібрані разом із бізнес-логікою.

00:08:29.520 --> 00:08:36.320
Якщо ви забудете оновити їх перед експортом із середовища розробки чи тестування, ви зафіксуєте посилання на неправильні ресурси.

00:08:36.480 --> 00:08:41.220
Я бачив, як команди сумлінно комітять свої ZIP-файли рішень, лише щоб після розгортання виявити,

00:08:41.380 --> 00:08:47.820
що половина програми досі звертається до датаверс середовища розробки, а не продуктового, бо ніхто не переналаштував посилання на конектори.

00:08:47.820 --> 00:08:56.040
Далі у нас етап збірки – білд. Слово «збірка» зазвичай викликає асоціації з компіляцією коду та спостереженням за зеленими галочками в CI-завданнях.

00:08:56.140 --> 00:09:02.120
У Pava Platform процес збірки полягає в збереженні ZIP-пакетів, перевірці схем та підтвердженні залежностей.

00:09:02.300 --> 00:09:05.940
У конвоєрі GitHub Actions завдання збірки бере ваш зафіксований файл рішення,

00:09:06.060 --> 00:09:11.620
а потім використовує Microsoft Pava Platform CLI для розпакування, перевірки та повторного пакування рішення.

00:09:11.620 --> 00:09:14.800
Етап перевірки – це те місце, де стається магія або хаос.

00:09:17.820 --> 00:09:23.980
Гірше того, якщо зміни у вашому потоці залежать від спеціального коннектора, якого немає в системі контролю версій,

00:09:24.120 --> 00:09:28.140
ваша збірка мовчки запакує щось неповне. Ось тут усе стає складним.

00:09:28.320 --> 00:09:35.760
Ці завдання збірки спрямовані не на компіляцію, а на забезпечення надійного експорту та гарантію того, що вміст готовий до випуску.

00:09:35.900 --> 00:09:41.080
Команди, які пропускають або поспішають із цим, швидко опиняються в ситуації, коли збірка технічно вдала,

00:09:41.080 --> 00:09:44.800
але в UIT або продакш не потрапляє продукт без половини потрібних функцій.

00:09:44.800 --> 00:09:50.180
Microsoft продовжує просувати ідею, що файли рішень роблять ALM портативним, але завжди є примітка.

00:09:50.340 --> 00:09:55.140
Портативність залежить від того, чи правильно налаштовані коннектори та чи встановлені ролі в різних середовищах.

00:09:55.280 --> 00:09:56.920
Тестування – це наступний етап.

00:09:57.100 --> 00:10:02.160
У конвоєрі веб-програми автоматизовані тести можуть включати модульні тести або перевірку інтерфейсу.

00:10:02.340 --> 00:10:06.220
Для PAWA платформ питання того, що вважати тестом, залишається відкритим.

00:10:06.220 --> 00:10:12.400
Іноді це перевірка рішення іншими словами, чи відкривається рішення і чи вирішуються ключові залежності.

00:10:12.580 --> 00:10:18.340
В іншому разі це запуск тестових потоків або перевірка того, чи відповідають коннектори в тестовому середовищі.

00:10:18.500 --> 00:10:25.140
Часто тестування є ручним, оскільки перевірка бізнес-логіки всередині Canvas-додатків ще не інтегрована в автоматизовані конвейери.

00:10:25.320 --> 00:10:31.220
Але ви можете автоматизувати перевірки для виявлення відсутніх коннекторів, валідації критичних потоків або навіть пінгу тестового середовища,

00:10:31.880 --> 00:10:33.680
щоб підтвердити роботу облікових даних.

00:10:33.680 --> 00:10:35.800
Розгортання лише посилює ці труднощі.

00:10:35.960 --> 00:10:39.920
Коли розгортається стандартний додаток, ви можете просто завантажити веб-артефакт у Azure.

00:10:40.100 --> 00:10:45.720
У Power Platform потрібно налаштовувати підключення, призначати дозволи оновлювати секрети, змінювати змінні середовища

00:10:45.720 --> 00:10:49.680
і нарешті запускати імпорт через суб'єкт службу, а не через звичайний обліковий запис.

00:10:49.880 --> 00:10:52.840
Інакше ви зіткнетеся з аудитами та відмовами у доступі.

00:10:53.000 --> 00:11:00.040
GitHub Actions може об'єднати цей процес, але лише якщо кожне завдання знає, на яке середовище спрямоване і які секрети використовувати.

00:11:00.040 --> 00:11:05.920
Я бачив, як команди намагалися прискорити це, використовуючи один набір облікових даних для розробки та продуктивного середовища,

00:11:06.000 --> 00:11:10.540
що веде до хаосу, витоку даних, помилок доступу та проблем, які з'являються лише в одному середовищі.

00:11:10.700 --> 00:11:13.580
Візьмемо реальну команду, з якою я працював кілька місяців тому.

00:11:13.780 --> 00:11:18.220
Вони робили майже все правильно – стандартні діт-репозиторії, версійні зіп-архіви рішень та чітке розгалуження.

00:11:18.380 --> 00:11:20.880
Але їхній конвейер завжди зупинявся під час розгортання.

00:11:21.060 --> 00:11:21.360
Чому?

00:11:21.360 --> 00:11:26.820
Вони ніколи не змінювали змінні середовища і не оновлювали посилання на конектори перед імпортом у продуктивне середовище.

00:11:26.960 --> 00:11:31.700
Це призводило до того, що ключові потоки вказували на неправильні кінцеві точки, а дані потрапляли не в ті системи.

00:11:31.840 --> 00:11:37.940
Вирішенням стали скриптові кроки в їхньому діт-хаб-конвейері, які змінювали змінні та перепризначали кожен конектор під час імпорту.

00:11:38.100 --> 00:11:40.800
Власні рекомендації Microsoft говорять про це прямо.

00:11:40.800 --> 00:11:48.160
Ви користовуйте файли рішень для переміщення об'єктів між середовищами, але завжди опрацьовуйте посилання на конектори та зіставлення ролей як частину вашого конвейера.

00:11:48.380 --> 00:11:54.440
Вони зазначають, що ігнорування цих кроків – це головна причина поломок додатків, особливо коли середовища стають більш захищеними.

00:11:54.440 --> 00:12:00.400
Якщо розглядати вихідний код, збірку, тестування та розгортання як взаємопов'язані частини, а не як ізольовані етапи,

00:12:00.540 --> 00:12:06.560
стає зрозуміло, чому багато спроби ALM провалюються і як можна реально усувати проблеми, а не просто сподіватися на успіх.

00:12:06.560 --> 00:12:13.200
Далі давайте розберемося, як GitHub Actions координує цей процес, тригери, розгалуження та розділення завдань,

00:12:13.340 --> 00:12:17.080
які роблять вашу автоматизацію PAVA Platform гнучкою та безпечною.

00:12:17.080 --> 00:12:20.820
GitHub Actions поєднуємо все разом за допомогою тригерів та завдань.

00:12:20.980 --> 00:12:24.760
Якщо ви чекали завершення конвейера GitHub Actions після оновлення свого PAVA App,

00:12:24.880 --> 00:12:28.940
ви вже знаєте, що автоматизація не означає миттєвість і точно не означає магію.

00:12:29.120 --> 00:12:33.940
Більшість команд стикаються з цією стіною відразу після захоплення від першого запуску робочого процесу.

00:12:33.940 --> 00:12:38.000
Ви налаштовуєте скрипт, підключаєте його до свого репозиторію і очікуєте,

00:12:38.160 --> 00:12:40.940
що кожен новий коміт буде чисто розгортатися в усіх середовищах.

00:12:41.620 --> 00:12:43.140
А потім настає реальність.

00:12:43.140 --> 00:12:47.400
Замість простого запуску сценарію, GitHub Actions використовує логічний ланцюжок,

00:12:47.480 --> 00:12:50.980
побудований навколо тригерів, завдань і передачі даних між середовищами.

00:12:51.160 --> 00:12:56.820
Саме цей порядок і структура не дають розгортанням перетворитися на клубок невдалих кроків і дивних помилок.

00:12:56.940 --> 00:12:59.340
Відправною точкою в цій системі є тригер.

00:12:59.340 --> 00:13:04.580
Більшість новачків створюють робочий процес, який запускається під час кожного пушу

00:13:04.580 --> 00:13:07.560
або коли запит на злиття потрапляє в головну гілку.

00:13:07.560 --> 00:13:10.180
На перший погляд, це виглядає як найкраща практика.

00:13:10.300 --> 00:13:12.780
Чому б не запускати конвейер щоразу, коли в роботі з'являються зміни?

00:13:12.920 --> 00:13:13.920
Ось у чому підвох.

00:13:14.000 --> 00:13:17.320
Коли ви встановлюєте тригер лише на головну гілку, усе спрямовується одним шляхом.

00:13:17.440 --> 00:13:20.980
А що, як зміни потрібно застосувати лише до середовища розробки, а не до тестового чи продуктового?

00:13:20.980 --> 00:13:24.460
Що, як ви готові до випуску в прод, але тест ще виконує перевірку?

00:13:24.620 --> 00:13:28.800
Команди, що використовують універсальні тригери, часто стикаються з проблемами,

00:13:28.900 --> 00:13:32.440
коли функції для розробки потрапляють у прод або тестові розгортання,

00:13:32.540 --> 00:13:34.940
раптово перезаписують налаштування продакшну.

00:13:35.100 --> 00:13:38.340
Ви можете розгалужувати робочі процеси для кожного середовища,

00:13:38.480 --> 00:13:42.020
дев, тест і прод, і налаштовувати для них дуже специфічні тригери.

00:13:42.220 --> 00:13:47.020
Наприклад, налаштуйте робочий процес, який запускається лише при пушах у гілку розробки,

00:13:47.020 --> 00:13:50.620
або інший процес, коли хтось робить злиття в гілку релізу продакшну.

00:13:50.760 --> 00:13:54.680
Це дає більше контролю та чітко розмежовує поточну роботу і робочі зміни,

00:13:54.820 --> 00:13:58.420
але багато команд ніколи не переглядають свої тригери після створення.

00:13:58.680 --> 00:14:02.020
Саме так секрети з одного середовища можуть просочитися в інше,

00:14:02.100 --> 00:14:05.460
а конфігурація для розробки випадково опинитися в продакшні.

00:14:05.640 --> 00:14:10.820
Одна команда, з якою я працював, намагалася виконувати весь свій ELM-процес через один робочий процес.

00:14:10.820 --> 00:14:13.520
Якийсь час усе було добре, поки хтось не помітив,

00:14:13.520 --> 00:14:17.640
що рядок підключення до робочої бази даних з'явився в середовищі розробки.

00:14:17.840 --> 00:14:21.260
Вони не усвідомлювали, що їхні секрети стають спільними для різних завдань.

00:14:21.380 --> 00:14:24.740
І як тільки код переміщувався між середовищами, ці секрети витікали разом із ним.

00:14:24.900 --> 00:14:26.860
Це не було очевидною критичною помилкою.

00:14:27.020 --> 00:14:28.220
Це відбувалося тихо.

00:14:28.360 --> 00:14:30.800
Такі витоки даних трапляються частіше, ніж ви думаєте,

00:14:30.920 --> 00:14:34.520
особливо якщо ви не налаштовуєте робочі процеси для розділення секретів і змінних середовища.

00:14:34.520 --> 00:14:39.940
Кожне завдання в робочому процесі GitHub Actions відповідає за чітко визначену частину процесу.

00:14:40.080 --> 00:14:44.380
Одне завдання може відповідати за експорт рішення з вихідного середовища.

00:14:44.560 --> 00:14:48.680
Інше займається перевіркою, розпакуванням, скануванням метаданих,

00:14:48.820 --> 00:14:52.160
перевіркою залежностей і наявністю посилань на конектори.

00:14:52.900 --> 00:14:58.520
Далі йде завдання, яке готує змінні середовища, адаптуючи рішення під цільове середовище.

00:14:58.520 --> 00:15:04.980
Останнє завдання запускає процес імпорту, використовуючи сервісні принципи для запису змін у потрібне середовище.

00:15:05.140 --> 00:15:08.520
Можна подумати, що змінні середовища та секрети – це прості заповнювачі,

00:15:09.280 --> 00:15:12.000
але на практиці вони є клеєм, що тримає все разом.

00:15:12.160 --> 00:15:16.780
Рядки, підключення, ключі АРІ, спільні паролі – усе це потрібно змінювати між завданнями,

00:15:16.900 --> 00:15:20.020
але вони ніколи не повинні виходити за межі встановлених кордонів.

00:15:20.180 --> 00:15:24.720
У Pava Platform ALM ви можете мати окреме підключення до Dataverse для кожного середовища

00:15:24.720 --> 00:15:29.420
або потребувати заміни кінцевих точок залежно від того, на який потік чи Pava App ви спрямовані.

00:15:29.560 --> 00:15:32.800
Якщо ви повторно використовуєте змінні або жорстко кодуєте секрети,

00:15:32.860 --> 00:15:36.780
ви отримуєте або ненадійний конвейер, або, що гірше, значні ризики для безпеки.

00:15:36.900 --> 00:15:40.220
Процес імпорту залежить від отримання секретів лише з відповідного сховища,

00:15:40.320 --> 00:15:44.320
щоб робоче середовище не наражалося на небезпеку через помилки в тестуванні чи розробці.

00:15:44.480 --> 00:15:47.560
Вдала ментальна модель для секретів у Dithub Actions – уявити,

00:15:47.560 --> 00:15:52.900
що кожне середовище має власне цифрове сховище, закриту скриньку, яку бачить лише потрібні завдання.

00:15:53.120 --> 00:15:55.400
Dithub надає вам точні засоби контролю.

00:15:55.560 --> 00:15:59.420
Ви можете обмежувати секрети середовищами, щоб завдання, яке виконується в розробці,

00:15:59.520 --> 00:16:02.400
не мало доступу до облікових даних робочого середовища і навпаки.

00:16:02.580 --> 00:16:07.040
Налаштуйте ці сховища, і навіть якщо хтось, хто коригує конвейер, спробує щось ризиковане,

00:16:07.160 --> 00:16:09.900
правила захисту середовища не дадуть помилці поширитися.

00:16:10.240 --> 00:16:13.540
Документація Microsoft і Dithub постійно наголошують на цьому.

00:16:13.540 --> 00:16:17.420
Вони рекомендують правила захисту середовища та суворе розмежування секретів,

00:16:17.540 --> 00:16:20.300
щоб зупинити витоки між середовищами ще до їх виникнення.

00:16:20.480 --> 00:16:24.760
Без такого захисту навіть найкраще розроблені робочі процеси ЕЛМ руйнуються.

00:16:24.940 --> 00:16:27.740
Уявіть робочий процес, що розгортається в робочому середовищі,

00:16:27.840 --> 00:16:30.200
але при цьому використовує рядок підключення для розробки

00:16:30.200 --> 00:16:32.700
або має тестове середовище з доступом до робочих даних.

00:16:32.800 --> 00:16:34.840
Це не завжди призводить до видимих поломок.

00:16:35.040 --> 00:16:37.300
Іноді це означає лише спрацювання прапорців відповідності

00:16:37.300 --> 00:16:39.080
або заповнення журналів прихованими помилками,

00:16:39.240 --> 00:16:41.080
які поступово накопичуються у більші проблеми.

00:16:41.160 --> 00:16:44.000
Ось чому розгалуження робочих процесів та розмежування секретів –

00:16:44.000 --> 00:16:45.040
це не просто складні теми.

00:16:45.160 --> 00:16:48.900
Це запобіжний захід, який не дає вашій автоматизації непомітно вийти з ладу.

00:16:49.060 --> 00:16:52.320
Також є сенс розділяти робочі процеси не лише за середовищем,

00:16:52.420 --> 00:16:53.960
а й за сферою відповідальності.

00:16:54.140 --> 00:16:56.440
Код, який експортує та перевіряє рішення,

00:16:56.600 --> 00:16:59.660
не повинен знати, як розгортати чи замінювати секрети.

00:16:59.660 --> 00:17:02.900
Якщо кожне завдання відповідає за одну частину головоломки,

00:17:03.060 --> 00:17:05.480
стає набагато легше виявити, де щось зламалося,

00:17:05.620 --> 00:17:08.200
відкотитися назад і перевірити зміни постфактум.

00:17:08.340 --> 00:17:10.220
Секрети залишаються у своїх сховищах,

00:17:10.340 --> 00:17:12.700
завдання дотримуються чітко визначених прав доступу,

00:17:12.760 --> 00:17:16.060
а збої в конвоєрі прямо вказують на ту частину, яку потрібно виправити.

00:17:16.240 --> 00:17:20.200
Розуміння того, як GitHub Actions передає роботу від одного завдання до іншого,

00:17:20.320 --> 00:17:22.580
зберігаючи при цьому секрети суворо обмеженими,

00:17:22.680 --> 00:17:24.200
а тригери – чітко визначеними,

00:17:24.200 --> 00:17:27.180
перетворює ALM зі сподіваного експерименту на надійну,

00:17:27.300 --> 00:17:29.060
безпечну та передбачовану практику.

00:17:29.300 --> 00:17:33.660
Ця сегментація робочих процесів – це не просто дотримання найкращих практик.

00:17:33.740 --> 00:17:37.320
Це те, що блокує тихі витоки безпеки та випадкові перезаписи,

00:17:37.400 --> 00:17:39.600
усуваючи цілий клас невидимих помилок,

00:17:39.700 --> 00:17:42.320
перш ніж вони почнуть шкодити вашим середовищам.

00:17:42.500 --> 00:17:45.640
Тепер, коли всі частини працюють злагоджено завдяки належним чинам

00:17:45.640 --> 00:17:49.140
налаштуваній автоматизації, настав час розв'язати іншу проблему.

00:17:49.140 --> 00:17:52.740
Конектори, сервісні принципалі та дрібні, але критичні пастки,

00:17:52.940 --> 00:17:56.780
що можуть зупинити ваше розгортання саме тоді, коли ви стаєте впевнені.

00:17:56.900 --> 00:17:59.920
Таємні сервісні принципалі та проблеми з конекторами.

00:18:00.120 --> 00:18:04.140
Якщо ви коли-небудь намагалися перенести Pava App або Flow з розробки в продакшні,

00:18:04.220 --> 00:18:05.440
ви знаєте цю історію.

00:18:05.640 --> 00:18:08.000
Все працює бездоганно в одному середовищі,

00:18:08.080 --> 00:18:12.960
а як тільки ви перемикаєтесь, все зупиняється або видає загадкові помилки підключення.

00:18:12.960 --> 00:18:15.640
Це не унікальна проблема конкретної команди.

00:18:15.640 --> 00:18:19.540
Кожен адміністратор Pava Platform рано чи пізно впирається в цю стіну.

00:18:19.780 --> 00:18:24.320
Корінь проблеми полягає в тому, як конектори та секрети поводяться за лаштунками.

00:18:24.540 --> 00:18:27.480
Ви не можете просто експортувати зіп-архів рішення з розробки

00:18:27.480 --> 00:18:29.500
і очікувати, що він запрацює де-інде,

00:18:29.640 --> 00:18:32.960
бо зв'язки, від яких він залежить, змінюються з кожним середовищем.

00:18:33.140 --> 00:18:35.420
Візьмемо для початку посилання на конектори.

00:18:35.540 --> 00:18:39.100
У Pava Platform Connector це ніколи не просто статичний набір даних,

00:18:39.100 --> 00:18:40.320
вшитий у ваш додаток.

00:18:40.320 --> 00:18:43.940
Він динамічний, змінюваний і часто унікальний для кожного середовища.

00:18:44.060 --> 00:18:47.940
Коли ви експортуєте своє рішення, посилання на конектори діють майже як закладки.

00:18:48.160 --> 00:18:52.680
Вони вказують на об'єкти підключення, які існують лише в тому середовищі, де вони були створені.

00:18:52.820 --> 00:18:55.200
Тому при імпорті в тестове або робоче середовище,

00:18:55.280 --> 00:19:00.780
ваш вишуканий HTTP endpoint або посилання на Dataverse не обов'язково відтворяться так само або взагалі.

00:19:00.940 --> 00:19:03.060
Ось тут команди і потрапляють у пастку.

00:19:03.060 --> 00:19:07.020
Якщо розробка використовує конектор для тестових даних,

00:19:07.100 --> 00:19:09.820
а та сама конфігурація не відображена в продакшні,

00:19:09.940 --> 00:19:14.960
ваш потік або додаток або тихо збоїть або зависає при першій спробі підключитися.

00:19:16.100 --> 00:19:20.800
Багато хто намагається обійти це, ділячись обліковими даними користувачів між середовищами.

00:19:21.060 --> 00:19:23.960
Вони вважають, якщо використовувати той самий аккаунт або пароль,

00:19:23.960 --> 00:19:27.540
що створив підключення в розробці, можливо, воно просто запрацює в продакшні.

00:19:27.540 --> 00:19:32.600
Реальність така, що це створює купу проблем від відмови у правах до спрацювання аудиту відповідності.

00:19:32.740 --> 00:19:36.400
Власні настанови Microsoft чіткі, використання особистих облікових даних користувачів

00:19:36.400 --> 00:19:39.080
для автоматизованих розгортень не є життєздатним або безпечним.

00:19:39.240 --> 00:19:42.140
Це ставить вашу автоматизацію в залежність від скидання паролів

00:19:42.140 --> 00:19:44.640
і може залишити нечіткий слід у журналах аудиту.

00:19:44.840 --> 00:19:48.580
Відсутня чітка підзвітність і згодом права доступу блокують конвейер,

00:19:48.580 --> 00:19:52.760
коли початкового користувача позначають, видаляють або він втрачає доступ.

00:19:52.760 --> 00:19:55.580
Час звернутися до сервісних принципалів Service Principles.

00:19:55.740 --> 00:19:59.760
Якщо ви з ними не працювали, уявіть сервісний принципал як цифрову додаткову пару рук,

00:19:59.920 --> 00:20:01.660
спеціально створену для автоматизації.

00:20:01.860 --> 00:20:07.120
На відміну від звичайного користувача, сервісний принципал прив'язаний до реєстрації додатка в Azure ID,

00:20:07.340 --> 00:20:08.460
а не до реальної людини.

00:20:08.640 --> 00:20:12.580
Ви надаєте йому мінімальні дозволи, необхідні для виконання ваших завдань з розгортання.

00:20:12.580 --> 00:20:14.980
Це звучить просто, але віддача величезна.

00:20:15.140 --> 00:20:19.120
Замість того, щоб покладатися на користувача, який може піти з організації чи змінити посаду,

00:20:19.120 --> 00:20:22.040
розгортання залишаються послідовними, контрольованими та відстежуваними.

00:20:22.180 --> 00:20:25.560
Кожне середовище отримує доступ лише до потрібних підключень і ресурсів,

00:20:25.640 --> 00:20:28.380
а всі зміни реєструються під цим обліковим записом робота.

00:20:28.560 --> 00:20:31.340
Коли щось йде не так, у вас залишається чіткий контрольний журнал,

00:20:31.440 --> 00:20:34.560
і ви не залишаєтеся з покинутими потоками, які нікому виправити.

00:20:34.560 --> 00:20:40.240
Щодо проблеми зі ставлення конекторів, подумайте, що стається, коли середовища починають відрізнятися.

00:20:40.400 --> 00:20:43.700
Можливо, команда розробників отримала схвалення на новий власний конектор.

00:20:43.700 --> 00:20:46.200
Припустімо, він звертається до пісочниці Арі.

00:20:46.320 --> 00:20:49.780
Коли настає час переходу до продуктивного середовища, цей конектор не лише зникне.

00:20:49.920 --> 00:20:52.820
Можливо, політики безпеки даних організації його навіть не дозволять.

00:20:52.960 --> 00:20:58.260
Якщо забути переналаштувати зі ставлення, програма звернеться до неправильної кінцевої точки або взагалі зламається.

00:20:58.340 --> 00:21:01.360
Нещодавно я бачив, як це боляче вдарило по одній медичній групі.

00:21:01.500 --> 00:21:05.220
Одне пропущене зі ставлення конектора призвело до використання тестових даних у продуктивному середовищі,

00:21:05.220 --> 00:21:07.480
що ледь не спричинило інцидент із порушенням відповідності.

00:21:07.600 --> 00:21:10.920
Їхній автоматизований конвейер експортував усе, як планувалося,

00:21:11.000 --> 00:21:15.140
але посилання на конектор у рішенні все ще вказувало на стару тестову базу даних,

00:21:15.240 --> 00:21:19.580
яку Pava Platform не позначила, поки реальні дані не почали текти не тими каналами.

00:21:19.800 --> 00:21:22.960
Змінні середовища допомагають полегшити частину цих проблем.

00:21:23.180 --> 00:21:25.840
На відміну від жорсткого кодування кінцевих точок або ключів Арі,

00:21:25.920 --> 00:21:29.440
змінні середовища дозволяють відокремити те, що змінюється залежно від середовища,

00:21:29.440 --> 00:21:30.960
від того, що залишається незмінним.

00:21:31.120 --> 00:21:35.780
Ви можете замінювати кінцеві точки, ключі Арі чи інші секрети під час кожного розгортання,

00:21:35.920 --> 00:21:37.580
не переписуючи програму чи потік.

00:21:37.740 --> 00:21:41.360
Наприклад, потік, що працює з таблицею Dataverse для розробки,

00:21:41.540 --> 00:21:44.620
можна при імпорті переналаштувати на продуктивну таблицю,

00:21:44.760 --> 00:21:47.800
просто змінивши змінну середовища під час розгортання.

00:21:47.980 --> 00:21:50.440
Конвейери GitHub Actions роблять це реальним.

00:21:50.620 --> 00:21:53.740
Кожне завдання може вставити правильне значення в потрібний момент.

00:21:53.900 --> 00:21:55.960
Але навіть тут дисципліна – це головне.

00:21:55.960 --> 00:22:00.220
Забудьте оновити змінну або дозвольте секретам витокнути між середовищами,

00:22:00.340 --> 00:22:02.840
і ваш робочий процес раптово стане вразливим.

00:22:03.020 --> 00:22:06.820
Microsoft наголошує на необхідності ретельного обмеження області секретів

00:22:06.820 --> 00:22:09.380
та усвідомленого зіставлення посилань на конектори.

00:22:09.560 --> 00:22:13.340
Їхні політики DLP, запобігання втраті даних, існують недаремно,

00:22:13.480 --> 00:22:16.400
щоб конфіденційна інформація не блукала між середовищами

00:22:16.400 --> 00:22:18.320
і не з'являлася в недозволених місцях.

00:22:18.500 --> 00:22:21.960
Якщо ви спробуєте обійти це через спільне використання змінних чи підключень,

00:22:21.960 --> 00:22:26.460
ви зіткнетеся з проблемами корпоративної безпеки чи контролю відповідності.

00:22:26.600 --> 00:22:30.040
Важливіше те, що ви втрачаєте передбачуваність, адже зникає межа між тим,

00:22:30.180 --> 00:22:33.180
що призначено для розробки, тестування чи продуктивного використання.

00:22:33.400 --> 00:22:36.760
Важко переоцінити користь, яку ви отримуєте, коли робите все правильно.

00:22:37.020 --> 00:22:40.060
Сервісні принципи в поєднанні з добре налаштованими змінними середовища

00:22:40.060 --> 00:22:42.740
та правильно зіставленими конекторами трансформують ваш конвейер.

00:22:42.880 --> 00:22:44.880
Ваші розгортання стають передбачуваними.

00:22:45.060 --> 00:22:47.820
Коли щось ламається, ви маєте чіткий ланцюг відповідальності

00:22:51.960 --> 00:22:55.700
Аудитори можуть відстежити зміни і немає жодних несподіванок,

00:22:55.840 --> 00:22:57.700
коли хтось звільняється або змінює паролі.

00:22:57.840 --> 00:23:01.460
Все зводиться до того, щоб ставитися до секретів, конекторів та сервісних принципів

00:23:01.460 --> 00:23:02.580
як до важливих елементів.