Поделиться через

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

  • Статья

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

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

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

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

Основные стратегии проектирования

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

Использование известных и зрелых средств вне полки

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

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

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

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

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

  • Разработка кода

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В ADR включите:

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

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

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

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

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

Реализация стандартов для решения технической задолженности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Упрощение функций Azure

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

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

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

  • Ниже приведены средства с низким кодом и нет кода:

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

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

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

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

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

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

Контрольный список операционных знаний

Ознакомьтесь с полным набором рекомендаций.

Контрольный список операционных знаний