Рекомендации по проектированию цепочки поставок для разработки рабочих нагрузок
Применимо к этой рекомендации Power Platform контрольного списка хорошо спроектированного операционного совершенства:
| ОЭ:06 | Создайте цепочку поставок рабочей нагрузки для внедрения предлагаемых изменений с помощью предсказуемых автоматизированных конвейеров. Конвейеры проверяют и внедряют эти изменения в разных средах. Оптимизируйте цепочка поставок, чтобы сделать вашу рабочую нагрузку надежной, безопасной, экономичной и производительной. |
|---|
В этом руководстве описаны рекомендации по проектированию цепочки поставок для разработки рабочих нагрузок, основанной на конвейерах непрерывной интеграции и непрерывной доставки (CI/CD). В облачных рабочих нагрузках цепочка поставок представляет собой стандартизированный набор инструментов и процессов, которые вы используете для влияния на изменение конфигурации и рабочей нагрузки в разных средах. Разработайте цепочку поставок, чтобы обеспечить предсказуемый и стандартизированный метод поддержания рабочей нагрузки. Конвейеры CI/CD — это проявление цепочки поставок, но у вас должна быть единая цепочка поставок. У вас может быть несколько конвейеров, которые следуют одним и тем же процессам и используют одни и те же инструменты.
Создайте цепочку поставок, чтобы защитить вашу рабочую нагрузку от ущерба, который может возникнуть, если вы не будете должным образом управлять изменениями рабочей нагрузки. Всегда будьте в курсе состояния своей рабочей нагрузки, чтобы не подвергать себя риску непредсказуемого поведения. Этот риск возрастает, если при возникновении проблем вам приходится тратить критически важное время на отслеживание неучтенных изменений. Чтобы свести к минимуму эти риски, стандартизируйте процессы и инструменты, определяющие вашу цепочку поставок, и убедитесь, что ваша рабочая группа полностью привержена их использованию.
Ключевые стратегии проектирования
Следующие рекомендации помогут вам определить основные принципы вашей цепочки поставок.
Вносите предлагаемые изменения в рабочую нагрузку с помощью процессов и инструментов цепочки поставок. Обеспечьте соблюдение строгой политики автоматического развертывания на основе шаблонов. Этот метод помогает гарантировать, что конфигурация вашей рабочей нагрузки во всех средах стандартизирована, четко определена и строго контролируется. Для сред в цепочке продвижения кода не выполняйте обновления с помощью ручных процессов или взаимодействия с человеком. Включайте все изменения в среду через конвейер, следуя определенным вами методам развертывания. Чтобы обеспечить соблюдение этой политики, рассмотрите возможность ограничения доступа по умолчанию режимом «только для чтения» и использования шлюза авторизации доступа, чтобы разрешить доступ на запись.
Важным аспектом этого принципа является то, что все изменения являются предлагаемыми до тех пор, пока они не будут развернуты в рабочей среде. С помощью автоматического тестирования, такого как интеграционное тестирование и тестирование состояния, вы позволяете своей цепочке поставок автоматически отклонять изменения.
Используйте один набор ресурсов кода и артефактов во всех средах и конвейерах. Общей проблемой для организаций является то, что непроизводственная среда отличается от производственной. Создание производственных и непроизводственных сред вручную может привести к несовпадению конфигураций между средами. Такое несоответствие замедляет тестирование и повышает вероятность того, что изменения могут нанести вред производственной системе.
Отразите свою организационную структуру в дизайнах цепочки поставок и конвейеров. Ваша организация может быть разобщена между рабочими группами. Каждая рабочая группа может управлять частью цепочки поставок. Например, во многих организациях есть рабочие группы, которые управляют параметрами безопасности и соответствия требованиям или конфигурациями среды. Эти рабочие группы отделены от рабочих групп разработчиков, которые управляют разработкой, тестированием и развертыванием приложений. Существует множество способов организовать рабочие группы, участвующие в цепочке поставок. Ваша цепочка поставок опирается на слаженную совместную работу всех рабочих групп. Убедитесь, что все рабочие группы следуют стандартным процессам и используют стандартные инструменты, чтобы сделать цепочку поставок максимально эффективной.
Ваш цепочка поставок может полагаться на сторонних поставщиков, если вы передаете на аутсорсинг части жизненного цикла рабочей нагрузки. Эти поставщики так же важны для успеха вашего цепочка поставок, как и внутренние ресурсы. Убедитесь, что во всех командах существует взаимное согласие относительно используемых вами процессов и инструментов.
Стандартизируйте метод развертывания. Поговорите с владельцем продукта о приемлемом времени простоя производства для вашей рабочей нагрузки. В зависимости от того, насколько допустимо время простоя, вы можете выбрать метод развертывания, соответствующий вашим требованиям. В идеале развертывания следует выполнять во время периода обслуживания, чтобы снизить сложность и риск.
Спланируйте целостную стратегию тестирования. Основным принципом надежности системы является принцип «сдвига влево». Разработка и развертывание приложения — это процесс, который изображается как серия шагов, идущих слева направо. Не следует ограничивать тестирование окончанием процесса. Насколько это возможно, сдвиньте тестирование в начало или влево. Ошибки дешевле исправлять, если обнаружить их на ранней стадии. Их исправление на более поздних этапах жизненного цикла приложения может оказаться дорогостоящим или невозможным.
По возможности используйте автоматическое тестирование, чтобы обеспечить согласованность. Включите следующие типы тестирования в структуру вашей цепочки поставок:
Модульное тестирование: модульное тестирование обычно выполняется как часть процедуры непрерывной интеграции. Модульными тесты должны быть обширными и быстрыми. В идеале они должны покрывать 100 процентов кода. Применяйте модульные тесты ко всем ресурсам кода, включая шаблоны и скрипты.
Дымовое тестирование: Дымовое тестирование подтверждает, что рабочая нагрузка может быть выдержана в тестовой среде и работает так, как ожидалось. Тесты состояния не проверяют совместимость компонентов. Тесты состояния проверяют, что методология развертывания инфраструктуры и приложения работает, а также что система реагирует должным образом после завершения процесса.
Интеграционное тестирование: Интеграционные тесты гарантируют, что компоненты приложения работают по отдельности, а затем определяют, могут ли компоненты взаимодействовать друг с другом должным образом. Запуск большого набора интеграционных тестов может занять значительное время. Вот почему лучше всего использовать принцип сдвига влево и проводить тестирование на ранних этапах жизненного цикла разработки программного обеспечения. Зарезервируйте интеграционные тесты для сценариев, которые невозможно протестировать с помощью теста состояния или модульного теста. При необходимости вы можете запускать длительные процессы тестирования через регулярные промежутки времени. Регулярный интервал обеспечивает хороший компромисс и позволяет обнаружить проблемы совместимости между компонентами приложения не позднее, чем через день после их внедрения. Некоторые сценарии тестирования выигрывают от запуска вручную. Используйте ручное тестирование, когда вам нужно ввести в тесты элементы человеческого взаимодействия.
Приемочное тестирование: в зависимости от контекста вы можете вручную выполнить приемочное тестирование. Оно может быть частично или полностью автоматизировано. Приемочное тестирование определяет, соответствует ли программная система техническим требованиям. Основной целью данного теста является оценка соответствия системы бизнес-требованиям и определение того, соответствует ли система требуемым критериям для поставки пользователям.
Внедряйте контроль качества на протяжении всего процесса продвижения кода посредством тестирования. Разверните свой код в средах более низкого уровня, таких как обеспечение качества и тестирование, и в средах более высокого уровня, таких как промежуточная и производственная среда. По мере того, как ваше развертывание проходит через контроль качества, убедитесь, что оно соответствует вашим целевым показателям качества, прежде чем изменения попадут в рабочую среду. Требования вашего бизнеса определяют, на что направлены ваши шлюзы качества. Также примите во внимание фундаментальные принципы Power Platform хорошей архитектуры: безопасность, надежность и эффективность работы.
Также интегрируйте рабочие процессы утверждения в свои шлюзы качества. Четко определите и автоматизируйте рабочие процессы утверждения, когда это необходимо. Определите критерии приемки качества для вашей автоматизации, чтобы вы могли эффективно и безопасно проходить через ворота.
Возможности в Power Platform
Pipelines Power Platform направлены на демократизацию управления жизненным циклом приложений (ALM) для Power Platform клиентов Dynamics 365 путем внедрения в сервис возможностей автоматизации ALM, непрерывной интеграции и непрерывной поставки (CI/CD).
Microsoft Power Platform Инструменты сборки для Azure DevOps могут использоваться для автоматизации общих задач сборки и развертывания, связанных с приложениями, созданными на Power Platform.
Действия GitHub для Power Platform позволяют разработчикам создавать автоматизированные рабочие процессы жизненного цикла разработки программного обеспечения. С помощью GitHub Actions для Microsoft Power Platform вы можете создавать бизнес-процессы в своем репозитории для создания, тестирования, упаковки, выпуска и развертывания приложений; выполнять автоматизацию; и управлять ботами и другими компонентами на базе Power Platform.
ALM Accelerator — это инструмент с открытым исходным кодом, состоящий из набора приложений, скриптов и конвейеров, предназначенных для автоматизации процесса непрерывной интеграции/непрерывной поставки.
Автоматизируйте тесты с помощью Azure Pipelines.
Power Apps API проверки Web предоставляет механизм для выполнения проверок статического анализа в отношении настроек и расширений Microsoft Dataverse платформы.
Microsoft Power Platform CLI (PAC CLI) — это инструмент командной строки, который поддерживает импорт и экспорт Power Platform решений, а также упаковку и распаковку Power Platform исходных файлов решений. PAC CLI доступен как автономный инструмент командной строки или как расширение для Visual Studio Code.
Вы можете использовать Terraform, Bicep и Azure Resource Manager для развертываний неизменяемой инфраструктуры как кода (IaC). В зависимости от ваших требований и знакомства вашей команды с этими инструментами вы можете использовать один или несколько из этих инструментов для развертывания и управления ресурсами.
Согласованность внутри организации
Cloud Adoption Framework предоставляет центральным рабочим группам рекомендации по созданию зон размещения рабочей нагрузки. Зоны размещения рабочей нагрузки — это места, куда настраиваемый цепочка поставок рабочей нагрузки развертывает приложения.
Узнайте больше в статьях Что такое целевая зона Azure? и Принципы проектирования целевой зоны Azure.