управление жизненным циклом приложения

Средства управления жизненным циклом приложений: тенденции развития

Введение

о, что разработка программного обеспечения состоит не только из программирования, но и из иных процессов, ему предшествующих и за ним следующих, известно уже много лет. Достаточно долго существуют и программные продукты, предназначенные для поддержки и автоматизации указанных процессов. Однако массовое и систематическое применение этих продуктов в подавляющем большинстве проектов, связанных с разработкой приложений, началось относительно недавно — еще три-пять лет назад из всех возможных инструментов создания программного обеспечения самыми популярными и повсеместно применяемыми были главным образом средства разработки приложений и, в несколько меньшей степени, средства проектирования данных и инструменты генерации отчетов.

Сегодня ситуация стремительно меняется — начинается активное внедрение средств поддержки жизненного цикла приложений, и происходит это в компаниях и в отделах разработки самых разных размеров, причем применительно к самым разнообразным проектам. Нередко внедрение идет стихийно, начавшись с бесплатного средства контроля версий или с простейшего средства генерации документации, но бывает и так, что в качестве корпоративного стандарта принимается линейка продуктов какого-то одного производителя в расчете на более тесную взаимную интеграцию продуктов для поддержки различных этапов жизненного цикла приложений.

Основные этапы жизненного цикла приложений

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

Стоимость различных этапов жизненного цикла может значительно различаться для разных типов проектов и различных методологий. Например, в случае коробочного продукта наибольшие затраты приходятся на тестирование продукта в условиях применения разнообразных конфигураций аппаратного и программного обеспечения, тогда как в случае нестандартного заказного проекта основная часть средств расходуется на управление требованиями.

Естественно, желание автоматизировать указанные процессы или хотя бы избавиться от рутинной работы — это один из факторов, привлекающих пристальное внимание руководителей отделов разработки к средствам поддержки жизненного цикла приложений.

Рынок средств поддержки жизненного цикла приложений

о данным аналитической компании Butler Group, рынок средств поддержки жизненного цикла приложений выглядит следующим образом. Основную долю рынка делят между собой компании Microsoft, IBM, Oracle и Borland, однако при этом на данном рынке присутствует довольно много других сильных игроков, в частности Computer Associates, Compuware, Sun Microsystems, Telelogic, которые поставляют как наборы средств для поддержки всех этапов жизненного цикла приложений, так и отдельные инструменты для какого-то конкретного этапа. В последние годы происходила заметная консолидация рынка, выразившаяся в приобретении лидирующими в этой области компаниями (например, IBM и Borland) инструментов, разработанных другими компаниями, с целью обеспечения поддержки всех этапов жизненного цикла. В последнее время также возросла популярность средств поддержки жизненного цикла приложений с открытым кодом, равно как и объем инвестируемых в них средств. Сегодня эти средства, как правило, не удовлетворяют требованиям, предъявляемым к подобным инструментам при реализации крупных проектов, однако в небольших проектах их применение вполне себя оправдывает. Нередко подобные инструменты реализуются в виде модулей, подключаемых к средам с открытым кодом типа Eclipse.

Ниже мы рассмотрим основные категории средств, применяемых различными участниками проектов, связанных с разработкой приложений.

Средства управления требованиями

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

В ряде стран документ, содержащий формулировки требований, служит обязательным приложением к договору на разработку продукта. В зависимости от методологии выполнения проекта формулировка требований или их модификация может производиться однократно или многократно. Иногда требования формулируются в виде текстового документа, например технического задания. Однако в последнее время все большую популярность приобретают средства автоматизации управления требованиями, позволяющие не только генерировать документ согласно стандартам, принятым в той или иной стране, но и автоматизировать реализацию требований на уровне мoдели и даже кода приложения.

Из наиболее часто применяющихся в нашей стране средств управления требованиями следует назвать Rational Requisite Pro (IBM, www.ibm.com) и Borland CaliberRM (Borland, www.borland.com). Первый из этих продуктов довольно давно продвигается в России несколькими наиболее активными партнерами IBM, а второй приобрел популярность скорее благодаря отсутствию продвижения — до приобретения корпорацией Borland компании StarTeam, владевшей этим продуктом, на российском рынке он вообще не рекламировался. Из других популярных брендов в области средств управления требованиями следует, пожалуй, отметить DOORS (Telelogic, www.telelogic.com).

Что же умеют делать все современные средства управления требованиями? Как правило, они позволяют классифицировать требования по категориям и подкатегориям, осуществлять их детализацию и генерировать различные документы, содержащие требования к продукту, в соответствии со стандартами, которые приняты в той или иной стране (иногда для реализации подобной возможности требуется создать соответствующие шаблоны). Однако основная функциональность, ради которой приобретаются указанные средства, — это возможность интеграции с инструментами, предназначенными для других этапов жизненного цикла приложений. Так, Borland CaliberRM интегрируется со многими средствами разработки Borland и Microsoft, вплоть до встраивания списка требований в среду разработки и генерации заготовок кода при переносе пиктограммы требования мышью в редактор кода, а Rational Requisite Pro — со средством генерации проектной документации Rational SoDA и со средством объектно-ориентированного моделирования Rational Rose (в частности, этот продукт позволяет генерировать требования на основе прецедентов, описанных в модели). Что же касается DOORS, то он содержит средства визуализации требований в виде диаграмм и для него доступны средства интеграции с большим количеством средств проектирования и разработки приложений, включая продукты как самой компании Telelogic, так и Rational, CA и ряда других производителей.

Средства моделирования бизнес-процессов, приложений и данных

оделирование и проектирование данных и приложений основывается на сформулированных требованиях и является весьма важной частью процесса создания готового продукта. Инструменты для поддержки данного этапа жизненного цикла приложений можно условно разделить на средства моделирования бизнес-процессов, средства проектирования данных и средства объектно-ориентированного моделирования. Отметим, однако, что сегодня многие компании производят все три категории инструментов, интегрирующихся между собой (например, позволяющих сгенерировать модель данных и модели бизнес-процессов или синхронизировать их между собой), либо реализуют функциональность нескольких разнотипных средств моделирования в одном продукте, поэтому применительно к указанной категории инструментов имеет смысл говорить о линейках продуктов различных производителей.

Ниже перечислены наиболее известные на российском и мировом рынках продукты и линейки продуктов, предназначенных для моделирования и проектирования.

AllFusion Modelling Suite (Computer Associates, www.cai.com) состоит из следующих продуктов:

• AllFusion Process Modeler — основной инструмент для визуального моделирования бизнес-процессов;

• AllFusion ERwin Data Modeler — средство проектирования и документирования баз данных, хранилищ данных и витрин данных;

• AllFusion Data Model Validator — инструмент для проверки структуры баз данных и создаваемых моделей, позволяющий выявлять недочеты и ошибки проектирования;

• AllFusion Model Manager — средство обеспечения для совместной работы группы проектировщиков над одним проектом с помощью AllFusion ERwin Data Modeler и/или AllFusion Process Modeler;

• AllFusion Component Modeler — средство объектно-ориентированного проектирования приложений, интегрирующееся с AllFusion Process Modeler.

В России эта линейка продуктов весьма популярна, а AllFusion ERwin Data Modeler является одним из самых распространенных средств проектирования данных, главным образом благодаря поддержке широкого спектра СУБД.

Oracle Designer представляет собой инструмент, позволяющий проектировать данные, моделировать бизнес-процессы, создавать диаграммы потоков данных и функциональные модели, а также реализовывать их в виде серверных объектов. Этот продукт главным образом предназначен для применения совместно с СУБД Oracle и поддерживает все особенности данной СУБД, хотя с его помощью можно осуществлять и обратное проектирование для СУБД других производителей.

Sybase PowerDesigner — это инструмент, в состав которого входят средства создания моделей и объектно-ориентированного моделирования. Помимо серверных СУБД производства Sybase, PowerDesigner способен работать с любыми ODBC-источниками, генерировать код клиентских приложений для PowerBuilder, а также классы Java и компоненты JavaBeans. Возможно и обратное проектирование диаграмм классов из исходных текстов Java. Набор функциональных возможностей продукта варьируется в зависимости от редакции. Отметим, что PowerDesigner весьма популярен на российском рынке, и отнюдь не только среди пользователей СУБД и средств разработки Sybase.

System Architect (Popkin Software) является универсальным средством, позволяющим осуществить не только проектирование данных, но и структурное моделирование. В его состав входит средство проектирования данных и создания ER-диаграмм. Этот продукт поддерживает СУБД практически всех ведущих производителей. Компоненты System Architect позволяют документировать процесс работы над проектом, включая техническое задание, план тестирования и др. С помощью System Architect 2001 возможно генерировать код клиентских приложений для Visual Basic, Delphi и PowerBuilder, классы C++.

Rational Rose (IBM) — одно из самых популярных средств объектно-ориентированного UML-моделирования приложений. Данный продукт позволяет решать практически любые задачи в проектировании информационных систем — от анализа бизнес-процессов и моделирования данных до генерации кода на различных языках программирования, а также обладает средствами интеграции с другими инструментами Rational, в частности с Requisite Pro.

Together (Borland) является платформой для анализа и проектирования приложений, интегрирующейся с различными средствами разработки как самой компании Borland, так и других производителей (в частности, Microsoft). Данный продукт позволяет осуществлять моделирование и проектирование приложений и данных, причем степень его интеграции со средствами разработки на данный момент такова, что изменения модели данных приводят к автоматическому изменению кода приложения, равно как и изменения в коде приводят к изменению в моделях (указанная технология интеграции инструментов моделирования и средств разработки получила название LiveSource).

Из вышесказанного следует, что основной тенденцией развития средств моделирования в настоящее время является активное предложение средств интеграции их между собой и с инструментами поддержки других этапов жизненного цикла приложений, как-то: средств разработки, средств управления требованиями и средств управления изменениями. Происходившее в последние годы слияние компаний, специализирующихся на производстве подобных инструментов, позволило создать линейки продуктов, в своей совокупности реализующих все или почти все задачи, которые могут возникнуть на этапе проектирования приложений.

Еще одной тенденцией можно назвать появление таких средств моделирования, которые тесно интегрированы со средствами разработки не только на уровне синхронизации кода и модели, но и на уровне полного определения поведения приложения непосредственно в самой модели (как это, например, реализовано в архитектуре Model Driven Architecture).

Средства разработки приложений

C точки зрения аналитической компании Meta Group, в настоящее время лидерами рынка средств разработки Java-приложений являются Borland, IBM, Oracle, а к компаниям, имеющим четкое видение рынка и претендующим на его заметную долю, относятся Sun, JetBrains и Novell (подробнее о средствах разработки Java-приложений этих компаний вы сможете прочесть в статье «Средства разработки Java-приложений» (КомпьютерПресс № 8’2003).

В ряду самых важных составляющих современных средств разработки приложений необходимо выделить средства повышения производительности труда разработчиков, средства поддержки коллективной работы, возможности, связанные с повторным использованием моделей и кода, поддержку средств и стандартов создания распределенных приложений и их интеграции (в частности, поддержку создания и применения Web-сервисов), поддержку разработки приложений для мобильных устройств и, разумеется, средства интеграции с инструментами поддержки других этапов жизненного цикла приложенний (в частности, со средствами проектирования и моделирования приложений и данных, управления требованиями, тестирования и оптимизации).

Средства тестирования и оптимизации приложений

естирование — абсолютно необходимая составляющая процесса создания качественного программного обеспечения. Именно на этом этапе проверяется, удовлетворяет ли приложение сформулированным требованиям, а затем в продукт вносятся изменения, устраняющие выявленные при тестировании недостатки.

Средства тестирования приложений можно с некоторой долей условности разделить на несколько категорий: средства управления процессом тестирования и генерации планов тестирования, средства управления найденными дефектами (Bug tracking), средства тестирования баз данных, средства тестирования пользовательского интерфейса, средства тестирования производительности, средства тестирования безопасности приложений, средства регрессионного тестирования (создающие испытательные сценарии на основе записанных действий пользователя и затем многократно их повторяющие) и ряд других категорий.

Из самых распространенных средств тестирования в первую очередь следует назвать набор средств тестирования компании IBM/Rational, который включает:

• TestManager — средство составления планов тестирования, управления процессом тестирования и анализа результатов, позволяющее проводить распределенное и нагрузочное тестирование;

• Quantify — средство сбора статистических данных о количестве вызовов функций в тестируемом приложении и выявления временных характеристик отдельных частей приложения;

• Pure Coverage — средство поиска участков кода, пропущенных при тестировании;

• Purify — средство поиска ошибок, связанных с утечкой памяти;

• Visual Test — средство тестирования пользовательских интерфейсов приложения.

Большой популярностью пользуются также решения компании Compuware (www.compuware.com):

• QACenter — средство тестирования пользовательского интерфейса приложений и регрессионного тестирования;

• QACenter Performance Edition — средство нагрузочного тестирования;

• BoundsChecker — средство тестирования кода приложений;

• TrackRecord — средство отслеживания найденных дефектов и управления ими.

Характерной особенностью современных средств тестирования является наличие средств интеграции их со средствами разработки приложений, средствами управления требованиями, а иногда и со средствами управления изменениями, а также появление интегрированных сред управления процессом тестирования.

Средства управления коллективной работой и контроля версий

редства управления коллективной работой применяются на различных этапах создания приложений — начиная с формулировки требований и заканчивая внедрением готового продукта. Условно их можно разделить на средства управления задачами и проектами, средства контроля версий кода, моделей и документов, средства организации документооборота внутри команды разработчиков.

Из средств контроля версий самыми распространенными считаются Merant PVCS Version Manager и Microsoft Visual SourceSafe, однако именно среди этой категории продуктов немалую популярность имеют и средства категории Open Source.

Среди средств управления проектами в первую очередь нужно отметить семейство продуктов Microsoft Project (см. КомпьютерПресс № 1’2003), состоящее из нескольких редакций, разных по своему назначению и по степени масштабируемости, — Microsoft Project является сейчас безусловным лидером рынка средств управления проектами.

К средствам организации коллективной работы прежде всего относится Borland StarTeam — масштабируемое средство управления конфигурациями программного обеспечения, хранящее в централизованном репозитарии все необходимые данные и предоставляющее команде участников проекта разнообразные средства для публикации требований, управления задачами, планирования работы, обсуждения изменений, контроля версий, организации документооборота, а также средство управления изменениями Rational ClearQuest и средство управления конфигурациями Rational ClearCase.

Современные средства управления коллективной работой и контроля версий характеризуются, как правило, наличием централизованного репозитария (нередко хранящего не только сведения о проекте и его составных частях, но и сами составные части — иногда подобные репозитарии основаны на какой-нибудь серверной СУБД, как это сделано в Borland StarTeam), средства поддержки репозитариев других производителей, а также наличие средств интеграции со средствами поддержки других этапов жизненного цикла приложений.

Средства внедрения приложений

средствам внедрения приложений относятся инструменты для создания дистрибутивов и, в определенной степени, средства управления приложениями в корпоративных сетях (последние мы в настоящем обзоре рассматривать не будем, поскольку их уместно отнести к средствам администрирования, а не к инструментам для разработчиков).

Из компаний, лидирующих на рынке средств создания дистрибутивов приложений, следует упомянуть InstallShield и Wise. Продуктами этих компаний пользуются многие крупнейшие производители программного обеспечения, а специализированные (либо облегченные) версии их средств создания инсталляционных приложений нередко включаются в состав средств разработки приложений.

Заключение

так, можно сделать вывод, что рынок инструментов создания приложений отнюдь не ограничивается собственно средствами разработки, Более того, они перестают играть доминирующую роль в процессе реализации проектов, связанных с разработкой приложений. Объясняется это прежде всего появлением новых технологий создания приложений, выдвигающих на первый план моделирование и проектирование приложений и определение поведения приложений непосредственно в моделях, а также с развитием компонентно-ориентированного подхода, позволяющего реализовывать приложения на основе готовых компонентов и бизнес-объектов при минимальном объеме кодирования.

Одними из важнейших тенденций развития средств поддержки жизненного цикла приложений в последние годы стали, во-первых, интеграция этих инструментов между собой, а во-вторых, появление наборов средств, исчерпывающих все или почти все задачи по реализации проектов, которые связаны с разработкой приложений (примерами таких наборов являются некоторые решения компании Borland, носящие название «Enterprise Studio», и, в меньшей степени, продукт IBM Rational Suite, в состав которого не входят средства разработки приложений).

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

Источник

Общие сведения об ALM с Microsoft Power Platform

В этой статье описываются компоненты, средства и процессы, необходимые для реализации управления жизненным циклом приложений (ALM).

Среды

Среды — это пространство для хранения, управления и предоставления общего доступа к бизнес-данным, приложениям и бизнес-процессам. Они также служат контейнерами, которые разделяют приложения, которые могут иметь различные роли, требования безопасности или целевые аудитории. Каждая среда может иметь только одну базу данных Microsoft Dataverse.

При создании среды вы можете выбрать установку приложений Dynamics 365, таких как Dynamics 365 Sales и Dynamics 365 Marketing. В это время важно определить, нужны ли эти приложения или нет, потому что их нельзя удалить или установить позже. Если вы не используете эти приложения и не будете нуждаться в них в будущем, мы рекомендуем не устанавливать их в своих средах. Это поможет избежать осложнений с зависимостью при распределении решений между средами.

Типы сред, используемых в ALM

С использованием Центр администрирования Power Platform, вы можете создавать эти типы сред Dataverse:

Песочница среда песочницы — это любая непроизводственная среда Dataverse. Изолированная от производственного использования среда песочницы представляет собой среду, где можно без опасений вносить изменения в приложение и тестировать их с низким риском. Среды песочницы включают в себя возможности, которые могут быть опасными в рабочей среде, такие как операции сброса, удаления и копирования. Дополнительные сведения: Управление средами песочницы

Рабочая среда, в которой приложения и другое программное обеспечение вводятся в эксплуатацию по назначению.

Сообщество план сообщества Power Apps дает вам доступ к функциональность Power Apps премиум-класса, Dataverse и Power Automate для индивидуального использования. Этот план в первую очередь предназначен для обучения или создания бизнес-решений для распространения для AppSource Test Drive. Хотя вы не можете делиться ресурсами из среды разработки плана сообщества с кем-либо еще, вы можете принимать участие в конвейере Azure DevOps. Среда разработки — это однопользовательская среда, и ее нельзя использовать для запуска или совместного использования рабочих приложений.

По умолчанию автоматически создается одна среда по умолчанию для каждого клиента. Доступ к ней получают все пользователи этого клиента. Клиент идентифицирует клиента, который может иметь одну или несколько подписок Microsoft и связанных с ней сервисов. Когда новый пользователь регистрируется в Power Apps, он автоматически добавляется в роль разработчика в среде по умолчанию. Среда по умолчанию создается в ближайшем регионе к региону по умолчанию клиента Azure Active Directory (Azure AD) и называется: » <Имя клиента Azure AD>(по умолчанию)»

Создайте и используйте среду для определенных целей, таких как разработка, тестирование или производство.

У кого должен быть доступ?

Определите и управляйте безопасностью своих ресурсов и данных в Microsoft Dataverse. Microsoft Power Platform предоставляет роли администратора уровня среды для выполнения задач. Dataverse включает роли безопасности, которые определяют уровень доступа к приложениям, компонентам приложений и ресурсам, которые разработчики приложений и пользователи имеют в Dataverse.

Решения

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

Решения имеют следующие особенности:

Они включают в себя метаданные и некоторые сущности с данными конфигурации. Решения не содержат никаких бизнес-данных.

Они могут содержать много разных компоненты Microsoft Power Platform, такие как приложения на основе модели, приложения на основе холста, карты сайта, потоки, сущности, формы, настраиваемые соединители, веб-ресурсы, наборы параметров, диаграммы и поля. Обратите внимание, что не все сущности могут быть включены в решение. Например, в решение нельзя добавить системные таблицы «Пользователь приложения», «Пользовательский API» и «Параметры организации».

Они упакованы как единое целое для экспорта и импорта в другие среды или деконструированы и включены в управление исходным кодом в качестве исходного кода для активов. Решения также используются для внесения изменений в существующие решения.

Управляемые решения используются для развертывания в любой среде, которая не является средой разработки для этого решения. Это включает в себя тестирование, приемочное тестирование пользователя (UAT), тестирование системной интеграции (SIT) и рабочие среды. Управляемые решения можно обслуживать (обновлять, исправлять и удалять) независимо от других управляемых решений в среде. В соответствии с рекомендациями ALM управляемые решения должны генерироваться сервером сборки и считаться артефактом сборки.

Обновления управляемое решение развернуты в предыдущей версии управляемое решение. Это не создает дополнительный слой решения. Вы не можете удалить компоненты с помощью обновления.

Исправление содержит только изменения для родительского управляемое решение. Вы должны использовать исправления только при небольших обновлениях (например, исправление), и, возможно, вам потребуется удалить их. Когда исправления импортируются, они накладываются поверх родительского решения. Вы не можете удалить компоненты с помощью исправления.

Обновление решения устанавливает новый слой решения непосредственно над базовым слоем и любыми существующими исправлениями.

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

При обновлении решения удаляются компоненты, которые существовали, но больше не включены в обновленную версию.

Управление исходным кодом

Управление исходным кодом, также известное как управление версиями, представляет собой систему, которая поддерживает и надежно хранит активы разработки программного обеспечения и отслеживает изменения в этих активах. Отслеживание изменений особенно важно, когда несколько создателей приложений и разработчиков работают с одним и тем же набором файлов. Система управления версиями также дает вам возможность откатить изменения или восстановить удаленные файлы.

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

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

Почти каждая система управления версиями имеет некоторую форму поддержки ветвления и слияния. Ветвление означает, что вы отклоняетесь от основной линии разработки и продолжаете выполнять работу без изменения основной линии. Процесс слияния состоит из объединения одной ветви в другую, например, из ветви разработки в основную ветку. Некоторые распространенные стратегии ветвления — это ветвление на основе соединительных линий, ветвление выпуска и ветвление функций. Дополнительные сведения: Примите стратегию ветвления Git

Процесс управления исходным кодом с использованием решения

Есть два основных пути, которые вы можете использовать при работе с решениями в системе управления версиями:

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

Служба автоматизации является ключевой частью жизненного цикла приложения, которая повышает производительность, надежность, качество и эффективность ALM. Инструменты и задачи службы автоматизации используются для проверки, экспорта, упаковки, распаковки и экспорта решений в дополнение к созданию и сбросу сред песочницы.

Коллективная разработка с использованием совместного управления исходным кодом

Важно учитывать, как вы и ваша группа разработчиков будете работать вместе для сборки проекта. Преодоление обособленности и генерация мнений и разговоров может помочь вашей группе предоставить лучшее программное обеспечение. Некоторые средства и бизнес-процессы—такие как в Git, GitHub и Azure DevOps—были разработаны специально для улучшения качества коммуникации и программного обеспечения. Обратите внимание, что работа с конфигурациями в системе решений может создать проблемы для коллективной разработки. Организации должны координировать изменения от нескольких разработчиков, чтобы максимально избежать конфликтов при слиянии, потому что системы управления версиями имеют ограничения на то, как происходят слияния. Мы рекомендуем вам избегать ситуаций, когда несколько человек вносят изменения в сложные компоненты—такие как формы, потоки и приложения на основе холста—одновременно.

Непрерывная интеграция и развертывание

Вы можете использовать любую систему управления исходным кодом и собрать конвейер, чтобы начать работу с непрерывной интеграции и непрерывного развертывания (CI/CD). Тем не менее, это руководство фокусируется на GitHub и Azure DevOps. GitHub — это платформа разработки, используемая миллионами разработчиков. Azure DevOps предоставляет службы разработчиков группам поддержки для планирования работы, коллективной работы над разработкой кода, а также для создания и развертывания приложений.

Чтобы приступить к работе, требуется следующее:

Учетная запись GitHub, где вы можете создать репозиторий. Если у вас нет учетной записи, вы можете создать ее бесплатно.

Организация Azure DevOps. Если у вас нет учетной записи, вы можете создать ее бесплатно.

Лицензирование

Для создания или редактирования приложений и потоков с помощью Power Apps и Power Automate, соответственно, пользователи будут обязаны иметь индивидуальную лицензию для Power Apps или Power Automate или соответствующую лицензию на приложение Dynamics 365. Дополнительные сведения см. в Обзор лицензирования для Microsoft Power Platform. Мы также рекомендуем связаться с представителем вашей учетной записи Майкрософт для обсуждения ваших потребностей в лицензировании.

Особенности ALM

Когда вы рассматриваете ALM как неотъемлемую часть создания приложений на Microsoft Power Platform, это может радикальным образом повысить скорость, надежность и удобство работы приложения. Это также гарантирует, что несколько разработчиков, как обычные разработчики, пишущие код, так и разработчики-любители, могут совместно вносить вклад в создание приложения.

См. следующие статьи, в которых обсуждаются несколько вопросов, которые следует учитывать в начале разработки любого приложения:

Источник