Microsoft AZ-400: Управление исходным кодом и репозиториями — Руководство по подготовке
Часть Microsoft DevOps Engineer Expert AZ-400 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.
Автоматизация, хуки, большие файлы и безопасность
Хуки Git повышают качество на всех этапах:
- Хуки pre-commit локально обеспечивают проверку кода (линтинг), форматирование, поиск секретов и запуск модульных тестов перед тем, как разработчик создаст коммит. Они должны быть быстрыми и детерминированными.
- Хуки pre-push блокируют отправку кода, который не прошел интеграционные тесты или проверки политик. Предоставляйте общекомандные скрипты хуков через инструменты (например, Husky для JavaScript) и документируйте их опциональное использование.
- Серверные хуки в управляемых сервисах различаются: GitHub поддерживает серверные веб-хуки и обязательные проверки статуса (required status checks); Azure DevOps Services не позволяет использовать пользовательские серверные хуки, но поддерживает политики ветвей, проверки сборок, сервисные хуки и проверки статуса от внешних систем. В Azure DevOps Server (on-prem) серверные хуки возможны.
Large File Storage (Git LFS) хранит большие бинарные файлы вне базы объектов Git, поддерживая производительность репозитория:
- Отслеживайте шаблоны с помощью
undefined
или конкретные типы бинарных файлов. Закоммитьте файл .gitattributes, чтобы все участники использовали LFS единообразно.
- Мигрируйте историю, выполнив
undefined
с фильтрами по путям, чтобы переписать большие бинарные файлы в указатели. Скоординируйте действия с командой и приостановите отправку изменений (push); используйте force-push с осторожностью и обновите клоны.
- Управляйте пропускной способностью, избегая ненужного процесса smudging. Используйте
undefined
и выборочно выполняйте
undefined
. Кэшируйте LFS в CI и рассмотрите возможность использования репозиториев артефактов для бинарных файлов, которым не обязательно находиться в Git.
Обеспечение безопасности должно быть сдвинуто влево (shift-left) и основано на политиках:
- GitHub Advanced Security (GHAS) предоставляет сканирование секретов (включая защиту от push), сканирование кода с помощью CodeQL и проверку зависимостей для выявления раскрытых учетных данных, уязвимостей в коде и рисков в цепочке поставок. Установите их в качестве обязательных проверок для PR. Для Azure Repos используйте Advanced Security for Azure DevOps, чтобы получить аналогичные функции сканирования секретов, SAST через CodeQL и анализа зависимостей.
- Сканирование секретов следует настроить так, чтобы блокировать push-операции с секретами высокой степени достоверности и оповещать специалистов по безопасности. Поддерживайте пользовательские детекторы для специфичных шаблонов организации.
- Сканирование кода с помощью CodeQL должно запускаться по триггерам pull_request и по расписанию, загружая результаты в формате SARIF в качестве проверок статуса. Настраивайте наборы запросов (query packs), чтобы уменьшить количество ложных срабатываний и обеспечить покрытие критически важных участков кода.
- Проверка зависимостей выявляет изменения версий и известные предупреждения (advisories) во время рецензирования PR; используйте это для соблюдения SLA по устранению уязвимостей и управления лицензиями.
Миграция, управление версиями и релизами
Миграция с TFVC на Git требует стратегии и инструментов, соответствующих допустимому уровню риска:
- Для полнофункциональной миграции с сохранением полной истории и связей с рабочими элементами используйте git-tfs для клонирования путей TFVC в Git, сохраняя наборы изменений и сопоставляя пользователей. Разделяйте по приложениям или веткам, чтобы репозитории Git оставались управляемыми. Очищайте большие двоичные файлы с помощью LFS во время или после миграции.
- Для упрощенной миграции текущего состояния используйте инструмент Azure DevOps Import, чтобы создать новый репозиторий Git из TFVC (или другого хоста Git), опционально ограничивая историю. Это сокращает продолжительность и риски, но жертвует глубокой исторической детализацией.
- Сохраняйте прослеживаемость путем миграции тегов/меток, сопоставления веток TFVC с ветками Git и сохранения зеркала TFVC в режиме «только для чтения» для аудита. Проверьте на пилотном проекте, заморозьте исходный код на время перехода и выполните верификационную матрицу (сборки, тесты и развертывание).
Внедрите семантическое версионирование для ясности и автоматизации:
- Используйте SemVer 2.0.0: MAJOR.MINOR.PATCH с необязательными предварительными версиями (например, -rc.1) и метаданными сборки (+build.45). Помечайте релизы аннотированными тегами (git tag -a v1.4.2 -m “Release 1.4.2”) и подписывайте теги для аудита.
- Автоматизируйте повышение версий в CI/CD:
- Формируйте версию на основе коммитов с помощью Conventional Commits и инструмента для релизов (например, GitVersion или semantic-release), чтобы вычислять следующую версию на основе типов и областей коммитов.
- Автоматически обновляйте номера сборок и версии пакетов; прерывайте сборку при расхождении версий или конфликтах тегов.
- Согласуйте управление версиями со стратегией ветвления:
- Trunk-based: ветка main всегда готова к релизу; создавайте релизные теги из main; используйте короткоживущие релизные ветки только для стабилизации.
- GitFlow: ветки release/* содержат замороженную минорную версию; ветка hotfix/* создается из main для срочных исправлений; изменения вливаются обратно как в develop, так и в main, а тег ставится по завершении слияния.
- GitHub Flow: ставьте тег на main при развертывании; используйте теги предварительных версий для canary-релизов.
Интегрируйте автоматизацию релизов с политиками репозитория: требуйте успешных сборок с релизными конвейерами, блокируйте слияния без обновленных списков изменений, сгенерированных из коммитов, и требуйте подписанных коммитов/тегов в регулируемых средах.
Сценарий практической задачи
Starbucks необходимо консолидировать несколько устаревших приложений, управляемых в TFVC, в Azure Repos Git, одновременно устанавливая единое управление, сканирование безопасности и масштабируемые рабочие процессы как для сервисов, так и для мобильных приложений.
- Выбор топологии репозиториев и стратегии ветвления
- Действие: Внедрить trunk-based development с монорепозиторием для общих библиотек и несколькими сфокусированными репозиториями для независимо выпускаемых сервисов. Включить sparse checkout для монорепозитория в скриптах для новых разработчиков.
- Почему: Trunk-based сокращает долг по слияниям и ускоряет интеграцию; монорепозиторий централизует общий код и позволяет проводить атомарные рефакторинги, а sparse checkout избавляет команды, работающие только с частью кода, от необходимости загружать полную историю и рабочее дерево.
- Миграция проектов TFVC в Git с сохранением истории там, где это целесообразно
- Действие: Использовать git-tfs для миграции основных кодовых баз веба и мобильных приложений с полной историей, сопоставляя пути к большим файлам с Git LFS во время миграции. Для небольших утилит использовать инструмент Azure DevOps Import для переноса только текущего состояния.
- Почему: git-tfs сохраняет критически важную прослеживаемость для флагманских приложений; выборочное использование инструмента Import ускоряет миграции с низким риском и сокращает продолжительность проекта.
- Настройка защищенных веток и политик ветвления
- Действие: Защитить ветки main и release/*, запретив Force push/Delete; требовать двух рецензентов, разрешения всех комментариев, привязки рабочего элемента и прохождения валидации сборки с фильтрами по путям. Ограничить слияния до Squash для репозиториев сервисов и до Rebase and fast-forward для монорепозитория, чтобы сохранить линейную историю. Отключить «Обход политик» для всех, кроме небольшой группы инженеров по релизам.
- Почему: Политики как код (Policy-as-code) ужесточают контроль качества и возможности аудита. Стратегии слияния отражают предпочтения команд: Squash упрощает откат и cherry-pick для сервисов; линейная история в монорепозитории ускоряет операции blame и bisect.
- Стандартизация практики pull request
- Действие: Добавить файл pull_request_template.md в каталог .azuredevops/ с разделами для оценки рисков, доказательств тестирования, влияния на производительность и плана отката. Поощрять раннее создание Draft PR; включить Auto-complete для всех PR. Настроить обязательных рецензентов на основе путей к файлам для эмуляции владения кодом и добавить файл CODEOWNERS для репозиториев на GitHub.
- Почему: Шаблоны повышают базовый уровень качества ревью; Draft PR способствуют раннему сотрудничеству; Auto-complete устраняет время простоя; маршрутизация по владельцам кода направляет нужных рецензентов на соответствующие изменения.
- Внедрение хуков и шлюзов CI
- Действие: Распространять хуки pre-commit/pre-push через инструменты репозитория для принудительного выполнения линтинга, проверок на секреты и юнит-тестов; обеспечить их быстрое выполнение. Использовать валидацию сборок в Azure Pipelines как канонический механизм контроля и добавлять проверки статуса от сканеров безопасности. Избегать пользовательских серверных хуков; использовать сервисные хуки для уведомления внешних систем.
- Почему: Локальные хуки выявляют проблемы на ранней стадии, не блокируя совместную работу; принудительный контроль на стороне сервера в Azure DevOps лучше всего реализуется с помощью политик ветвления и проверок статуса для надежности и аудита.
- Управление большими файлами с помощью Git LFS
- Действие: Отслеживать шаблоны двоичных файлов (изображения, дизайнерские ассеты, медиа для тестов) с помощью git lfs track; мигрировать устаревшие двоичные файлы с помощью git lfs migrate import. Настроить CI для установки GIT_LFS_SKIP_SMUDGE=1 и выборочной загрузки для снижения использования полосы пропускания; кэшировать артефакты LFS на агентах сборки.
- Почему: Это сохраняет репозитории быстрыми и предотвращает избыточное использование сети, поддерживая при этом воспроизводимость сборок.
- Интеграция Advanced Security
- Действие: Включить GitHub Advanced Security в репозиториях GitHub и Advanced Security for Azure DevOps в Azure Repos. Активировать сканирование секретов с защитой при push, запускать CodeQL для PR и по ночам, а также включить проверки зависимостей. Блокировать завершение PR при обнаружении уязвимостей высокой степени серьезности.
- Почему: Это смещает безопасность «влево», предотвращая утечку учетных данных и попадание уязвимых паттернов в ветку main, и предоставляет действенные инсайты во время ревью.
- Автоматизация семантического версионирования и тегирования
- Действие: Использовать GitVersion в Azure Pipelines для вычисления SemVer на основе истории веток и коммитов; подписывать и отправлять аннотированные теги в конвейерах релиза; генерировать примечания к выпуску из Conventional Commits. Использовать ветки release/* только для стабилизации; создавать hotfix из тегированной ветки main.
- Почему: Детерминированные, автоматизированные версии улучшают прослеживаемость и воспроизводимость развертываний, а подписанные теги поддерживают соответствие требованиям.
Эта последовательность снижает риски миграции, обеспечивает последовательный контроль качества и безопасности и оптимизирует поставку, точно согласовывая управление репозиториями с масштабируемыми операциями DevOps.
Отработать эти вопросы → · Тесты на время на ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Сдайте экзамен →