Поділитися через

Основи ALM за допомогою Microsoft Power Platform

  • Стаття

У цій статті описано компоненти, засоби та процеси, необхідні для впровадження керування життєвим циклом програм (ALM).

Середовища

Середовища – це простір для зберігання, упорядкування й надсилання даних, програм і бізнес-процесів організації. Вони також служать контейнерами для розділення програм, які можуть мати різні ролі, вимоги до безпеки або цільові аудиторії. У кожного середовища може бути лише одна база даних Microsoft Dataverse. Додаткові відомості: Огляд середовищ

Важливо

Під час створення середовища можна інсталювати такі програми Dynamics 365, як Dynamics 365 Sales і Dynamics 365 Marketing. У цей час важливо визначити, чи потрібні ці програми чи ні, оскільки їх не можна видалити або встановити пізніше. Якщо ви не створюєте рішення на основі цих програм та вони не знадобляться в майбутньому, рекомендовано їх не інсталювати в середовищах. Це допомагає уникнути ускладнень залежностей під час розподілу рішень між середовищами.

Типи середовищ, що використовуються в ALM

За допомогою центру адміністрування Power Platform можна створити зазначені нижче типи середовищ Power Platform.

  • Пісочниці. Середовище пісочниці – це будь-яке невиробниче середовище Dataverse. Унаслідок відокремлення від виробничого середовища ізольоване середовище дає змогу безпечно розробляти й тестувати зміни в програмах з низьким ризиком. Ізольовані середовища містять можливості, які можуть бути шкідливими у виробничому середовищі, наприклад операції скидання, видалення та копіювання. Додаткові відомості: Керування ізольованими середовищами
  • Виробництво. Середовище, у якому програми та інше програмне забезпечення вводяться в експлуатацію за призначенням.
  • Забудовник (офіційно називається Спільнота). Середовище розробника — це середовище з одним користувачем, яке не можна використовувати для запуску або спільного використання виробничих програм. План спільноти Power Apps надає доступ до преміум-функцій Power Apps, Dataverse і Power Automate для індивідуального використання. Цей план в першу чергу призначений для створення та тестування за допомогою Power Apps, Power Automate, а Dataverse також для навчальних цілей.
  • За замовчуванням. Для кожного клієнта автоматично створюється одне середовище за замовчуванням, до якого надається спільний доступ для всіх користувачів у цьому клієнті. Цей клієнт ідентифікує споживача, який може мати одну або кілька зв’язаних із ним передплат і служб Microsoft. Щоразу, коли новий користувач реєструється Power Apps, він автоматично додається до ролі Maker середовища стандартного середовища. Середовище за замовчуванням створюється в найближчому до стандартного регіону Microsoft Entra клієнта і має назву: "{Microsoft Entra ім’я} клієнта (за замовчуванням)"

Створюйте та використовуйте правильне середовище для певної цілі, наприклад розробки, тестування або виробництва.

Щоб дізнатися більше про середовища, перейдіть до розділу Огляд середовищ.

Кому надати доступ?

Визначайте та керуйте безпекою своїх ресурсів і даних у. Dataverse Power Platform Надає ролі адміністратора на рівні середовища для виконання завдань. Dataverse включає ролі безпеки, які визначають рівень доступу до програм, компонентів програм і ресурсів, який мають розробники програм і користувачі в Dataverse.

Природоохоронне призначення Ролі, які мають доступ Коментарі
Розробка Розробники та розробники програм. Користувачі програм не мають доступу. Для створення ресурсів розробникам потрібна принаймні роль безпеки «Відповідальна особа для середовища».
Перевірити Адміністратори та люди, що виконують тестування. Розробники програм, розробники та користувачі виробничих програм не повинні мати доступу. Тестові користувачі повинні мати лише привілеї для виконання тестування.
Виробниче Адміністратори та користувачі програм. Користувачі повинні мати лише доступ для виконання своїх завдань для програм, які вони використовують. Розробники та розробники програм не повинні мати доступ або повинні мати лише права на рівні користувача.
За замовчуванням За замовчуванням кожен користувач у клієнті може створювати та змінювати програми в середовищі Dataverse за замовчуванням, в якому є база даних. Настійно рекомендуємо створити середовище для певної мети, а також надати відповідні ролі та права лише тим людям, яким вони потрібні.

Додаткові відомості:

Рішення

Рішення використовуються для транспортування програм і компонентів з одного середовища в інше або застосування набору настроювань до наявних програм.

Рішення мають зазначені нижче функції.

  • Вони включають метадані та певні таблиці з даними конфігурації. Рішення не містять жодних бізнес-даних.
  • Вони можуть містити багато різних Power Platform компонентів, таких як програми на основі моделі, програми для полотна, карти сайтів, потоки, таблиці, форми, спеціальні з’єднувачі, веб-ресурси, варіанти, діаграми та стовпці. Зауважимо, що не всі таблиці можуть бути включені в розчин. Наприклад, системні таблиці «Користувач програми», «Настроюваний API» і «Параметр організації» не можна додати до рішення.
  • Вони упаковані як одиниця для експорту та імпорту до інших середовищ, або проаналізовані та зареєстровані у системі керування вихідним кодом як вихідний код для ресурсів. Рішення також використовуються для застосування змін до наявних рішень.
  • Керовані рішення використовуються для розгортання до будь-якого середовища, яке не є середовищем розробки для цього рішення. Це включає ознайомлювальні середовища, середовища для тестування на прийнятність для користувачів (UAT), середовища для тестування інтеграції систем (SIT), а також виробничі середовища. Керовані рішення можна обслуговувати (оновлювати, виправляти та видаляти) незалежно від інших керованих рішень у середовищі. В роботі з ALM рекомендується створювати керовані рішення сервером збірок і вважати їх артефактом збірки.
  • Оновлення для керованого рішення, які розгортаються в попередню версію керованого рішення. Це не призводить до створення додаткового шару рішення. Не можна видаляти компоненти за допомогою оновлення.
  • Виправлення містить лише зміни, внесені до основного керованого рішення. Ви повинні використовувати лише виправлення під час створення невеличких оновлень (аналогічно до поточного виправлення), і можливо, вам буде потрібно видалити його. Коли виправлення імпортуються, вони нашаровуються на головне рішення. Не можна видаляти компоненти за допомогою виправлення.
  • Під час оновлення рішення інсталюється новий шар рішення безпосередньо над базовим шаром і всіма наявними виправленнями.
    • Використання оновлень рішення передбачає видалення всіх наявних виправлень і базового шару.
    • Оновлення рішення видаляє компоненти, які існували, але більше не входять до оновленої версії.

Додаткові відомості: Концепція рішення

Керування вхідним кодом

Керування вхідним кодом, також відомий як керування версіями, — це система, яка підтримує та надійно зберігає ресурси розробки програмного забезпечення та відстежує зміни в цих ресурсах. Відстеження змін особливо важливе, коли кілька розробників і розробників програм працюють над одним набором файлів. Система керування вхідним кодом також дає змогу відкотити зміни або відновити видалені файли.

Система керування вхідним кодом допомагає організаціям досягти справного ALM, оскільки ресурси, що зберігаються в системі керування вхідним кодом, є «єдиним джерелом істини» або, іншими словами, єдиною точкою доступу та модифікації для ваших рішень.

Стратегія відгалуження та злиття

Майже кожна система керування вхідним кодом має форму підтримки відгалуження та об’єднання. Відгалуження означає, що ви відхиляєтеся від основної лінії розвитку та продовжуєте роботу, не змінюючи основну лінію. Процес злиття складається з об’єднання однієї гілки в іншу, наприклад, наприклад з гілки розробки до гілки головної лінії. Деякі поширені стратегії відгалуження — це відгалуження на основі каналів зв’язку, відгалуження випусків і відгалуження функцій. Додаткові відомості: Впровадження стратегії відгалуження Git

Процес керування вхідним кодом за допомогою рішення

Існує два основні шляхи, які можна використовувати під час роботи з рішеннями в системі керування вхідним кодом.

  • Експортуйте некероване рішення та розмістіть його як нерозпаковане в системі керування вхідним кодом. Процес створення імпортує запаковане рішення як некероване до тимчасового середовища збірки (ізольоване середовище). Потім експортуйте це рішення як кероване і збережіть його як артефакт збірки в системі керування вхідним кодом.
  • Експортуйте рішення як некероване, а також експортуйте це рішення як кероване і розмістіть обидва у вихідній системі керування вхідним кодом. Хоча для цього методу не потрібне середовище створення, він вимагає підтримки двох копій усіх компонентів (одну копію всіх некерованих компонентів із некерованого рішення та одну копію всіх керованих компонентів із керованого рішення).

Контроль джерела за допомогою розчину.

Додаткові відомості: Завдання інструментів створення

Автоматизація

Автоматизація — це ключова частина життєвого циклу програм, яка покращує продуктивність, надійність, якість та ефективність ALM. Засоби та завдання автоматизації використовуються для перевірки, експорту, пакування, розпакування та експорту рішень, а також створення та скидання ізольованих середовищ.

Додаткові відомості: Що таке інструменти Microsoft Power Platform Build Tools?

Групова розробка за допомогою спільного керування вхідним кодом

Важливо врахувати, як ви і ваша група розробників будуть працювати разом, щоб створити проект. Розбивання ізольованих даних і заохочення переглядів і розмов може дати вашій робочій групі можливість створити кращу програму. Деякі інструменти та робочі цикли (наприклад, надані в Git, GitHub, і Azure DevOps) призначені для безпосередньої мети поліпшення спілкування та якості програмного забезпечення. Зверніть увагу, що робота з конфігураціями в системі рішень може створити проблеми для розвитку робочої групи. Організації мають упорядковувати зміни від кількох розробників, щоб уникнути конфліктів злиття наскільки це можливо, оскільки системи керування вхідним кодом мають обмеження на виконання злиття. Рекомендуємо уникати ситуацій, коли кілька користувачів змінюють складні компоненти (наприклад форми, цикли та компоновані програми) одночасно.

Додаткові відомості: Сценарій 5. Підтримка командної розробки

Безперервна інтеграція та розгортання

Можна використовувати будь-яку систему керування вхідним кодом і створювати процес для початку для безперервної інтеграції та безперервного розгортання (CI/CD). Однак це керівництво стосується GitHub та Azure DevOps. GitHub — платформа для розробки, що використовується мільйонами розробників. Azure DevOps надає робочим групам підтримки послуги розробників для планування роботи, співпраці в розробці коду, та створення та розгортання програм.

Щоб почати роботу, вам потрібні зазначені нижче елементи.

Додаткові відомості: Створення першого процесу

Ліцензування

Щоб створювати або редагувати застосунки та потоки за допомогою Power Apps і Power Automate, відповідно, користувачі повинні мати ліцензію для кожного користувача або Power Apps Power Automate відповідну ліцензію на програму Dynamics 365. Щоб дізнатися більше, перейдіть до розділу Огляд ліцензування для Microsoft Power Platform. Крім того, рекомендуємо звернутися до представника бізнес-партнера Microsoft для обговорення ваших потреб у ліцензуванні.

Зауваження щодо ALM

Якщо розглядати ALM як невід’ємну частину створення програм на Microsoft Power Platform, вона може значно покращити швидкість, надійність програми та зручність користування для користувачів. Вона також гарантує, що численні розробники (як традиційні розробники, що пишуть код, так і розробники-аматори) можуть спільно брати участь у програмі, яка створюється.

Ознайомтеся із зазначеними нижче статтями, які описують деякі елементи, які необхідно врахувати на початку створення будь-якої програми.