Правила хранения артефактов GitLab, чтобы снизить затраты на хранилище

Что идёт не так, когда артефакты никогда не истекают

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

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

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

Это напрямую бьёт по бюджету. Больше хранения — выше затраты GitLab, и большая часть этих денег ничего не покупает полезного. Команды редко скачивают артефакты из устаревших feature-веток, старых попыток исправлений или провалившихся экспериментов трёхмесячной давности.

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

Большая часть загромождения происходит из повторяющихся артефактов в активных feature-ветках, старых пайплайнов merge request, выходных данных упавших задач, которые хранятся долго после исправления, и файлов кандидатных релизов, которые никто не продвинул. Результат — не только большая счёт-фактура. Команды тратят время, угадывая, какой артефакт ещё важен, а очистка превращается в ручную рутину, которую никто не хочет делать.

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

Какие артефакты стоит сохранять, а какие удалять

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

Короткоживущие тестовые результаты должны быстро истекать. Сюда входят временные логи сборки, превью-бандлы, отчёты тестов для feature-веток и файлы, созданные только для продвижения одного merge request. Как только ревью заканчивается или ветка закрывается, этим файлам обычно нет причин оставаться.

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

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

Большинству команд не нужна сложная система классификации. Четырёх меток обычно достаточно: review-only, branch build, release и audit/rollback. С такими метками решения по хранению перестают быть эмоциональными. Разработчик может взглянуть на артефакт и понять, зачем он нужен, как долго жить и кто по нему будет скучать.

Один пример делает это понятнее. Feature-ветка создаёт тестовый бандл, скриншоты и отчёт покрытия для одного merge request. Эти файлы помогают ревьюерам сегодня, но почти никогда — через месяц. Тегированный релиз создаёт установочный пакет и заметки к релизу, связанные с развёртыванием клиента. Этот набор стоит сохранить, потому что команда может понадобиться сравнить версии или откатиться.

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

Сортируйте ветки и релизы по простым группам

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

Хорошая отправная точка — четыре группы: feature-ветки, main, release-ветки и помеченные релизы. Хотфиксы можно вписать в ту же модель с одним дополнительным правилом вместо настройки для каждого срочного патча.

Используйте четыре корзины, а не двадцать

Feature-ветки принадлежат к корзине короткого хранения. Эти сборки помогают при ревью и тестировании, но быстро теряют ценность после слияния или заброса ветки. Для многих команд 3–7 дней достаточно.

Сборки ветки main заслуживают более длинного окна. Люди часто возвращаются к ним, чтобы сравнить поведение, протестировать откат или проверить недавний пакет. Хранение 14–30 дней обычно достаточно.

Release-ветки отличаются от помеченных релизов, и команды часто путают их. Release-ветка всё ещё меняется. Вы можете её патчить, пересобирать или тестировать несколько раз перед финальной датой отправки. Это делает её ближе к текущей работе, чем к постоянной записи.

Помеченные релизы — это сборки, которые могут понадобиться через месяцы. Они соответствуют отправленной версии, поэтому их следует хранить намного дольше, чем сборки release-веток. Некоторые команды держат их 6–12 месяцев. Другие хранят только несколько последних помеченных релизов, если публикуют часто.

Пусть правила по хотфиксам будут скучными

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

Простое правило работает: храните артефакты хотфикс-веток столько же, сколько и для release-веток, а помеченные хотфикс-релизы — как другие помеченные релизы. Это даёт достаточно времени для проверки исправления, сравнения файлов и отката при необходимости.

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

Задавайте окна истечения по шагам

Начните с простого инвентаря. Запишите типы веток, которые реально использует ваша команда, а не те, которые вы думаете, что используете. Большинству команд нужен короткий список: feature- и bugfix-ветки, main, release-ветки и помеченные релизы.

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

Вам не нужно ничего сложного, чтобы принять начальные окна. Для многих команд подходящая стартовая конфигурация выглядит так:

• Feature и bugfix-ветки: 3–7 дней
• Main: 14–30 дней
• Release-ветки: 30–90 дней
• Помеченные релизы: 6–12 месяцев

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

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

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

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

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

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

Простой пример политики для одной команды

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

Для ежедневной работы они сортируют ветки по тому, как долго сборка будет полезна. Большинство feature-веток живёт всего несколько дней, затем MR закрывается и никто больше не трогает артефакты. Поэтому команда хранит эти файлы 5 дней и продлевает до 7, только когда ревью действительно длинные.

Их политика проста:

• Feature-ветки: 3–7 дней
• Main: 14–30 дней
• Release-ветки: хранить артефакты до отправки релиза
• Помеченные production-релизы: хранить месяцами или дольше, если требует соответствие
• Хотфикс-сборки: применяйте то же правило, что и к помеченным production-релизам

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

Release-ветки живут до отправки релиза. В этот период QA может перезапускать тесты, продукт просит последний прогон, и разработчики могут понадобиться точную ту же сборку ещё раз. Удалять такие артефакты слишком рано — это лишняя работа и замедление релиза.

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

Эта политика намеренно скучная. Она сокращает мусор, не усложняя отладку. Если команда реже выпускает релизы — держите main ближе к 30 дням. Если команда быстро сливает и часто мержит — держите feature-артефакты ближе к 3 дням.

Ошибки, которые тратят место зря

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

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

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

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

Где команды путаются

Доказательства релиза требуют другого правила, чем временные review-артефакты. Подписанные пакеты, записи для соответствия и файлы, связанные с отправленной версией, могут требовать более длительной жизни. Превью-сборки для QA, скриншоты MR и временные отладочные бандлы обычно нет.

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

Короткая проверка здравомыслия поможет. Держите артефакты веток на коротких таймерах, ограничьте повторные прогонки, которые сохраняют те же выходы, сохраняйте тяжёлые тестовые бандлы только когда кто-то их реально проверит, отделяйте релизные артефакты от review и debug-файлов и предупреждайте разработчиков и QA до изменения правил. Звучит просто, но это экономит реальные деньги.

Быстрые проверки перед включением правил

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

Начните с релизов. Возьмите недавнюю production-версию и спросите: если она упадёт сегодня ночью, можно ли переотправить её без пересборки из исходников? Некоторые команды хранят только теги исходников и считают, что всё пересоберут заново. Это работает до тех пор, пока не изменится зависимость, не исчезнет пакет или среда сборки не перестанет совпадать. Если откат зависит от сохранённых артефактов, держите релизные артефакты дольше, чем веточные.

Аудиты требуют той же реальной проверки. Инженерия может быть довольна 14 или 30 днями, но финансы, безопасность или клиентский контракт могут требовать доказательств релиза гораздо дольше. Подтвердите это с владельцем соответствия. Догадки — путь к восстановлению старых резервных копий только ради ответа на простой вопрос.

Теперь смотрите на размер, а не только на возраст. В большинстве проектов GitLab несколько задач создают основную часть счёта хранения. Сборки пакетов с большими бинарниками, UI-тесты с видео и скриншотами, сканы с полными архивами отчётов и неудачные отладочные задачи, которые архивируют рабочие пространства, — обычно главные виновники.

Эти тяжёлые задачи заслуживают отдельного внимания до применения новых правил. Артефакт 2 ГБ, хранящийся 7 дней, — совсем другая история, чем отчёт 30 МБ, хранящийся 30 дней.

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

Наконец, спросите разработчиков, как далеко назад они реально идут при расследовании бага. Многие команды нуждаются только в недавних веточных сборках неделю–две, тогда как кандидатные релизы и теги production хранятся дольше. Если люди всё ещё отлаживают проблемы по сборкам main за прошлый месяц — держите это окно. Если нет — не платите за хранение.