Споделяне чрез


Основи на 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. Инструментите и задачите за автоматизация се използват за валидиране, експортиране, пакетиране, разопаковане и експортиране на решения в допълнение към създаването и нулирането на среди в пясъчниците.

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

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