Основи 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 і Microsoft Dataverse а також з метою навчання. Середовище розробника — це середовище з одним користувачем, яке не можна використовувати для запуску або спільного використання виробничих програм.
За замовчуванням Одне середовище за замовчуванням автоматично створюється для кожного клієнта та спільно використовується всіма користувачами в цьому клієнті. Цей клієнт ідентифікує споживача, який може мати одну або кілька зв’язаних із ним передплат і служб Microsoft. Щоразу, коли новий користувач підписується на Power Apps, він автоматично додається до ролі розробника в середовищі за замовчуванням. Середовище за замовчуванням створюється в регіоні, найближчому до регіону Microsoft Entra клієнта за замовчуванням, і має назву: "ім’я клієнта (за{Microsoft Entra замовчуванням)"}
Створюйте та використовуйте правильне середовище для певної цілі, наприклад розробки, тестування або виробництва.
Додаткові відомості про роботу із середовищами: Огляд середовищ.
Кому надати доступ?
Визначайте та керуйте безпекою своїх ресурсів і даних у програмі Microsoft Dataverse. Microsoft Power Platform надає ролі адміністратора на рівні середовища для виконання завдань. Dataverse включає ролі безпеки, які визначають рівень доступу до програм, компонентів програм і ресурсів, який мають розробники програм і користувачі в Dataverse.
| Призначення середовища | Ролі, які мають доступ | Примітки |
|---|---|---|
| Розробка | Розробники та розробники програм. | Користувачі програм не мають доступу. Для створення ресурсів розробникам потрібна принаймні роль безпеки «Відповідальна особа для середовища». |
| Перевірити | Адміністратори та люди, що виконують тестування. | Розробники програм, розробники та користувачі виробничих програм не повинні мати доступу. Тестові користувачі повинні мати достатньо прав лише для виконання тестування. |
| Виробництво | Адміністратори та користувачі програм. Користувачам потрібно мати достатньо прав для лише виконання завдань для програм, які вони використовують. | Розробники та розробники програм не повинні мати доступ або повинні мати лише права на рівні користувача. |
| За замовчуванням | За замовчуванням кожен користувач у клієнті може створювати та змінювати програми в середовищі Dataverse за замовчуванням, в якому є база даних. | Настійно рекомендуємо створити середовище для певної мети, а також надати відповідні ролі та права лише тим людям, яким вони потрібні. |
Додаткові відомості:
- Огляд середовищ
- Керування доступом користувачів до середовищ: групи безпеки та ліцензії
- Створення облікових записів користувачів і призначення їм ролей безпеки
- Створення середовищ
Рішення
Рішення використовуються для транспортування програм і компонентів з одного середовища в інше або застосування набору настроювань до наявних програм.
Рішення мають зазначені нижче функції.
Вони включають метадані та певні сутності з даними конфігурації. Рішення не містять жодних бізнес-даних.
Вони можуть містити багато різних компонентів Microsoft 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 надає робочим групам підтримки послуги розробників для планування роботи, співпраці в розробці коду, та створення та розгортання програм.
Щоб почати роботу, вам потрібні зазначені нижче елементи.
Обліковий запис GitHub, в якому можна створити сховище. Якщо у вас немає такого облікового запису, можна створити його безкоштовно.
Організація Azure DevOps. Якщо у вас немає такого облікового запису, можна створити його безкоштовно.
Додаткові відомості: Створення першого процесу
Ліцензування
Щоб створити або змінити програми та потоки за допомогою Power Apps і Power Automate відповідно, користувачі повинні мати ліцензію на користувача для Power Apps або Power Automate або відповідну ліцензію програми Dynamics 365. Додаткову інформацію див. в огляді ліцензування для Microsoft Power Platform. Крім того, рекомендуємо звернутися до представника бізнес-партнера Microsoft для обговорення ваших потреб у ліцензуванні.
Зауваження щодо ALM
Якщо розглядати ALM як невід’ємну частину створення програм на Microsoft Power Platform, вона може значно покращити швидкість, надійність програми та зручність користування для користувачів. Вона також гарантує, що численні розробники (як традиційні розробники, що пишуть код, так і розробники-аматори) можуть спільно брати участь у програмі, яка створюється.
Ознайомтеся із зазначеними нижче статтями, які описують деякі елементи, які необхідно врахувати на початку створення будь-якої програми.