Стратегия разработки Azure DevOps
| Новые возможности | Сообщество разработчиков | DevOps Блог | |
Стратегия развития продуктов
Этот список функций является обзором нашей стратегии. Он определяет некоторые из важных функций, над которыми мы сейчас работаем, и грубым временем, когда вы можете ожидать их просмотра. Она не является всеобъемлющей, но призвана обеспечить некоторую видимость ключевых инвестиций. В верхней части вы найдете список наших крупных многоквартовых инициатив и функций, на которые они разбиваются. Далее вы найдете полный список важных функций, которые мы планировали.
Каждая функция связана со статьей, в которой можно узнать больше о конкретном элементе. Эти функции и даты являются текущими планами и подлежат изменению. Столбцы временных интервалов отражают, когда ожидается, что функция будет доступна.
Инициативы
Расширенная безопасность GitHub для Azure DevOps
GitHub Advanced Security (GHAS) для Azure DevOps теперь общедоступен. Теперь любой администратор коллекции проектов может включить расширенную безопасность для своей организации, проектов и репозиториев из параметров проекта или параметров организации. Дополнительные сведения о настройке GitHub Advanced Security для Azure DevOps см. в нашей документации.
Новые возможности, которые мы ожидаем обеспечить, включают:
| Функция | Площадь | Квартальная |
|---|---|---|
| Отображение контекстных комментариев для запросов на вытягивание, содержащих недавно появившиеся результаты расширенной безопасности | Расширенная безопасность GitHub для Azure DevOps | 2024 Q4 |
| Определение допустимости обнаруженных секретов партнеров | Расширенная безопасность GitHub для Azure DevOps | 2024 Q4 |
| Автоматическое исправление обнаруженных уязвимостей проверки зависимостей с помощью обновлений безопасности Dependabot | Расширенная безопасность GitHub для Azure DevOps | Будущая |
Минимизация рисков, связанных с кражей учетных данных
Azure DevOps поддерживает множество различных механизмов проверки подлинности, включая обычную проверку подлинности, личные маркеры доступа (PATS), SSH и идентификатор Microsoft Entra ID (ранее Azure Active Directory). Эти механизмы не создаются одинаково с точки зрения безопасности, особенно если речь идет о потенциале кражи учетных данных. Например, непреднамеренная утечка учетных данных, таких как PATs, может позволить злоумышленникам в организации Azure DevOps, где они могут получить доступ к критически важным ресурсам, таким как исходный код, сводить к атакам цепочки поставок или даже сводить к компрометации производственной инфраструктуры. Чтобы свести к минимуму риски кражи учетных данных, мы сосредоточим наши усилия в предстоящих кварталах в следующих областях:
Разрешить администраторам улучшить безопасность проверки подлинности с помощью политик уровня управления.
Сокращение потребности в PAT и других украденных секретах путем добавления поддержки для более безопасных альтернатив.
Углубление интеграции Azure DevOps с Идентификатором Microsoft Entra для повышения поддержки различных функций безопасности.
Избегайте необходимости хранить секреты рабочей среды в подключениях к службе Azure Pipelines.
| Функция | Площадь | Квартальная |
|---|---|---|
| API жизненного цикла PAT | Общие |  2022 Q4 |
| Плоскость управления для личных маркеров доступа (PAT) | Общие | 2022 Q4 |
| Поддержка управляемого удостоверения и субъекта-службы (предварительная версия) | Общие | 2023 Q1 |
| Федерация удостоверений рабочей нагрузки для развертываний Azure (предварительная версия) | Pipelines | 2023 Q3 |
| Детализированные области для OAuth Azure Active Directory | Общие | 2023 Q3 |
| Поддержка управляемого удостоверения и субъекта-службы (GA) | Общие | 2023 Q3 |
| Федерация удостоверений рабочей нагрузки для подключения службы Azure (GA) | Pipelines | 2024 Q1 |
| Федерация удостоверений рабочей нагрузки для подключения службы Docker | Pipelines | 2024 H2 |
| Полная веб-поддержка политик условного доступа | Общие | 2024 H2 |
| Политики для отключения методов проверки подлинности | Общие | Будущая |
Улучшенные доски и интеграция GitHub
Существующая интеграция Azure Boards + GitHub уже несколько лет. Интеграция является отличной отправной точкой, но она не предлагает уровень трассировки, к которому привыкли наши клиенты. На основе отзывов клиентов мы объединили набор инвестиций для улучшения этой интеграции. Наша цель заключается в том, чтобы улучшить его, чтобы клиенты Azure Boards, которые решили использовать репозитории GitHub, могут поддерживать эквивалентный уровень трассировки с наличием репозиториев в Azure DevOps.
К этим инвестициям относятся:
| Функция | Площадь | Квартальная |
|---|---|---|
| Добавление ссылки на фиксацию или извлечение запроса на GitHub из рабочего элемента | Boards | 2024 Q1 |
| Дополнительные сведения о запросе на вытягивание GitHub | Boards | 2024 Q1 |
| Повышение масштабируемости при поиске и связывании GitHub репозитории в проект Azure DevOps |
Boards | 2024 Q2 |
| Ссылки AB# на запрос на вытягивание GitHub (предварительная версия) | Boards | 2024 Q2 |
| Создание ветви в репозитории GitHub из рабочего элемента | Boards | 2024 Q3 |
| Поддержка GitHub Enterprise Cloud с размещением данных | Boards | 2024 Q4 |
| ! упоминает поддержку запросов на вытягивание GitHub | Boards | 2025 Q1 |
| Отображение состояния сборки при использовании конвейера сборки YAML с репозиторием GitHub | Boards | 2025 Q1 |
| Состояние этапа отчета для рабочего элемента при использовании конвейера выпуска YAML с репозиторием GitHub | Boards | Будущая |
Четность компонентов YAML и конвейеров выпуска
За последние несколько лет все инвестиции в конвейеры YAML были в области конвейеров YAML. Кроме того, все наши улучшения безопасности были для конвейеров YAML. Например, при использовании конвейеров YAML контроль над защищенными ресурсами (например, репозиториями, подключениями к службам и т. д.) находится в руках владельцев ресурсов, а не авторов конвейеров. Маркеры доступа к заданию, используемые в конвейерах YAML, относятся к определенным репозиториям, указанным в файле YAML. Это всего два примера функций безопасности, доступных для конвейеров YAML. По этим причинам рекомендуется использовать конвейеры YAML по сравнению с классическими. Внедрение YAML по сравнению с классической версией было значительным для сборок (CI). Однако многие клиенты продолжали использовать классические конвейеры управления выпусками по YAML для выпусков (CD). Основной причиной этого является отсутствие четности в различных функциях CD между двумя решениями. За последний год мы рассмотрели несколько пробелов в этой области, в частности, в проверках. Проверки — это основной механизм в конвейерах YAML для продвижения сборки с одного этапа на другой. Мы будем продолжать устранять пробелы в других областях в течение следующего года. Мы сосредоточимся на пользовательском интерфейсе, возможности трассировки и средах.
| Функция | Площадь | Квартальная |
|---|---|---|
| Аудит для проверок | Pipelines | 2022 Q4 |
| Пользовательские переменные в проверках | Pipelines | 2023 Q1 |
| Проверка масштабируемости | Pipelines | 2023 Q2 |
| Обход утверждений и проверок | Pipelines | 2023 Q4 |
| Последовательные утверждения и другие проверки | Pipelines | 2024 Q1 |
| Отложенные утверждения | Pipelines | 2024 Q1 |
| Повторное выполнение одного этапа | Pipelines | 2024 Q1 |
| Ручная очередь этапов | Pipelines | 2024 H2 |
| Параллелизм на уровне стадии | Pipelines | 2024 Q3 |
| Трассировка на уровне стадии | Pipelines | 2024 H2 |
| Подключения к службе в проверках | Pipelines | Будущая |
| Проверка расширяемости | Pipelines | Будущая |
Все функции
Azure DevOps Services
Azure DevOps Server
Отправка отзыва
Мы хотели бы услышать то, что вы думаете об этих функциях. Сообщите о любых проблемах или предложите функцию с помощью Сообщество разработчиков.
Вы также можете получить советы и ваши вопросы, ответы сообщества на Stack Overflow.