Справочник

Обеспечить качество кода (сборка, тестирование, покрытие) до слияния pull request.

→На целевой ветке настройте политику проверки сборки, которая запускает конвейер при создании PR. Конвейер должен публиковать результаты покрытия кода. Установите политику ветки для минимального покрытия.

Почему: Это обеспечивает качество до слияния. Стандартный CI триггер запускается после слияния. Ворота выпуска предназначены для развертываний, а не для PR.

Выбрать стратегию ветвления Git, которая минимизирует конфликты слияния и поддерживает быстрое, непрерывное развертывание в production.

→Реализовать разработку на основе магистральной ветви (trunk-based development) с короткими по времени существования ветками функций, которые часто (ежедневно или чаще) сливаются в `main`.

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

Защитить критическую ветку (например, `main`), обеспечивая проведение ревью кода, успешные сборки и связывание элементов работы перед слиянием.

→Настройте политики ветки на ветке `main` в Azure Repos. Включите политики для минимального количества рецензентов, проверки сборки и связывания элементов работы.

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

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

→Реализовать модель ветвления GitFlow, которая использует ветки `main`, `develop`, `feature/*`, `release/*` и `hotfix/*`.

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

Секрет был случайно закоммичен и отправлен. Он должен быть полностью удален из всей истории Git.

→Сначала смените раскрытый секрет. Затем используйте инструмент, такой как `git-filter-repo` или BFG Repo-Cleaner, чтобы переписать историю, удалив файл. Принудительно отправьте изменения и уведомите всех разработчиков о необходимости повторного клонирования.

Почему: Простой `git rm` или откат не удаляет секрет из истории. Для полного удаления требуется переписывание истории.

Моделирование сложного рабочего процесса с параллельными стадиями и зависимостями между ними.

→Используйте многостадийные конвейеры YAML. Используйте ключевое слово `dependsOn` для зависимостей стадий и настройте параллельные задания в пределах стадий.

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

Реализовать развертывание веб-приложения с нулевым временем простоя, низким риском и возможностью мгновенного отката.

→Используйте слоты развертывания Azure App Service. Разверните в промежуточный (зеленый) слот, проверьте, затем выполните переключение слота с production (синим).

Почему: Переключение слотов — это атомарная, почти мгновенная операция, которая перенаправляет трафик. Откат так же прост, как и обратное переключение.

Источник↗

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

→Создайте шаблоны YAML в центральном репозитории. В каждом конвейере, специфичном для службы, используйте ключевое слово `extends` и передайте параметры для настройки.

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

Ограничить выполнение стадии конвейера (например, развертывание в production) только слияниями в определенную ветку (например, main).

→Используйте `condition` на стадии или задании. Например, `condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`.

Почему: Сборки проверки PR используют другую ссылку на исходную ветку (например, `refs/pull/...`), поэтому это условие корректно предотвращает развертывание во время жизненного цикла PR.

Развертывание приложений из Azure DevOps на локальные серверы за корпоративным брандмауэром.

→Установите локальные агенты на локальные серверы. Зарегистрируйте их в пуле агентов в Azure DevOps.

Почему: Локальные агенты инициируют исходящую связь с Azure DevOps, поэтому входящие правила брандмауэра не требуются. Они могут получить доступ к локальным сетевым ресурсам для развертывания.

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

→Определите среду Azure DevOps для production. Настройте утверждения с требуемыми утверждающими. Добавьте проверку "Рабочие часы" в качестве шлюза для обеспечения временного окна.

Почему: Среды централизуют контроль развертывания. Утверждения и шлюзы обеспечивают надежное, автоматизированное применение политик перед запуском стадии.

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

→Используйте Azure App Configuration для управления функциями. Инструментируйте приложение для чтения флагов и включите его возможности динамического обновления.

Почему: Отделяет выпуски функций от развертываний. App Configuration предоставляет централизованный UI и SDK для динамических обновлений, избегая перезапусков приложений.

Декларативное управление состоянием кластера Kubernetes, где Git является единственным источником истины, а изменения применяются автоматически.

→Разверните агент GitOps, такой как Flux или ArgoCD, в кластере AKS. Настройте агент для мониторинга репозитория Git, содержащего манифесты Kubernetes, и автоматической синхронизации состояния кластера.

Почему: Эта pull-модель обеспечивает непрерывное согласование и обнаружение отклонений, что является основой GitOps. Она более надежна, чем push-конвейеры `kubectl`.

Управление состоянием Terraform для командной работы, обеспечение безопасности и предотвращение одновременных изменений.

→Настройте бэкенд Terraform для использования учетной записи хранения Azure. Это обеспечивает удаленное хранение состояния, с блокировкой состояния, обрабатываемой через аренду Azure Blob.

Почему: Предотвращает повреждение файла состояния из-за одновременных операций `apply` и исключает конфиденциальные данные состояния из системы контроля версий.

Источник↗

В монорепозитории запускать конвейер CI приложения только при изменении файлов в его конкретной директории (или в общей директории).

→В YAML конвейера используйте фильтр `trigger.paths.include` для указания соответствующих директорий, например, `include: ['/apps/frontend/**', '/apps/shared/**']`.

Почему: Это позволяет избежать ненужных сборок для несвязанных изменений кода, экономя время CI и вычислительные ресурсы.

Оптимизировать стадию тестирования с быстрыми (модульными) и медленными (интеграционными) тестами для более быстрой обратной связи.

→Запускайте модульные тесты и интеграционные тесты в параллельных заданиях в рамках одной стадии.

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

Автоматически версионировать пакет библиотеки на основе истории коммитов, чтобы четко сообщать о влиянии изменений (breaking, feature, fix).

→Интегрируйте инструмент, такой как GitVersion, в конвейер CI. Он анализирует сообщения коммитов, ветки и теги для автоматического расчета версии SemVer (Major.Minor.Patch).

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

Развертывание приложения в нескольких географических регионах поочередно, с проверкой после каждого регионального развертывания.

→Используйте многостадийный YAML конвейер с последовательными стадиями, по одной для каждого региона, используя `dependsOn` для обеспечения порядка. Используйте шлюзы среды между стадиями для проверки.

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

Настроить конвейер для поддержки модели разработки на основе магистральной ветви (trunk-based development), гарантируя, что основная ветвь всегда готова к развертыванию.

→Настройте триггер CI для ветки `main`. Обеспечьте PR политикой проверки сборки, которая выполняет быстрые, всесторонние тесты. Интегрируйте быстрые уведомления (например, в Teams/Slack) о сбоях сборки.

Почему: Немедленная обратная связь критически важна в разработке на основе магистральной ветви. Эта комбинация предотвращает слияние нерабочего кода и обеспечивает быстрое устранение проблем при их возникновении.

Эффективно передавать большие артефакты (например, модели ML, >5 ГБ) между стадиями конвейера.

→Загрузите большой артефакт в Azure Blob Storage на стадии производителя. Передайте URI BLOB-объекта на стадию потребителя в качестве выходной переменной.

Почему: Azure Blob Storage более экономичен и производителен, чем встроенные артефакты конвейера, для файлов размером в несколько гигабайт.

Сократить время сборки, избегая повторной загрузки зависимостей (например, NuGet, npm) при каждом запуске.

→Используйте задачу `Cache@2`. Определите ключ на основе файла блокировки пакета (например, `packages.lock.json`). Задача будет хранить и восстанавливать папку зависимостей.

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

Создавать или развертывать один и тот же код для нескольких целей (например, разных ОС, регионов) параллельно.

→Используйте `strategy: matrix` в задании конвейера YAML. Определите переменные для каждой комбинации, что сгенерирует задание для каждой записи матрицы.

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

Реализовать канареечное развертывание в AKS, которое автоматически переключает трафик и продвигает или откатывает изменения на основе метрик в реальном времени.

→Используйте контроллер прогрессивной доставки, такой как Flagger, интегрированный с service mesh (например, Istio) и поставщиком метрик (например, Prometheus).

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

Конвейер приложения должен запускаться при изменении кода в его собственном репозитории ИЛИ в отдельном, общем репозитории библиотеки.

→В YAML приложения определите общую библиотеку в `resources.repositories` и настройте блок `trigger` для этого ресурса.

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

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

→Используйте многостадийный конвейер с отдельными стадиями apply и destroy для IaC (Terraform/Bicep). Настройте стадию destroy с `condition: always()`.

Почему: Условие `always()` гарантирует выполнение стадии очистки независимо от успеха или неудачи предыдущих стадий, предотвращая появление потерянных ресурсов.

Предотвратить продолжение развертывания в production, если нет утвержденного запроса на изменение в инструменте ITSM, таком как ServiceNow.

→Настройте шлюз среды, который вызывает шлюз "Query ServiceNow" для проверки статуса запроса на изменение.

Почему: Автоматизирует интеграцию с корпоративными процессами управления изменениями, обеспечивая соответствие без ручных передач.

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

→Настройте пул агентов Azure DevOps, используя масштабируемый набор виртуальных машин Azure (VMSS), настроенный на автоматическое масштабирование на основе количества ожидающих заданий.

Почему: Агенты VMSS сочетают в себе настраиваемость локальных агентов с эластичностью облачных агентов, оптимизируя производительность и стоимость.

Развертывание изменений схемы базы данных таким образом, чтобы предотвратить потерю данных и поддерживать откаты.

→Используйте инструмент миграции (например, Flyway, DbUp). Реализуйте шаблон expand/contract для изменений схемы, чтобы сохранить обратную совместимость.

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

Локальные агенты испытывают нехватку дискового пространства из-за накопленных артефактов сборки.

→В YAML конвейера, на уровне задания, настройте `workspace: clean: all`.

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

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

→Определите ресурс контейнера (например, SQL Server, Postgres) как службу в YAML конвейера. Затем тестовое задание может подключиться к этой временной службе.

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

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

→В Azure Artifacts создайте канал и настройте восходящие источники, указывающие на публичные репозитории. Настройте клиенты для потребления пакетов из канала Azure Artifacts.

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

Развернуть Helm chart в нескольких средах (dev, prod) с различными значениями конфигурации.

→Используйте отдельные файлы `values-<env>.yaml` для каждой среды. В задаче `HelmDeploy` используйте вход `valueFile` для указания соответствующего файла и `overrideValues` для внедрения динамических значений, таких как теги образов.

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

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

→Храните секреты в Azure Key Vault. В Azure DevOps создайте группу переменных, связанную с Key Vault. Ссылайтесь на секреты из группы переменных в конвейере.

Почему: Централизует управление секретами, обеспечивает ротацию без изменений конвейера и предоставляет надежный контроль доступа и аудит через Key Vault.

Внедрить сканирование безопасности в конвейер CI для обнаружения уязвимостей в коде приложения (SAST) и сторонних зависимостях (SCA).

→Интегрируйте расширение Microsoft Security DevOps, которое включает несколько сканеров. Также рассмотрите GitHub Advanced Security for Azure DevOps для нативного, комплексного набора.

Почему: Этот "сдвиг влево" подход выявляет уязвимости на ранних этапах жизненного цикла разработки, снижая затраты и риски.

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

→Удалите постоянные роли "Участник/Владелец". Используйте подключения службы конвейера для развертываний. В экстренных случаях используйте Azure AD Privileged Identity Management (PIM) для повышенного доступа Just-In-Time (JIT).

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

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

→Используйте Azure Key Vault, интегрированный с Secrets Store CSI Driver для AKS. Используйте удостоверение рабочей нагрузки для подов для аутентификации в Key Vault.

Почему: Монтирует секреты непосредственно в поды из Key Vault, избегая использования Kubernetes Secrets. Обеспечивает идентификацию на уровне пода и бесшовную ротацию секретов.

Источник↗

Обеспечить, чтобы в production кластер Kubernetes могли быть развернуты только просканированные и подписанные образы контейнеров.

→Используйте доверие к содержимому Azure Container Registry (ACR) для подписи образов. Используйте Microsoft Defender for Containers для сканирования. Используйте Azure Policy для Kubernetes для применения политик в AKS.

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

Подключить Azure Pipelines к ресурсам Azure без использования клиентских секретов или сертификатов.

→Создайте подключение службы Azure Resource Manager с использованием "Федерации удостоверений рабочей нагрузки" (Workload Identity Federation).

Почему: Устраняет необходимость управлять и ротировать секреты, улучшая состояние безопасности системы CI/CD.

Развертывание в подписку Azure клиента из вашей организации Azure DevOps без обмена секретами.

→Разверните локальный агент в среде Azure клиента. Назначьте управляемое удостоверение (Managed Identity) виртуальной машине/VMSS агента и предоставьте ему необходимые роли RBAC.

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

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

→Используйте единый проект с путями областей для каждой команды, чтобы предоставить им отфильтрованные бэклоги. Используйте планы поставок (Delivery Plans) для визуализации прогресса и зависимостей между командами.

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

Автоматически связывать коммиты/PR с элементами работы и изменять состояние элемента работы (например, на "Resolved") при слиянии PR.

→В настройках проекта включите "Автоматически завершать элементы работы с помощью pull requests". Разработчики должны использовать `#<ID>` в сообщениях коммитов или связывать PR.

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

Измерение ключевых метрик процесса, таких как Cycle Time, Lead Time и метрики DORA, для анализа потока создания ценности.

→Используйте службу Azure DevOps Analytics и ее канал OData. Подключите Power BI или используйте встроенные виджеты панели мониторинга для визуализации этих метрик.

Почему: Служба Analytics предоставляет базовые данные для ключевых метрик потока и SRE, обеспечивая улучшение процессов на основе данных.

Исследовать периодические медленные времена отклика, которые скрыты средними метриками производительности.

→В Application Insights используйте вкладку "Производительность" с анализом процентилей (P95, P99) и "Поиск транзакций" для детального изучения конкретных медленных образцов запросов.

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

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

→Инструментируйте все службы с помощью SDK Application Insights. Он автоматически распространяет идентификатор корреляции W3C Trace Context по вызовам служб.

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

Проактивно отслеживать Цель уровня обслуживания (SLO) приложения и получать оповещения *до* нарушения SLO.

→Определите SLI, используя KQL-запросы в Azure Monitor. Создайте правило оповещения, которое срабатывает на основе скорости расходования бюджета ошибок (как быстро расходуется бюджет).

Почему: Оповещения о скорости выгорания являются предиктивными, предоставляя время для реакции до нарушения SLO и значительного воздействия на пользователей.

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

→В качестве шага после развертывания или шлюза выпуска запустите тесты доступности Application Insights (синтетический мониторинг), которые имитируют ключевые пользовательские сценарии.

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

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

→Используйте задачу Azure Pipelines для создания "Аннотаций выпуска" в Application Insights, которая размещает маркер на графиках метрик.

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

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

→Интегрируйте Azure Chaos Studio в конвейеры выпуска. Создавайте эксперименты, которые внедряют сбои (например, выключение ВМ, задержка сети) и проверяют поведение системы.

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