Стратегія щодо середовищ для ALM

Щоб стежити за принципами керування життєвим циклом програм (ALM), знадобляться окремі середовища для розробки програм і виробництва. Хоча можна виконувати базове ALM лише з окремими виробничими середовищами та середовищами розробки, рекомендуємо також підтримувати принаймні одне ознайомлювальне середовище, яке існує окремо від середовища розробки та виробничого середовища. Якщо ви маєте окреме ознайомлювальне середовище, ви можете виконати комплексну перевірку, яка включає розгортання рішень і тестування програм. Деякі організації також можуть потребувати більше середовищ для тестування на прийнятність для користувачів (UAT), тестування інтеграції систем (SIT) і навчання.

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

Кожна організація унікальна, тому уважно врахуйте потреби середовища своєї організації.

Середовища розробки

Слід відповісти на зазначені нижче запитання.

• Скільки середовищ розробки мені потрібно?
  • Додаткові відомості: Огляд середовищ
• Як можна автоматично підготувати середовища з вихідного коду?
  • Додаткові відомості: Microsoft Power Platform Build Tools для Azure DevOps
• Які залежності існують в моїх середовищах?
  • Додаткові відомості: Багатошарові рішення та залежності

Інші середовища

Крім того, слід відповісти на таке запитання: «Які типи середовищ, не призначених для розробки, мені потрібні?»

Наприклад, окрім виробничого середовища, можуть знадобитися окремі ознайомлювальні середовища, середовища UAT, SIT і невиробничі середовища. Зверніть увагу, будь-яка практика справного ALM як мінімум має включати використання ознайомлювального середовища до розгортання будь-чого у виробничому середовищі. Воно забезпечить місце для тестування вашої програми та можливість тестування самого розгортання.

Докладніше див. у розділі: Створення стратегії середовища для Microsoft Power Platform

Зауваження щодо мультирегіональності

Середовища Power Platform дотримуються певного розкладу оновлення служб, оскільки середовища оновлюються в усьому світі. Загалом існує шість станцій, які визначаються географічним розташуванням. Оновлення служб застосовуються послідовно для кожної станції. Тобто, оновлення служб станції 2 відбувається раніше за оновлення станції 3. Отже, середовища на різних станціях зазвичай можуть мати різні версії на певний момент часу. Щоб отримати додаткові відомості про розклад оновлення служб середовища, див. Випущені версії Microsoft Dataverse

Імпорт рішення та версія середовища

За наявності кількох середовищ в різних регіонах важливо розуміти наведені нижче фактори під час імпортування рішення.

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

Приклад успішного налагодження середовища за допомогою станцій оновлення служб

Уявіть, що у вас є робочі середовища в Канаді та Сполучених Штатах. У такому разі середовища розробки має бути розташовано в Північній Америці (станція 5), а не в Канаді (станція 2). Відтак середовища розробки завжди матимуть таку саму або попередню версію за виробничі середовища, що зменшить конфлікти версій під час імпорту рішень.

Див. також

Концепції рішень