Настройка политик хранения для сборок, выпусков и тестов
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Политики хранения позволяют задать срок хранения выполнений, выпусков и тестов в системе. Чтобы сэкономить место в хранилище, необходимо удалить старые запуски, тесты и выпуски.
В параметрах проекта доступны следующие политики хранения в Azure DevOps:
- Конвейер — задайте время хранения артефактов, символов, вложений, запусков и выполнения запросов на вытягивание.
- Выпуск (классическая версия) — задайте, следует ли сохранять сборки и просматривать параметры хранения по умолчанию и максимальному значению хранения.
- Тест — задайте время, пока выполняется автоматическое и ручное тестирование, результаты и вложения.
Примечание.
Если вы используете локальный сервер, вы также можете указать политики хранения по умолчанию для проекта, а также при окончательном уничтожении выпусков. Дополнительные сведения о хранении выпусков см. далее в этой статье.
Необходимые компоненты
По умолчанию управлять политиками хранения могут участники групп "Участники", "Администраторы сборки", "Администраторы проекта" и "Администраторы выпуска".
Для управления политиками хранения требуется одна из следующих подписок:
Вы также можете приобрести месячный доступ к Azure Test Plans и назначить уровень доступа Обычная + планы тестирования. См. раздел Проверка доступа по ролям пользователей.
Настройка политик хранения
Войдите в проект.
Перейдите на вкладку "Параметры " параметров проекта.
Выберите "Хранение выпуска" в разделе "Конвейеры" или "Хранение" в разделе "Тест".
- Выберите срок хранения выпуска, чтобы настроить политики хранения выпусков и настроить время удаления или окончательного уничтожения выпусков.
- Выберите "Хранение", чтобы настроить время выполнения ручного и автоматического тестирования.
Настройка политик хранения
Войдите в проект.
Перейдите на вкладку "Параметры " параметров проекта.
Выберите параметры или хранение выпуска в разделе "Конвейеры" или "Хранение" в разделе "Тест".
- Выберите параметры , чтобы настроить политики хранения для запусков, артефактов, символов, вложений и выполнения запросов на вытягивание.
- Выберите срок хранения выпуска, чтобы настроить политики хранения выпусков и настроить время удаления или окончательного уничтожения выпусков.
- Выберите "Хранение", чтобы настроить время выполнения ручного и автоматического тестирования.
Внимание
Azure Pipelines больше не поддерживает политики хранения для каждого конвейера. Рекомендуется использовать правила хранения на уровне проекта.
Настройка политик хранения запуска
В большинстве случаев вам не нужно хранить завершенные запуски дольше определенного количества дней. С помощью политик хранения вы можете контролировать количество дней , которые необходимо сохранить перед удалением каждого запуска.
Перейдите на вкладку "Параметры " параметров проекта.
Выберите "Параметры " в разделе "Конвейеры".
- Задайте количество дней для хранения артефактов, символов и вложений.
- Задайте количество дней для поддержания выполнения
- Задайте количество дней для поддержания выполнения запроса на вытягивание
- Задайте количество последних запусков , которые будут храниться для каждого конвейера.
Предупреждение
Azure DevOps больше не поддерживает правила хранения для каждого конвейера. Единственным способом настройки политик хранения для YAML и классических конвейеров является использование параметров проекта, описанных выше. Вы больше не можете настроить политики хранения для каждого конвейера.
Для количества последних запусков для каждого конвейера требуется немного более подробное описание. Интерпретация этого параметра зависит от типа репозитория, создаваемого в конвейере.
Azure Repos: Azure Pipelines сохраняет настроенное количество последних запусков для ветвь по умолчанию конвейера и для каждого защищенная ветвь репозитория. Ветвь с настроенными политиками ветви считается защищенная ветвь.
В качестве примера рассмотрим репозиторий с двумя ветвями
main
иrelease
.pipeline's default branch
Представьте, что этоmain
ветвь, иrelease
ветвь имеет политику ветвей, что делает ее защищенная ветвь. В этом случае, если вы настроили политику для сохранения трех запусковmain
, сохраняются оба последних трех запуска и последние три запускаrelease
ветви. Кроме того, сохраняются последние три запуска этого конвейера (независимо от ветви).Чтобы уточнить эту логику дальше, предположим, что список запусков для этого конвейера выглядит следующим образом, с самым последним запуском в верхней части. В таблице показано, какие запуски будут сохранены, если вы настроили сохранение последних трех запусков (игнорируя влияние параметра числа дней):
Бежать # Ветвь Сохранено / не сохранено Почему? Запуск 10 main Сохранено Последние 3 для основного и последнего 3 для конвейера Запуск 9 Branch1 Сохранено Последние 3 для конвейера Запуск 8 Branch2 Сохранено Последние 3 для конвейера Запуск 7 main Сохранено Последние 3 для основного Запуск 6 main Сохранено Последние 3 для основного Запуск 5 main Не сохранено Ни последние 3 для основного, ни для конвейера Запуск 4 main Не сохранено Ни последние 3 для основного, ни для конвейера Запуск 3 Branch1 Не сохранено Ни последние 3 для основного, ни для конвейера Запуск 2 выпуска Сохранено Последняя версия 3 для выпуска Запуск 1 main Не сохранено Ни последние 3 для основного, ни для конвейера Все остальные репозитории Git: Azure Pipelines сохраняет настроенное количество последних запусков для всего конвейера.
TFVC: Azure Pipelines сохраняет настроенное количество последних запусков для всего конвейера независимо от ветви.
Какие части запуска удаляются
При удалении выполнения следующие сведения удаляются:
- Журналы
- Все артефакты конвейера и сборки
- Все символы
- Двоичные файлы
- Результаты теста
- Запуск метаданных
- Исходные метки (TFVC) или теги (Git)
Универсальные пакеты, NuGet, npm и другие пакеты не привязаны к хранению конвейеров.
При выполнении удаления
Политики хранения обрабатываются один раз в день. Время, когда политики получают обработанные переменные, так как мы распределяем работу в течение дня для целей балансировки нагрузки. Нет возможности изменить этот процесс.
Выполнение удаляется, если все следующие условия имеют значение true:
- Оно превышает количество дней, настроенных в параметрах хранения.
- Это не один из последних запусков, настроенных в параметрах хранения.
- Оно не отмечено для сохранения на неопределенный срок
- Он не сохраняется в выпуске
Автоматическая установка аренды хранения при выполнении конвейера
Аренды хранения используются для управления временем существования конвейера за пределами настроенных периодов хранения. Аренды хранения можно добавлять или удалять в конвейере, вызывая API аренды. Этот API можно вызвать в конвейере с помощью скрипта и использовать предопределенные переменные для runId и definitionId.
Аренда хранения может быть добавлена в запуск конвейера в течение определенного периода. Например, конвейер, который развертывается в тестовой среде, может храниться в течение более короткого времени, пока выполнение развертывания в рабочей среде может храниться дольше.
Настройка аренды хранения вручную при выполнении конвейера
Вы можете вручную настроить запуск конвейера, который будет сохранен с помощью меню "Дополнительные действия" на странице сведений о выполнении конвейера.
Удаление запуска
Вы можете удалить запуски с помощью меню "Дополнительные действия" на странице сведений о выполнении конвейера.
Примечание.
Если к запуску применяются какие-либо политики хранения, их необходимо удалить перед удалением. Инструкции см. в разделе "Сведения о выполнении конвейера" — удаление выполнения.
Настройка политик хранения выпусков
Политики хранения выпусков для классического конвейера выпуска определяют, как долго сохраняется выпуск и запуск, связанный с ним. С помощью этих политик вы можете контролировать количество дней , которые необходимо сохранить каждый выпуск после последнего изменения или развертывания, а также минимальное количество выпусков , которые должны храниться для каждого конвейера.
Таймер хранения в выпуске сбрасывается каждый раз, когда выпуск изменяется или развертывается на этапе. Минимальное количество выпусков, которые необходимо сохранить, имеет приоритет над числом дней. Например, если вы указываете сохранить не менее трех выпусков, последние три будут храниться на неопределенный срок независимо от числа указанных дней. Однако вы можете вручную удалить эти выпуски, если их больше не требуется. Дополнительные сведения о том, как работает хранение выпусков, см. ниже.
В качестве автора конвейера выпуска можно настроить политики хранения для выпусков конвейера на вкладке "Хранение ".
Политика хранения для YAML и конвейеров сборки одинакова. Параметры хранения конвейера можно просмотреть в разделе "Параметры проекта" для конвейеров.
Глобальная политика хранения выпусков
Если вы используете локальный Team Foundation Server или Azure DevOps Server, вы можете указать политику хранения выпусков по умолчанию и максимальные значения для проекта. Вы также можете указать, когда выпуски окончательно уничтожены (удалены с вкладки "Удаленные " в обозревателе сборок).
Если вы используете Azure DevOps Services, вы можете просмотреть, но не изменить эти параметры для проекта.
Параметры политики хранения глобальных выпусков можно просмотреть из параметров хранения выпуска проекта:
- Azure DevOps Services:
https://dev.azure.com/{organization}/{project}/_settings/release?app=ms.vss-build-web.build-release-hub-group
- Локальная среда:
https://{your_server}/tfs/{collection_name}/{project}/_admin/_apps/hub/ms.vss-releaseManagement-web.release-project-admin-hub
Максимальная политика хранения задает верхний предел для сохранения выпусков для всех конвейеров выпуска. Авторы конвейеров выпуска не могут настраивать параметры для их определений за пределами указанных здесь значений.
Политика хранения по умолчанию задает значения хранения по умолчанию для всех конвейеров выпуска. Авторы конвейеров сборки могут переопределить эти значения.
Политика уничтожения помогает сохранять выпуски в течение определенного периода времени после их удаления. Эта политика не может быть переопределена в отдельных конвейерах выпуска.
Настройка политик хранения на уровне коллекции
Для локальных серверов можно также задать политики хранения на уровне коллекции с пользовательскими правилами хранения. Эти политики хранения применяются к классическим конвейерам сборки. Страница на https://{your_server}/{collection_name}/_settings/buildqueue
странице управляет максимальными значениями и значениями по умолчанию.
Использование задачи копирования файлов для сохранения данных дольше
Задачу копирования файлов можно использовать для сохранения данных сборки и артефактов дольше, чем указано в политиках хранения. Задача "Файлы копирования" предпочтительна задаче "Публикация артефактов сборки", так как данные, сохраненные с помощью задачи "Публикация артефактов сборки", периодически очищаются и удаляются.
- task: CopyFiles@2
displayName: 'Copy Files to: \\mypath\storage\$(Build.BuildNumber)'
inputs:
SourceFolder: '$(Build.SourcesDirectory)'
Contents: '_buildOutput/**'
TargetFolder: '\\mypath\storage\$(Build.BuildNumber)'
Вопросы и ответы
Если я помечаю запуск или выпуск, который будет храниться на неопределенный срок, применяется ли политика хранения?
№ Ни политика хранения конвейера, ни максимальные ограничения, заданные администратором, не применяются при пометки отдельного запуска или выпуска, который будет храниться на неопределенный срок. Он останется до тех пор, пока вы не перестанете хранить его на неопределенный срок.
Разделы справки указать, что запуски, развернутые в рабочей среде, будут храниться дольше?
Если вы используете классические выпуски для развертывания в рабочей среде, настройте политику хранения в конвейере выпуска. Укажите количество дней, в течение которых должны храниться выпуски, развернутые в рабочей среде. Кроме того, укажите, что будут сохранены запуски, связанные с этим выпуском. Это переопределит политику хранения запуска.
Если для развертывания в рабочей среде используются многоэтапные конвейеры YAML, в параметрах проекта можно настроить только политику хранения. Невозможно настроить хранение на основе среды, в которой развертывается сборка.
Я не помечаю, чтобы быть сохранены на неопределенный срок. Тем не менее, я вижу большое количество запусков, сохраняемых. Как предотвратить это?
Это может быть по одной из следующих причин:
- Запуски помечаются кем-то в проекте, который будет храниться на неопределенный срок.
- Запуски используются выпуском, и выпуск содержит блокировку хранения для этих запусков. Настройте политику хранения выпуска, как описано выше.
Если вы считаете, что запуски больше не нужны или если выпуски уже удалены, то можно вручную удалить запуски.
Как работает настройка "минимальных выпусков"?
Минимальные выпуски для хранения определяются на уровне стадии. Это означает, что Azure DevOps всегда будет хранить указанное количество последних развернутых выпусков на этапе, даже если выпуски не будут храниться. Выпуск будет рассматриваться как минимум выпуск для стадии только при запуске развертывания на этом этапе. Рассматриваются как успешные, так и неудачные развертывания. Выпуски, ожидающие утверждения, не рассматриваются.
Как определяется период хранения при развертывании выпуска на нескольких этапах с разными периодами хранения?
Окончательный период хранения определяется путем рассмотрения дней, чтобы сохранить параметры всех этапов развертывания выпуска и принимать максимальные дни, чтобы сохранить их среди них. Минимальные выпуски для поддержания управляются на уровне стадии и не изменяются на основе выпуска, развернутого на нескольких этапах или нет. Сохранить связанные артефакты будут применимы при развертывании выпуска на этапе, для которого задано значение true.
Я удалил этап, для которого у меня есть некоторые старые выпуски. Какое хранение будет рассматриваться в этом случае?
По мере удаления этапа параметры хранения уровня стадии неприменимо. Azure DevOps будет возвращать уровень хранения по умолчанию по умолчанию для проекта.
Моя организация требует, чтобы мы сохраняли сборки и выпуски дольше, чем разрешено в параметрах. Как запросить более длительное хранение?
Единственный способ сохранить запуск или выпуск дольше, чем разрешено с помощью параметров хранения, — вручную пометить его на неопределенный срок. Невозможно настроить более длительный параметр хранения вручную. Обратитесь в службу поддержки Azure DevOps.
Вы также можете изучить возможность использования REST API для скачивания сведений и артефактов о запусках и их отправке в собственное хранилище или репозиторий артефактов.
Я потерял некоторые беги. Есть ли способ их вернуть?
Если вы считаете, что вы потеряли запуски из-за ошибки в службе, создайте запрос в службу поддержки немедленно, чтобы восстановить потерянную информацию. Если определение сборки было удалено вручную более чем за неделю до этого, его невозможно восстановить. Если запуски были удалены должным образом из-за политики хранения, невозможно восстановить потерянные запуски.
Разделы справки использовать Build.Cleanup
возможности агентов?
Build.Cleanup
Установка возможности для агентов приведет к тому, что задания очистки пула будут направляться только этим агентам, оставляя остальные свободные для регулярной работы. При удалении запуска конвейера артефакты, хранящиеся за пределами Azure DevOps, удаляются с помощью задания, выполняемого агентами. Когда пул агентов получает насыщенный с заданиями очистки, это может вызвать проблему. Решением этого является назначение подмножества агентов в пуле, которые являются агентами очистки. Если какие-либо агенты Build.Cleanup
установлены, только эти агенты будут запускать задания очистки, оставляя остальные агенты свободными для продолжения выполнения заданий конвейера. Функциональные возможности очистки можно включить, перейдя к возможностям агента>и установив равный 1
параметру.Build.Cleanup
Что происходит с артефактами общей папки при удалении сборки
При удалении сборки с общими артефактами файловой папки новая задача сборки помещается в очередь агента сборки для очистки этих файлов. Агент выбирается для выполнения этой задачи на основе следующих критериев: доступен ли агент с Build.Cleanup
возможностью?
Доступен ли агент, выполняющий сборку?
Доступен ли агент из одного пула?
Доступен ли агент из аналогичного пула?
Доступен ли любой агент?
Будут ли автоматические результаты теста, опубликованные в рамках выпуска, сохраненного до удаления выпуска?
Результаты теста, опубликованные на этапе выпуска, сохраняются, как указано политикой хранения, настроенной для результатов теста. Результаты теста не сохраняются до тех пор, пока выпуск не будет сохранен. Если вам нужны результаты теста до выпуска, задайте параметры хранения для автоматического тестирования в параметрах Project соответствующим образом, чтобы никогда не удалять. Это гарантирует удаление результатов теста только при удалении выпуска.
Удалены ли результаты теста вручную?
№ Результаты теста вручную не удаляются.
Как сохранить метки или теги системы управления версиями?
Внимание
Все метки или теги элемента управления версиями, применяемые во время конвейера сборки, которые не создаются автоматически из задачи "Источники", будут сохранены, даже если сборка удалена. Однако все метки и теги системы управления версиями, которые создаются автоматически задачей "Источники" во время сборки, считаются частью артефактов сборки и удаляются при ее удалении.
Если метки или теги системы управления версиями должны сохраняться даже при удалении сборки, их необходимо либо применить в рамках выполнения задачи конвейера, либо добавить вручную за пределы конвейера, либо сохранить сборку на неопределенный срок.
Что происходит с конвейерами, которые используются в других конвейерах?
Классические выпуски сохраняют конвейеры, которые они используют автоматически.
Что происходит с конвейерами, которые используются в других конвейерах?
Классические выпуски сохраняют конвейеры, которые они используют автоматически. При использовании YAML можно также создать многоэтапный конвейер YAML для представления выпуска и использования в нем другого конвейера YAML в качестве ресурса. Конвейер ресурсов будет храниться автоматически, пока конвейер выпуска сохраняется.