Основи на ALM с Microsoft Power Platform

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

Среди

Средите са място за съхранение, управление и споделяне на бизнес данните, приложенията и бизнес процесите на организацията. Те също служат като контейнери за отделни приложения, които могат да имат различни роли, изисквания за защита или целеви аудитории. Всяка среда може да разполага само с една база данни на Microsoft Dataverse. Повече информация: Общ преглед на средите

Видове среди, използвани в ALM

Като използвате Административен център на Power Platform, можете да създадете тези видове среди на Power Platform:

• Пясък. Среда в пясъчник е всяка непроизводствена среда на Dataverse. Изолиран от производството, средата в ограничителен режим е мястото за безопасно разработване и тестване на промени в приложението при нисък риск. Средата в ограничителен режим включва възможности, които биха били вредни в производствена среда, като например операции за нулиране, изтриване и копиране. Повече информация: Управление на среди в ограничителен режим
• Производство. Средата, в която приложенията и другият софтуер се използват по предназначение.
• Разработчик (официално наричан Общност). Средата за разработчици е среда за един потребител и не може да се използва за стартиране или споделяне на приложения за производство. Общност Планът за разработчици на Power Apps ви дава достъп до първокласните функционалности на Power Apps, Dataverse и Power Automate за индивидуална употреба. Този план е предназначен предимно за изграждане и тестване с Power Apps Power Automate и Dataverse /или за учебни цели.
• По подразбиране. Една единична среда по подразбиране се създава автоматично за всеки клиент и се споделя от всички потребители в този наемател. Наемателят идентифицира клиента, който може да има един или повече абонаменти на Microsoft и услуги, свързани с него. Всеки път, когато нов потребител се регистрира, Power Apps той автоматично се добавя към ролята на създател на среда на средата по подразбиране. Средата по подразбиране се създава в най-близкия регион до региона по подразбиране на Microsoft Entra клиента и се нарича: "{Microsoft Entra име} на клиент (по подразбиране)"

Създаване и използване на правилната среда за конкретна цел, например за разработка, тестване или производство.

За повече информация относно средите отидете на Общ преглед на средите.

Кой трябва да има достъп?

Дефинирайте и управлявайте сигурността на вашите ресурси и данни Dataverse. Power Platform Предоставя администраторски роли на ниво среда за изпълнение на задачи. Dataverse включва роли в сигурността, които определят нивото на достъп до приложения, компоненти на приложения и ресурси, които създателите и потребителите на приложения имат в себе си Dataverse.

Допълнителна информация:

• Преглед на средите
• Контролирайте достъпа на потребителите до среди: групи за защита и лицензи
• Създаване на потребители и присвояване на права за достъп
• Създаване на среда

Решения

Решенията се използват за транспортиране на приложение и компоненти от една среда в друга или за прилагане на набор от персонализации на съществуващи приложения.

Решенията имат тези функции:

• Те включват метаданни и определени таблици с конфигурационни данни. Решенията не съдържат никакви бизнес данни.
• Те могат да съдържат много различни Power Platform компоненти, като например приложения, управлявани от модел, приложения за платно, карти на сайтове, потоци, таблици, формуляри, персонализирани конектори, уеб ресурси, избори, диаграми и колони. Обърнете внимание, че не всички таблици могат да бъдат включени в решение. Например системните таблици на потребителя на приложението, персонализирания API и настройката на организацията не могат да се добавят към решение.
• Те са пакетирани като единица, която ще бъде експортирана и внесена в други среди, или деконструирана и проверена в контрола на източника като изходен код за активи. Решенията се използват и за прилагане на промени към съществуващи решения.
• Управлявани решения се използват за внедряване във всяка среда, която не е среда за развитие на това решение. Това включва тест, тестване за приемане от потребители (UAT), тестване на системната интеграция (SIT) и производствена среда. Управляваните решения могат да бъдат обслужвани (надстройка, кръпка и изтриване) независимо от други управлявани решения в среда. Като най-добра практика на ALM, управляваните решения трябва да бъдат генерирани от сървър за изграждане и да се считат за артефакт за изграждане.
• Актуализациите на завършено решение се разполагат в предишната версия на завършено решение. Това не създава допълнителен слой решение. Не можете да изтриете компоненти, като използвате актуализация.
• Патчът съдържа само промените за родителски завършено решение. Трябва да използвате пачове само когато правите малки актуализации (подобно на актуална корекция) и ще ви е нужна, за да може да бъде деинсталирана. Когато корекциите се импортират, те се наслояват върху родителското решение. Не можете да изтриете компоненти, като използвате корекция.
• Надстройването на решение инсталира нов слой решение непосредствено над основния слой и всички съществуващи корекции.
  • Прилагането на ъпгрейди на решения включва изтриване на всички съществуващи кръпки и основния слой.
  • Надстройките на решението изтриват компоненти, които са съществували, но вече не са включени в надстроената версия.

Повече информация: Концепции на решение

Изходна контрола

Контролът на източниците, известен също като контрол на версиите, е система, която поддържа и сигурно съхранява активи за разработка на софтуер и проследява промените в тези активи. Проследяването на промените е особено важно, когато множество производители и разработчици на приложения работят върху един и същ набор от файлове. Система за контрол на източници също ви дава възможност да върнете промените или да възстановите изтритите файлове.

Система за контрол на източниците помага на организациите да постигнат здравословно управление на ALM, защото активите, поддържани в системата за контрол на източниците, са „единствен източник на истина” или с други думи, единната точка за достъп и модификация за вашите решения.

Стратегия за разклоняване и сливане

Почти всяка система за контрол на източниците има някаква форма на поддръжка за разклоняване и сливане. Разклоняването означава, че се отклонявате от основната линия на развитие и продължавате да вършите работа, без да променяте основната линия. Процесът на сливане се състои в комбиниране на един клон в друг, например от разклонителен клон в основен клон. Някои общи стратегии за разклоняване са базираните на ствола разклонения, разклоняването на освобождаване и характеристиките на разклонението. Повече информация: Приемане на стратегия за разклоняване на Git

Процес за контрол на източника с помощта на решение

Има два основни пътя, които можете да използвате, когато работите с решения в система за контрол на източника:

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

Повече информация: Изграждане на задачи с инструменти

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

Автоматизацията е ключова част от жизнения цикъл на приложението, която подобрява производителността, надеждността, качеството и ефективността на ALM. Инструментите и задачите за автоматизация се използват за валидиране, експортиране, пакетиране, разопаковане и експортиране на решения в допълнение към създаването и нулирането на среди в пясъчниците.

Повече информация: Какво e 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, може драстично да подобри скоростта, надеждността и потребителското изживяване на приложението. Той също така гарантира, че множество разработчици, както традиционните програмисти за писане на код, така и граждански разработчици, могат заедно да допринесат за изграждането на приложението.

Вижте следните статии, които обсъждат няколко въпроса, които трябва да разгледате в началото на всяка разработка на приложения:

• Стратегия за околната среда на ALM
• Концепции за решения