Настройка политик хранения для сборок, выпусков и тестов

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

В параметрах проекта доступны следующие политики хранения в Azure DevOps:

1. Конвейер — задайте время хранения артефактов, символов, вложений, запусков и выполнения запросов на вытягивание.
2. Выпуск (классическая версия) — задайте, следует ли сохранять сборки и просматривать параметры хранения по умолчанию и максимальному значению хранения.
3. Тест — задайте время, пока выполняется автоматическое и ручное тестирование, результаты и вложения.

Примечание.

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

Требования

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

Для управления политиками хранения требуется одна из следующих подписок:

• Предприятие
• Test Professional
• MSDN Platforms

Вы также можете приобрести месячный доступ к Azure Test Plans и присвоить уровень доступа Базовый + планы тестирования. См. раздел Проверка доступа по ролям пользователей.

Настройка политик хранения

1. Войдите в проект.

2. Перейдите на вкладку "Параметры" параметров проекта.

3. Выберите настройки или удержание выпусков в разделе Конвейеры или удержание в разделе Тест.

   • Выберите Настройки, чтобы настроить политики хранения для запусков, артефактов, символов, вложений и запусков pull request.
   • Выберите срок хранения выпуска, чтобы настроить политики хранения выпусков и настроить время удаления или окончательного уничтожения выпусков.
   • Выберите «Хранение», чтобы установить, как долго сохранять ручные и автоматические тестовые прогоны.

   

Настройка политик хранения запуска

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

1. Перейдите на вкладку Настройки в параметрах проекта.

2. Выберите Параметры в разделе Конвейеры.

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

Предупреждение

Azure DevOps больше не поддерживает правила хранения для каждого конвейера. Единственным способом настройки политик хранения для YAML и классических конвейеров является использование параметров проекта, описанных выше. Вы больше не можете настроить политики хранения для каждого конвейера.

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

• Azure Repos: Azure Pipelines сохраняет настроенное количество последних запусков для ветви по умолчанию конвейера и для каждой защищённой ветви репозитория. Ветвь с настроенными политиками для ветви считается защищенной ветвью.

  В качестве примера рассмотрим репозиторий с двумя ветвями main и release. Представьте, что pipeline's default branch — это main ветвь, а у release ветви есть политика ветвления, что делает её защищённой ветвью. В этом случае, если вы настроили политику на сохранение трех запусков, сохраняются последние три запуска main и последние три запуска ветви release. Кроме того, сохраняются последние три запуска этого конвейера (независимо от ветви).

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

  Забег #	Ветвь	Сохранено / не сохранено	Почему?
  Запуск 10	главный	Сохранено	Последние 3 для основного и последние 3 для конвейера
  Запуск 9	филиал 1	Сохранено	Последние 3 для конвейерной системы
  Запуск 8	ветка2	Сохранено	Последние 3 для конвейера
  Запуск 7	главный	Сохранено	Последние 3 для основного раздела
  Запуск 6	главный	Сохранено	Последние 3 для главного раздела
  Пробег 5	главный	Не сохранено	Ни последние 3 для основного процесса, ни для канала обработки
  Бег 4	основной	Не сохранено	Ни последние 3 для основного, ни для конвейера
  Run 3	Филиал1	Не сохранено	Ни последние 3 для основного, ни для конвейера
  Бег 2	выпуск	Сохранено	Последняя версия 3 для выпуска
  Запуск 1	главный	Не сохранено	Ни последние 3 для основного, ни для конвейера

• Все остальные репозитории Git: Azure Pipelines сохраняет настроенное количество последних запусков для всего конвейера.

• TFVC: Azure Pipelines сохраняет настроенное количество последних запусков для всего конвейера независимо от ветви.

Какие части запуска удаляются

При удалении запуска следующие сведения удаляются:

• Логи
• Все артефакты конвейера и сборки
• Все символы
• Двоичные файлы
• Результаты теста
• Запуск метаданных
• Исходные метки (TFVC) или теги (Git)

Универсальные пакеты, NuGet, npm и другие пакеты не привязаны к политике хранения конвейеров.

Когда выполняется удаление результатов?

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

Прогон удаляется, если выполняются все следующие условия:

• Оно превышает количество дней, настроенных в параметрах хранения.
• Это не один из последних запусков, настроенных в параметрах хранения.
• Оно не отмечено для сохранения на неопределённое время
• Он не сохраняется в версии выпуска.

Автоматическая установка срока хранения при выполнении конвейерных процессов

Аренды хранения используются для управления временем существования конвейера за пределами настроенных периодов хранения. Договора хранения можно добавлять или удалять при запуске конвейерного процесса через вызов 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

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

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

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

Использование задачи копирования файлов для сохранения данных дольше

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

YAML

- task: CopyFiles@2
  displayName: 'Copy Files to: \\mypath\storage\$(Build.BuildNumber)'
  inputs:
    SourceFolder: '$(Build.SourcesDirectory)'
    Contents: '_buildOutput/**'
    TargetFolder: '\\mypath\storage\$(Build.BuildNumber)'

Классическое

1. Добавьте задачу копирования файлов в ваш конвейер.

2. Настройте задачу копирования файлов.

Вопросы и ответы

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

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

Как указать, что запуски, развернутые в производственной среде, будут храниться дольше?

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

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

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

Это может быть по одной из следующих причин:

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

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

Как работает настройка "минимальное количество выпусков для сохранения"?

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

Как определяется период хранения при развертывании выпуска на нескольких этапах с разными периодами хранения?

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

Я удалил этап, для которого у меня имелись некоторые старые релизы. Какое сохранение будет рассматриваться в этом случае?

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

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

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

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

Я потерял некоторые результаты. Есть ли способ их вернуть?

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

Как я могу использовать Build.Cleanup возможности агентов?

Build.Cleanup Установка возможности для агентов приведет к тому, что задания очистки пула будут направляться только этим агентам, оставляя остальных свободными для обычной работы. При удалении запуска конвейера артефакты, хранящиеся за пределами Azure DevOps, очищаются посредством выполнения задания агентами. Когда пул агентов насыщается заданиями по очистке, это может вызвать проблемы. Решением этого является назначение подмножества агентов в пуле, которые являются агентами очистки. Если для каких-либо агентов установлено значение Build.Cleanup, только эти агенты будут выполнять задания очистки, оставляя остальных агентов свободными для продолжения выполнения заданий конвейера. Функциональность очистки можно включить, перейдя к Агент>Возможности и установив Build.Cleanup равным 1.

Что происходит с артефактами общей папки при удалении сборки

При удалении сборки с общими артефактами файловой папки новая задача сборки помещается в очередь агента сборки для очистки этих файлов. Агент выбирается для выполнения этой задачи на основе следующих критериев: доступен ли агент с Build.Cleanup возможностью? Доступен ли агент, выполняющий сборку? Доступен ли агент из одного пула? Доступен ли агент из аналогичного пула? Доступен ли любой агент?

Сохраняются ли результаты автоматических тестов, опубликованных в рамках релиза, до его удаления?

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

Удалены ли результаты теста вручную?

№ Результаты теста вручную не удаляются.

Как сохранить метки или теги системы управления версиями?

Внимание

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

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

Что происходит с конвейерами, которые используются в других конвейерах?

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

Связанные статьи

• Управление длительностью хранения результатов теста
• Удаление артефактов теста
• Использование задач для сохранения запусков в Azure Pipelines