Latest / M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською / ALM для Power Platform з GitHub Actions: вихідний код, збірка, тести й розгортання без вгадування (ШІ-дубляж)

Transcript

ALM для Power Platform з GitHub Actions: вихідний код, збірка, тести й розгортання без вгадування (ШІ-дубляж) · M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською

• 0:00
  Готові до 10-х днів Microsoft 365, Co-Pilot, She, Azure та людей, які формують майбутні роботи.
• 0:07
  Цього січня M365Con повертається, і ми стаємо ще масштабнішими.
• 0:12
  Приєднуйтесь до нас для живих сесій, реальних демо-версій та практичних знань від MVP та галузевих експертів з усього світу.
• 0:18
  Жодних загальних слайдів, жодних нескінчених модних слів.
• 0:22
  Ми вирішуємо реальні завдання Co-Pilot Studio, She-агенти, Fabric, безпека, управління та автоматизація.
• 0:29
  Незалежно від того, чи ви IT-фахівець, розробник чи бізнес-лідер, для вас знайдуться сесії.
• 0:35
  За 10 повних днів ви зможете дослідити різні технології та приєднатися до глобальної спільноти.
• 0:40
  Дивіться наживо та принесьте практичні ідеї у свою організацію.
• 0:44
  Січень 2027 – 10 днів, одна спільнота Microsoft. Реєстрація вже відкрита.
• 0:52
  Забронюйте своє місце сьогодні.
• 0:54
  Приєднуйтесь на M365Con.net і побачимося в січні.
• 1:04
  Ви коли-небудь відчували, що ваші розгортання Pava Platform – це чорна скринька.
• 1:08
  Ви випускаєте оновлення, затамовуєте подих і сподіваєтесь, що воно запрацює у розробці, тестуванні та продакшені.
• 1:14
  А що, якби ви могли контролювати кожен етап процесу ELM за допомогою GitHub Actions без припущень та ручних правок?
• 1:21
  Давайте відкриємо завісу того, як компоненти, контроль версій, автоматизація та безпечні змінні насправді взаємодіють.
• 1:28
  Це не просто черговий огляд. Це те, про що мовчать більшість інструкцій, щоб ваше наступне розгортання було передбачуваним.
• 1:35
  Отже, чому ELM у Pava Platform здається лабіринтом?
• 1:38
  Якщо ви хоч раз намагалися розгорнути Pava App і відчували невпевненість, ніби щось важливе вислизнуло, ви не одні.
• 1:45
  На папері Pava Platform обіцяє легку розробку додатків, але за цим дружнім фасадом ELM зовсім непроста.
• 1:53
  Веб-додаток розгортається з контролю версій, збирається в конвоїрі та потрапляє у продакшен з передбачуваною поведінкою.
• 2:00
  Pava Platform, навпаки, ховає логіку в інтерфейсах, екранах підключень та формулах, які не видно в репозиторіях DIT.
• 2:07
  Тож, навіть якщо ви виконуєте всі кроки з інструкцій для адміністраторів, ви все одно стикаєтеся зі збоями, коли важливі для бізнесу додатки залишають розробку.
• 2:17
  Давайте поглянемо на ELM-посібники, які існують сьогодні.
• 2:20
  Більшість з них показують лише експорт в ZIP-архіву рішення та його імпорт в інше місце.
• 2:24
  Досить просто, чи не так? Але це лише технічний бік справи.
• 2:27
  Вони пропускають відповідь на питання «Чому?»
• 2:29
  Чому розгортання Pava Platform ламається там, де звичайний код працює бездоганно?
• 2:33
  Ось що спричиняє нескінченну плутанину.
• 2:36
  Корінь проблеми в тому, що логіка, підключення та конфігурації в Pava Apps зберігаються не так, як класичний код.
• 2:42
  Ви не просто клонуєте репозиторі і спостерігаєте за модульними тестами.
• 2:45
  Тож, коли ви намагаєтеся перенести свій додаток, усі ці приховані залежності, підключення до Outlook, SharePoint, власні ARRI не завжди акуратно вміщуються в цей ZIP-файл.
• 2:54
  Ось такий сценарій.
• 2:55
  Ви запускаєте новий блискучий додаток у середовищі розробки, експортуєте рішення, імпортуєте в тестування і раптом потік перестає працювати.
• 3:02
  Це рідко буває, просто проблемою з файлом.
• 3:04
  Натомість підключення вказують не туди, права доступу не збігаються, а політики даних блокують з'єднання, які ще хвилину тому працювали нормально.
• 3:11
  Тепер уявіть, що ви робите це для трьох середовищ – розробки, тестування та продуктового, де кожне використовує різні підключення, політики захисту даних, схвалювачів та адміністративні обмеження.
• 3:21
  Ви не зможете просто скопіювати та вставити рішення, щоб усе запрацювало.
• 3:24
  Дослідження підтверджують те, що адміністратори та розробники бачать щотижня.
• 3:27
  Більшість невдалих розгортань у Pava Platform стаються через відсутні посилання на конектори або неправильне керування змінними середовища.
• 3:34
  Відсутність посилання на конектор означає лише те, що потік не може знайти своє підключення до Outlook чи Dataverse.
• 3:40
  Тому, як тільки ви намагаєтеся запустити додаток чи потік в іншому середовищі, ви отримуєте помилки під час виконання.
• 3:47
  І оскільки змінні середовища в Pava Platform працюють інакше, ніж в інших продуктах Microsoft 365, вони ставлять у глухий кут навіть досвідчених розробників.
• 3:55
  Змінні мають обробляти кінцеві точки, ключі або конфігурації, специфічні для орендаря.
• 4:00
  Але якщо хтось забуде оновити їх після експорту рішення, навіть безневинна на вигляд зміна може зламати робочий додаток.
• 4:06
  Багато хто з нас спочатку потрапляє в ту саму пастку.
• 4:09
  Можна подумати, що експорт зі IP-файлу рішення містить усе необхідне, але насправді він пропускає динамічні посилання на конектори.
• 4:14
  Наприклад, припустімо, у вас є додаток, який використовує HTTP-конектор для стороннього сервісу в розробці.
• 4:19
  Коли ви імпортуєте його в тестування чи продуктив, саме цей екземпляр конектора буде відсутній.
• 4:24
  Посилання на конектор у вашому додатку вказує на відсутній об'єкт, і потоки в рішенні тихо ламаються,
• 4:30
  доки користувач чи адміністратор вручну не відтворить і не перепризначить підключення.
• 4:34
  Якщо у вас більше одного розробника чи адміністратора, ще легше втратити розуміння, яке посилання куди веде,
• 4:40
  і ніхто не хоче розбору польотів у стилі, а в розробці все працювало.
• 4:44
  Ще одна складність – суб'єкти служби – сервіс принципал.
• 4:47
  Більшість починають із використання облікових записів користувачів для експорту та імпорту рішень, бо так швидше розпочати.
• 4:53
  Але коли ви намагаєтеся автоматизувати це через GitHub Actions або будь-яку CI-систему,
• 4:57
  використання особистих облікових даних швидко веде в глухий кут.
• 5:00
  Ви зіткнетеся з обмеженнями прав доступу, іноді без чітких повідомлень про помилки,
• 5:03
  або навіть спровокуєте перевірки відповідності, оскільки виконуєте критичні розгортання через персональний аккаунт,
• 5:08
  а не через спеціально створений для автоматизації.
• 5:10
  Сервісні принципалі, по суті ідентифікатори додатків, створені в Azure ID, опрацьовують усі дозволи, логування та аудит, необхідні вашому конвоєру.
• 5:19
  Без них ваш ланцюжок автоматизації перетворюється на клаптик передачі завдань між людьми, і ви ніколи не знаєте, хто і що змінив.
• 5:25
  Контроль версій також стає непередбачуваним.
• 5:28
  У звичайному коді у вас є історія комітів та інструменти відстеження змін.
• 5:31
  Файли рішень Pava Platform – це лише знімки стану, що означає відсутність детального відстеження змін.
• 5:37
  Логіка, прихована у формулах екранів Canvas-додатків або в погано задокументованих потоках, невидима, доки ви не експортуєте її знову.
• 5:44
  Хтось змінює налаштування потоку в інтерфейсі і спробуйте зрозуміти, чому подальші середовища раптом поводяться інакше.
• 5:50
  У підсумку, управління ALM для Pava Platform нагадує складання пазла, де половини частин не вистачає або вони заховані під коробкою.
• 5:57
  Невидимі залежності, специфічні для середовища конектори та змінні, які неможливо побачити в коді, порушують звичний робочий процес розробника.
• 6:06
  І це ще до того, як ви зіткнетеся з тим, що продуктивні середовища майже завжди мають суворіші дозволи, інші політики даних та вимоги аудиту неочевидні під час розробки чи тестування.
• 6:16
  Але ось у чому перевага.
• 6:18
  Ця складність не випадкова.
• 6:20
  Є практична причина, чому Pava Platform обробляє джерела, змінні та конектори таким унікальним способом.
• 6:26
  Вона намагається дозволити бізнес-користувачам створювати потужні додатки, не переймаючись кодом.
• 6:32
  Побічним ефектом є те, що вам, як людині, яка налаштовує автоматизацію, потрібно стежити за тим, що приховано під капотом.
• 6:38
  Якщо ви знаєте, де проходять ці невидимі зв'язки, ви зможете виправити або уникнути більшості проблем, що гальмують ALM у Pava Platform.
• 6:46
  Якщо все це звучить як занадто багато справ одночасно, ви маєте рацію.
• 6:50
  Але є чотири стовпи ALM, які дійсно допомагають розплутати цей хаос.
• 6:53
  Джерело, збірка, тестування та розгортання.
• 6:56
  Кожен з них має свої особливості в Pava Platform, але разом вони повертають структуру в те, що інакше здається хаосом.
• 7:02
  Основна система ALM – джерело, збірка, тестування, розгортання.
• 7:05
  Щоразу, коли хтось просить конвейер Pava Platform, який просто працює, на думку спадають ці чотири старі стовпи ALM, джерело, збірка, тестування, розгортання.
• 7:15
  У традиційній розробці ви могли б робити це майже з заплющеними очима.
• 7:19
  Pava Platform не дозволяє вам так легко відбутися.
• 7:21
  Раптом, джерело вже не означає код.
• 7:24
  Це означає роботу з файлами рішень, експорту архівних пакетів із додатками, потоками та іноді конекторами, що вдають із себе частину джерела.
• 7:33
  Почнемо з основ, а потім розберемо, що робить кожен стовп таким дивним у цьому світі.
• 7:38
  Ви маєте свій ZIP-файл рішення.
• 7:40
  Це не код у звичному розумінні.
• 7:42
  Відкрийте його, і ви побачите файли XML та JSON, а не логіку, яку ви очікували б знайти в TypeScript чи C.
• 7:48
  Але це і є вихідний код для Pava Platform.
• 7:50
  Команди часто припускаються тут помило.
• 7:53
  Він здається портативним, доки ви не зрозумієте, що більшість змін, як от оновлення формули чи логіки потоку,
• 7:58
  стають помітними лише після експорту свіжого ZIP-архіву рішення.
• 8:02
  Тож так, ви можете версію оновити ці файли рішень у GIT, але якщо ви не будете дисципліновано експортувати їх після кожної важливої правки,
• 8:08
  ваша історія матиме серйозні прогалини.
• 8:10
  Тепер переходимо до конфігурації.
• 8:12
  Для звичайних програм ви можете зберегти рядки підключення у файлі конфігурації і на цьому завершити.
• 8:17
  Pava Platform приховано переносить дані, специфічні для середовища, всередину цих рішень.
• 8:21
  Це не лише змінні середовища, це посилання на конектори, динамічні кінцеві точки, ролі та дозволи, зібрані разом із бізнес-логікою.
• 8:29
  Якщо ви забудете оновити їх перед експортом із середовища розробки чи тестування, ви зафіксуєте посилання на неправильні ресурси.
• 8:36
  Я бачив, як команди сумлінно комітять свої ZIP-файли рішень, лише щоб після розгортання виявити,
• 8:41
  що половина програми досі звертається до датаверс середовища розробки, а не продуктового, бо ніхто не переналаштував посилання на конектори.
• 8:47
  Далі у нас етап збірки – білд. Слово «збірка» зазвичай викликає асоціації з компіляцією коду та спостереженням за зеленими галочками в CI-завданнях.
• 8:56
  У Pava Platform процес збірки полягає в збереженні ZIP-пакетів, перевірці схем та підтвердженні залежностей.
• 9:02
  У конвоєрі GitHub Actions завдання збірки бере ваш зафіксований файл рішення,
• 9:06
  а потім використовує Microsoft Pava Platform CLI для розпакування, перевірки та повторного пакування рішення.
• 9:11
  Етап перевірки – це те місце, де стається магія або хаос.
• 9:17
  Гірше того, якщо зміни у вашому потоці залежать від спеціального коннектора, якого немає в системі контролю версій,
• 9:24
  ваша збірка мовчки запакує щось неповне. Ось тут усе стає складним.
• 9:28
  Ці завдання збірки спрямовані не на компіляцію, а на забезпечення надійного експорту та гарантію того, що вміст готовий до випуску.
• 9:35
  Команди, які пропускають або поспішають із цим, швидко опиняються в ситуації, коли збірка технічно вдала,
• 9:41
  але в UIT або продакш не потрапляє продукт без половини потрібних функцій.
• 9:44
  Microsoft продовжує просувати ідею, що файли рішень роблять ALM портативним, але завжди є примітка.
• 9:50
  Портативність залежить від того, чи правильно налаштовані коннектори та чи встановлені ролі в різних середовищах.
• 9:55
  Тестування – це наступний етап.
• 9:57
  У конвоєрі веб-програми автоматизовані тести можуть включати модульні тести або перевірку інтерфейсу.
• 10:02
  Для PAWA платформ питання того, що вважати тестом, залишається відкритим.
• 10:06
  Іноді це перевірка рішення іншими словами, чи відкривається рішення і чи вирішуються ключові залежності.
• 10:12
  В іншому разі це запуск тестових потоків або перевірка того, чи відповідають коннектори в тестовому середовищі.
• 10:18
  Часто тестування є ручним, оскільки перевірка бізнес-логіки всередині Canvas-додатків ще не інтегрована в автоматизовані конвейери.
• 10:25
  Але ви можете автоматизувати перевірки для виявлення відсутніх коннекторів, валідації критичних потоків або навіть пінгу тестового середовища,
• 10:31
  щоб підтвердити роботу облікових даних.
• 10:33
  Розгортання лише посилює ці труднощі.
• 10:35
  Коли розгортається стандартний додаток, ви можете просто завантажити веб-артефакт у Azure.
• 10:40
  У Power Platform потрібно налаштовувати підключення, призначати дозволи оновлювати секрети, змінювати змінні середовища
• 10:45
  і нарешті запускати імпорт через суб'єкт службу, а не через звичайний обліковий запис.
• 10:49
  Інакше ви зіткнетеся з аудитами та відмовами у доступі.
• 10:53
  GitHub Actions може об'єднати цей процес, але лише якщо кожне завдання знає, на яке середовище спрямоване і які секрети використовувати.
• 11:00
  Я бачив, як команди намагалися прискорити це, використовуючи один набір облікових даних для розробки та продуктивного середовища,
• 11:06
  що веде до хаосу, витоку даних, помилок доступу та проблем, які з'являються лише в одному середовищі.
• 11:10
  Візьмемо реальну команду, з якою я працював кілька місяців тому.
• 11:13
  Вони робили майже все правильно – стандартні діт-репозиторії, версійні зіп-архіви рішень та чітке розгалуження.
• 11:18
  Але їхній конвейер завжди зупинявся під час розгортання.
• 11:21
  Чому?
• 11:21
  Вони ніколи не змінювали змінні середовища і не оновлювали посилання на конектори перед імпортом у продуктивне середовище.
• 11:26
  Це призводило до того, що ключові потоки вказували на неправильні кінцеві точки, а дані потрапляли не в ті системи.
• 11:31
  Вирішенням стали скриптові кроки в їхньому діт-хаб-конвейері, які змінювали змінні та перепризначали кожен конектор під час імпорту.
• 11:38
  Власні рекомендації Microsoft говорять про це прямо.
• 11:40
  Ви користовуйте файли рішень для переміщення об'єктів між середовищами, але завжди опрацьовуйте посилання на конектори та зіставлення ролей як частину вашого конвейера.
• 11:48
  Вони зазначають, що ігнорування цих кроків – це головна причина поломок додатків, особливо коли середовища стають більш захищеними.
• 11:54
  Якщо розглядати вихідний код, збірку, тестування та розгортання як взаємопов'язані частини, а не як ізольовані етапи,
• 12:00
  стає зрозуміло, чому багато спроби ALM провалюються і як можна реально усувати проблеми, а не просто сподіватися на успіх.
• 12:06
  Далі давайте розберемося, як GitHub Actions координує цей процес, тригери, розгалуження та розділення завдань,
• 12:13
  які роблять вашу автоматизацію PAVA Platform гнучкою та безпечною.
• 12:17
  GitHub Actions поєднуємо все разом за допомогою тригерів та завдань.
• 12:20
  Якщо ви чекали завершення конвейера GitHub Actions після оновлення свого PAVA App,
• 12:24
  ви вже знаєте, що автоматизація не означає миттєвість і точно не означає магію.
• 12:29
  Більшість команд стикаються з цією стіною відразу після захоплення від першого запуску робочого процесу.
• 12:33
  Ви налаштовуєте скрипт, підключаєте його до свого репозиторію і очікуєте,
• 12:38
  що кожен новий коміт буде чисто розгортатися в усіх середовищах.
• 12:41
  А потім настає реальність.
• 12:43
  Замість простого запуску сценарію, GitHub Actions використовує логічний ланцюжок,
• 12:47
  побудований навколо тригерів, завдань і передачі даних між середовищами.
• 12:51
  Саме цей порядок і структура не дають розгортанням перетворитися на клубок невдалих кроків і дивних помилок.
• 12:56
  Відправною точкою в цій системі є тригер.
• 12:59
  Більшість новачків створюють робочий процес, який запускається під час кожного пушу
• 13:04
  або коли запит на злиття потрапляє в головну гілку.
• 13:07
  На перший погляд, це виглядає як найкраща практика.
• 13:10
  Чому б не запускати конвейер щоразу, коли в роботі з'являються зміни?
• 13:12
  Ось у чому підвох.
• 13:14
  Коли ви встановлюєте тригер лише на головну гілку, усе спрямовується одним шляхом.
• 13:17
  А що, як зміни потрібно застосувати лише до середовища розробки, а не до тестового чи продуктового?
• 13:20
  Що, як ви готові до випуску в прод, але тест ще виконує перевірку?
• 13:24
  Команди, що використовують універсальні тригери, часто стикаються з проблемами,
• 13:28
  коли функції для розробки потрапляють у прод або тестові розгортання,
• 13:32
  раптово перезаписують налаштування продакшну.
• 13:35
  Ви можете розгалужувати робочі процеси для кожного середовища,
• 13:38
  дев, тест і прод, і налаштовувати для них дуже специфічні тригери.
• 13:42
  Наприклад, налаштуйте робочий процес, який запускається лише при пушах у гілку розробки,
• 13:47
  або інший процес, коли хтось робить злиття в гілку релізу продакшну.
• 13:50
  Це дає більше контролю та чітко розмежовує поточну роботу і робочі зміни,
• 13:54
  але багато команд ніколи не переглядають свої тригери після створення.
• 13:58
  Саме так секрети з одного середовища можуть просочитися в інше,
• 14:02
  а конфігурація для розробки випадково опинитися в продакшні.
• 14:05
  Одна команда, з якою я працював, намагалася виконувати весь свій ELM-процес через один робочий процес.
• 14:10
  Якийсь час усе було добре, поки хтось не помітив,
• 14:13
  що рядок підключення до робочої бази даних з'явився в середовищі розробки.
• 14:17
  Вони не усвідомлювали, що їхні секрети стають спільними для різних завдань.
• 14:21
  І як тільки код переміщувався між середовищами, ці секрети витікали разом із ним.
• 14:24
  Це не було очевидною критичною помилкою.
• 14:27
  Це відбувалося тихо.
• 14:28
  Такі витоки даних трапляються частіше, ніж ви думаєте,
• 14:30
  особливо якщо ви не налаштовуєте робочі процеси для розділення секретів і змінних середовища.
• 14:34
  Кожне завдання в робочому процесі GitHub Actions відповідає за чітко визначену частину процесу.
• 14:40
  Одне завдання може відповідати за експорт рішення з вихідного середовища.
• 14:44
  Інше займається перевіркою, розпакуванням, скануванням метаданих,
• 14:48
  перевіркою залежностей і наявністю посилань на конектори.
• 14:52
  Далі йде завдання, яке готує змінні середовища, адаптуючи рішення під цільове середовище.
• 14:58
  Останнє завдання запускає процес імпорту, використовуючи сервісні принципи для запису змін у потрібне середовище.
• 15:05
  Можна подумати, що змінні середовища та секрети – це прості заповнювачі,
• 15:09
  але на практиці вони є клеєм, що тримає все разом.
• 15:12
  Рядки, підключення, ключі АРІ, спільні паролі – усе це потрібно змінювати між завданнями,
• 15:16
  але вони ніколи не повинні виходити за межі встановлених кордонів.
• 15:20
  У Pava Platform ALM ви можете мати окреме підключення до Dataverse для кожного середовища
• 15:24
  або потребувати заміни кінцевих точок залежно від того, на який потік чи Pava App ви спрямовані.
• 15:29
  Якщо ви повторно використовуєте змінні або жорстко кодуєте секрети,
• 15:32
  ви отримуєте або ненадійний конвейер, або, що гірше, значні ризики для безпеки.
• 15:36
  Процес імпорту залежить від отримання секретів лише з відповідного сховища,
• 15:40
  щоб робоче середовище не наражалося на небезпеку через помилки в тестуванні чи розробці.
• 15:44
  Вдала ментальна модель для секретів у Dithub Actions – уявити,
• 15:47
  що кожне середовище має власне цифрове сховище, закриту скриньку, яку бачить лише потрібні завдання.
• 15:53
  Dithub надає вам точні засоби контролю.
• 15:55
  Ви можете обмежувати секрети середовищами, щоб завдання, яке виконується в розробці,
• 15:59
  не мало доступу до облікових даних робочого середовища і навпаки.
• 16:02
  Налаштуйте ці сховища, і навіть якщо хтось, хто коригує конвейер, спробує щось ризиковане,
• 16:07
  правила захисту середовища не дадуть помилці поширитися.
• 16:10
  Документація Microsoft і Dithub постійно наголошують на цьому.
• 16:13
  Вони рекомендують правила захисту середовища та суворе розмежування секретів,
• 16:17
  щоб зупинити витоки між середовищами ще до їх виникнення.
• 16:20
  Без такого захисту навіть найкраще розроблені робочі процеси ЕЛМ руйнуються.
• 16:24
  Уявіть робочий процес, що розгортається в робочому середовищі,
• 16:27
  але при цьому використовує рядок підключення для розробки
• 16:30
  або має тестове середовище з доступом до робочих даних.
• 16:32
  Це не завжди призводить до видимих поломок.
• 16:35
  Іноді це означає лише спрацювання прапорців відповідності
• 16:37
  або заповнення журналів прихованими помилками,
• 16:39
  які поступово накопичуються у більші проблеми.
• 16:41
  Ось чому розгалуження робочих процесів та розмежування секретів –
• 16:44
  це не просто складні теми.
• 16:45
  Це запобіжний захід, який не дає вашій автоматизації непомітно вийти з ладу.
• 16:49
  Також є сенс розділяти робочі процеси не лише за середовищем,
• 16:52
  а й за сферою відповідальності.
• 16:54
  Код, який експортує та перевіряє рішення,
• 16:56
  не повинен знати, як розгортати чи замінювати секрети.
• 16:59
  Якщо кожне завдання відповідає за одну частину головоломки,
• 17:03
  стає набагато легше виявити, де щось зламалося,
• 17:05
  відкотитися назад і перевірити зміни постфактум.
• 17:08
  Секрети залишаються у своїх сховищах,
• 17:10
  завдання дотримуються чітко визначених прав доступу,
• 17:12
  а збої в конвоєрі прямо вказують на ту частину, яку потрібно виправити.
• 17:16
  Розуміння того, як GitHub Actions передає роботу від одного завдання до іншого,
• 17:20
  зберігаючи при цьому секрети суворо обмеженими,
• 17:22
  а тригери – чітко визначеними,
• 17:24
  перетворює ALM зі сподіваного експерименту на надійну,
• 17:27
  безпечну та передбачовану практику.
• 17:29
  Ця сегментація робочих процесів – це не просто дотримання найкращих практик.
• 17:33
  Це те, що блокує тихі витоки безпеки та випадкові перезаписи,
• 17:37
  усуваючи цілий клас невидимих помилок,
• 17:39
  перш ніж вони почнуть шкодити вашим середовищам.
• 17:42
  Тепер, коли всі частини працюють злагоджено завдяки належним чинам
• 17:45
  налаштуваній автоматизації, настав час розв'язати іншу проблему.
• 17:49
  Конектори, сервісні принципалі та дрібні, але критичні пастки,
• 17:52
  що можуть зупинити ваше розгортання саме тоді, коли ви стаєте впевнені.
• 17:56
  Таємні сервісні принципалі та проблеми з конекторами.
• 18:00
  Якщо ви коли-небудь намагалися перенести Pava App або Flow з розробки в продакшні,
• 18:04
  ви знаєте цю історію.
• 18:05
  Все працює бездоганно в одному середовищі,
• 18:08
  а як тільки ви перемикаєтесь, все зупиняється або видає загадкові помилки підключення.
• 18:12
  Це не унікальна проблема конкретної команди.
• 18:15
  Кожен адміністратор Pava Platform рано чи пізно впирається в цю стіну.
• 18:19
  Корінь проблеми полягає в тому, як конектори та секрети поводяться за лаштунками.
• 18:24
  Ви не можете просто експортувати зіп-архів рішення з розробки
• 18:27
  і очікувати, що він запрацює де-інде,
• 18:29
  бо зв'язки, від яких він залежить, змінюються з кожним середовищем.
• 18:33
  Візьмемо для початку посилання на конектори.
• 18:35
  У Pava Platform Connector це ніколи не просто статичний набір даних,
• 18:39
  вшитий у ваш додаток.
• 18:40
  Він динамічний, змінюваний і часто унікальний для кожного середовища.
• 18:44
  Коли ви експортуєте своє рішення, посилання на конектори діють майже як закладки.
• 18:48
  Вони вказують на об'єкти підключення, які існують лише в тому середовищі, де вони були створені.
• 18:52
  Тому при імпорті в тестове або робоче середовище,
• 18:55
  ваш вишуканий HTTP endpoint або посилання на Dataverse не обов'язково відтворяться так само або взагалі.
• 19:00
  Ось тут команди і потрапляють у пастку.
• 19:03
  Якщо розробка використовує конектор для тестових даних,
• 19:07
  а та сама конфігурація не відображена в продакшні,
• 19:09
  ваш потік або додаток або тихо збоїть або зависає при першій спробі підключитися.
• 19:16
  Багато хто намагається обійти це, ділячись обліковими даними користувачів між середовищами.
• 19:21
  Вони вважають, якщо використовувати той самий аккаунт або пароль,
• 19:23
  що створив підключення в розробці, можливо, воно просто запрацює в продакшні.
• 19:27
  Реальність така, що це створює купу проблем від відмови у правах до спрацювання аудиту відповідності.
• 19:32
  Власні настанови Microsoft чіткі, використання особистих облікових даних користувачів
• 19:36
  для автоматизованих розгортень не є життєздатним або безпечним.
• 19:39
  Це ставить вашу автоматизацію в залежність від скидання паролів
• 19:42
  і може залишити нечіткий слід у журналах аудиту.
• 19:44
  Відсутня чітка підзвітність і згодом права доступу блокують конвейер,
• 19:48
  коли початкового користувача позначають, видаляють або він втрачає доступ.
• 19:52
  Час звернутися до сервісних принципалів Service Principles.
• 19:55
  Якщо ви з ними не працювали, уявіть сервісний принципал як цифрову додаткову пару рук,
• 19:59
  спеціально створену для автоматизації.
• 20:01
  На відміну від звичайного користувача, сервісний принципал прив'язаний до реєстрації додатка в Azure ID,
• 20:07
  а не до реальної людини.
• 20:08
  Ви надаєте йому мінімальні дозволи, необхідні для виконання ваших завдань з розгортання.
• 20:12
  Це звучить просто, але віддача величезна.
• 20:15
  Замість того, щоб покладатися на користувача, який може піти з організації чи змінити посаду,
• 20:19
  розгортання залишаються послідовними, контрольованими та відстежуваними.
• 20:22
  Кожне середовище отримує доступ лише до потрібних підключень і ресурсів,
• 20:25
  а всі зміни реєструються під цим обліковим записом робота.
• 20:28
  Коли щось йде не так, у вас залишається чіткий контрольний журнал,
• 20:31
  і ви не залишаєтеся з покинутими потоками, які нікому виправити.
• 20:34
  Щодо проблеми зі ставлення конекторів, подумайте, що стається, коли середовища починають відрізнятися.
• 20:40
  Можливо, команда розробників отримала схвалення на новий власний конектор.
• 20:43
  Припустімо, він звертається до пісочниці Арі.
• 20:46
  Коли настає час переходу до продуктивного середовища, цей конектор не лише зникне.
• 20:49
  Можливо, політики безпеки даних організації його навіть не дозволять.
• 20:52
  Якщо забути переналаштувати зі ставлення, програма звернеться до неправильної кінцевої точки або взагалі зламається.
• 20:58
  Нещодавно я бачив, як це боляче вдарило по одній медичній групі.
• 21:01
  Одне пропущене зі ставлення конектора призвело до використання тестових даних у продуктивному середовищі,
• 21:05
  що ледь не спричинило інцидент із порушенням відповідності.
• 21:07
  Їхній автоматизований конвейер експортував усе, як планувалося,
• 21:11
  але посилання на конектор у рішенні все ще вказувало на стару тестову базу даних,
• 21:15
  яку Pava Platform не позначила, поки реальні дані не почали текти не тими каналами.
• 21:19
  Змінні середовища допомагають полегшити частину цих проблем.
• 21:23
  На відміну від жорсткого кодування кінцевих точок або ключів Арі,
• 21:25
  змінні середовища дозволяють відокремити те, що змінюється залежно від середовища,
• 21:29
  від того, що залишається незмінним.
• 21:31
  Ви можете замінювати кінцеві точки, ключі Арі чи інші секрети під час кожного розгортання,
• 21:35
  не переписуючи програму чи потік.
• 21:37
  Наприклад, потік, що працює з таблицею Dataverse для розробки,
• 21:41
  можна при імпорті переналаштувати на продуктивну таблицю,
• 21:44
  просто змінивши змінну середовища під час розгортання.
• 21:47
  Конвейери GitHub Actions роблять це реальним.
• 21:50
  Кожне завдання може вставити правильне значення в потрібний момент.
• 21:53
  Але навіть тут дисципліна – це головне.
• 21:55
  Забудьте оновити змінну або дозвольте секретам витокнути між середовищами,
• 22:00
  і ваш робочий процес раптово стане вразливим.
• 22:03
  Microsoft наголошує на необхідності ретельного обмеження області секретів
• 22:06
  та усвідомленого зіставлення посилань на конектори.
• 22:09
  Їхні політики DLP, запобігання втраті даних, існують недаремно,
• 22:13
  щоб конфіденційна інформація не блукала між середовищами
• 22:16
  і не з'являлася в недозволених місцях.
• 22:18
  Якщо ви спробуєте обійти це через спільне використання змінних чи підключень,
• 22:21
  ви зіткнетеся з проблемами корпоративної безпеки чи контролю відповідності.
• 22:26
  Важливіше те, що ви втрачаєте передбачуваність, адже зникає межа між тим,
• 22:30
  що призначено для розробки, тестування чи продуктивного використання.
• 22:33
  Важко переоцінити користь, яку ви отримуєте, коли робите все правильно.
• 22:37
  Сервісні принципи в поєднанні з добре налаштованими змінними середовища
• 22:40
  та правильно зіставленими конекторами трансформують ваш конвейер.
• 22:42
  Ваші розгортання стають передбачуваними.
• 22:45
  Коли щось ламається, ви маєте чіткий ланцюг відповідальності
• 22:51
  Аудитори можуть відстежити зміни і немає жодних несподіванок,
• 22:55
  коли хтось звільняється або змінює паролі.
• 22:57
  Все зводиться до того, щоб ставитися до секретів, конекторів та сервісних принципів
• 23:01
  як до важливих елементів.