Рекомендации по стандартизации средств и процессов

  • Статья

Применяется к этой рекомендации по контрольным спискам эффективности операционных процессов Azure Well-Architected Framework:

OE:04 Оптимизируйте процессы разработки программного обеспечения и контроля качества, следуя проверенным отраслевым методикам разработки и тестирования. Для однозначного назначения ролей стандартизируйте методики для различных компонентов, таких как инструменты, система управления версиями, шаблоны проектирования приложений, документация и руководства по стилю.

Связанное руководство. Повышение скорости | сборкиИспользование непрерывной интеграции

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

Ключевые стратегии проектирования

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

Использование хорошо известных и зрелых готовых инструментов

Используйте хорошо известные и зрелые готовые инструменты и стандартизируйте их использование. Команды разработчиков с высокой эффективностью применяют лучшие в своем классе инструменты. Такой подход сводит к минимуму необходимость разработки решений для планирования, разработки, тестирования, совместной работы, а также непрерывной интеграции и непрерывной поставки (CI/CD). Многие предприятия предоставляют разработчикам выбор между несколькими инструментами, но все варианты являются стандартными средствами для организации и проверяются внутри организации. Самое главное, выберите средства, которые соответствуют требованиям для вашей рабочей нагрузки. Готовые средства должны предоставлять следующие функции:

  • Планирование работы и управление невыполненной работой

  • Управление версиями и репозитории

  • Конвейеры CI/CD

  • Тестирование, например интеграция, дым, искусственный пользователь, имитация, хаос и другие тесты качества

  • Написание кода

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

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

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

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

По возможности выберите модель на основе магистралей. Ветвление на основе магистралей синхронизирует группу разработчиков рабочей нагрузки и поощряет непрерывную поставку. Определите политики ветви для защиты важных ветвей, таких как main ветвь. Дополнительные сведения см. в разделах Внедрение стратегии ветвления Git и Политики и параметры ветви.

Оценка метрик для количественной оценки эффективности разработки

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

  • Частота развертывания. Количество развертываний, развертываемых каждым разработчиком каждый день.

  • Время выполнения: время, необходимое для выполнения задачи или пользовательской истории, от невыполненной работы до рабочего развертывания.

  • Среднее время до устранения. Среднее время, затраченное на исправление ошибок или дефектов в коде.

  • Частота сбоев изменений: процент изменений, которые приводят к сбою.

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

Стандартизация того, как команда рабочей нагрузки пишет, проверяет и документирует код

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

Когда это удобно, используйте инструменты для применения стандартов форматирования кода. Например, Visual Studio предлагает несколько средств , которые проверяют код на предмет стиля, качества, удобства обслуживания, дизайна и других проблем. Для инфраструктуры как кода (IaC) можно использовать Checkov или Terrascan для Terraform.

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

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

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

Включите в ADR следующее:

  • Определенные средства и технологии, например с помощью SQL или NoSQL, которые выбирает ваша команда.

  • Причины решений вашей команды.

  • Другие варианты, которые были рассмотрены, что помогает контекстуализировать окончательное решение.

  • Функциональные и нефункциональные требования, которые учитываются в решениях.

  • Контекст процесса принятия решений, как и проблема, которая была решена.

Внедрение стандартов по устранению технической задолженности

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

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

Стандартизация применения управления версиями к артефактам

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

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

Реализация подхода к тестированию сдвига влево

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

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

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

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

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

  • Рассмотрите возможность тестирования владения, основанного на владении рабочей нагрузкой. Ваша команда рабочей нагрузки владеет тестированием и не должна полагаться на другие команды для тестирования кода.

  • Максимально автоматизируйте тесты. Автоматизированный код снимает нагрузку на команду рабочей нагрузки и обеспечивает согласованное качество.

Подробные инструкции по реализации стратегии тестирования DevOps см. в разделе Тестирование с помощью смены влево с модульными тестами.

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

Реализация стандартов именования и добавления тегов к ресурсам

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

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

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

Дополнительные сведения об использовании соглашений об именовании для облачных ресурсов см. в статье Определение соглашения об именовании. Дополнительные сведения о применении тегов метаданных к облачным ресурсам см. в статье Определение стратегии добавления тегов.

Упрощение поддержки Azure

  • Azure DevOps — это набор служб, которые можно использовать для создания совместной, эффективной и согласованной методики разработки. Azure DevOps объединяет следующие решения:

    • Azure Pipelines предоставляет службы сборки и выпуска для поддержки CI/CD приложений.

    • Azure Boards — это веб-средство управления работой, которое поддерживает методики Agile, такие как Scrum и Kanban.

    • Azure Repos — это средство управления версиями, которое поддерживает распределенную систему управления версиями Git и систему система управления версиями Team Foundation.

    • Azure Test Plans — это браузерное решение для управления тестами, которое предоставляет возможности, необходимые для планового ручного тестирования, пользовательского приемочного тестирования, исследовательского тестирования и сбора отзывов от заинтересованных лиц.

    • Azure Artifacts позволяет разработчикам эффективно обмениваться кодом и управлять своими пакетами.

  • GitHub Actions для Azure — это средство, которое можно использовать для автоматизации процессов CI/CD. Она интегрируется непосредственно с Azure для упрощения развертываний. Вы можете создавать рабочие процессы, которые создают и тестируют каждый запрос на вытягивание в репозиторий, или развертывают объединенные запросы на вытягивание в рабочей среде.

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

  • К средствам с низким и без кода относятся:

  • Шаблоны azure Resource Manager и Bicep — это собственные средства Azure, которые можно использовать для развертывания IaC. Terraform — это еще одно средство IaC, поддерживаемого Azure, которое можно использовать для развертывания инфраструктуры и управления ею.

  • Visual Studio — это надежное средство разработки, которое интегрируется с Azure и поддерживает множество языков.

  • GitHub Copilot — это служба ИИ, которая выступает в качестве парного программиста и предоставляет предложения по стилю автозаполнения при коде. Copilot доступен в виде расширения в Visual Studio и ряде других средств разработки.

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

Соответствие структуре организации

В Cloud Adoption Framework для Azure приведены общие рекомендации и рекомендации по присвоению тегов и именованию ресурсов Azure, а также конкретные правила и примеры для различных типов ресурсов.

Контрольный список эффективности операций

См. полный набор рекомендаций.

Контрольный список эффективности операций