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

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

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

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

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

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

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

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

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

  • Планирование работы и управление журналом невыполненных работ

  • Контроль версий и репозитории

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В ADR включите:

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

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

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

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

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

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

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

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

Установите стандарты для применения версионирования к артефактам

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

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

Внедрите подход к тестированию со сдвигом влево

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

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

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

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

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

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

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

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

Требовать методики 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, а также конкретные правила и примеры для различных типов ресурсов.

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

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

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