Мы продолжаем рассказывать о том, как внедряем практики и подходы DevOps. Например, недавно писали о создании собственного инструмента для проведения конкурентного анализа программных продуктов. Сегодня речь пойдет о том, как мы интегрировали систему TeamCity с внешним сервером отладочных символов.
Зачем это нужно
Отладочные символы — это информация, которую компилятор генерирует автоматически на основе исходных кодов. Такие символы могут быть включены в состав бинарного файла, представлены в виде отдельного файла или вообще отброшены на этапе компиляции — это позволяет уменьшить размер бинарного файла и увеличить сложность его обратной разработки.
Такие символы решают несколько задач:
- они содержат отладочную информацию о бинарном файле (имена переменных, функций и т.п.)
- с их помощью легче искать ошибки в коде;
- отладочные символы необходимы при поиске багов и разборе дампов.
Польза отладочных символов понятна, теперь поговорим о том, почему мы не стали использовать встроенный в TeamCity сервер символов и пришли к другому решению.
Что не так с сервером символов TeamCity
Наше решение использовать внешний сервер символов было продиктовано недостатками встроенного в TeamCity решения:
- На момент, когда мы думали над тем, как именно работать с отладочными символами, встроенное решение TeamCity не умело взаимодействовать с бинарными файлами — позднее эта функция появилась, но мы уже приняли решение использовать внешний сервер.
- Также там не было отлаженного механизма хранения символов.
- В существовавшей у нас на тот момент конфигурации на сервере символов не было большого объёма дисковых ресурсов, нам просто не хватало места.
- Наша компания занимается разработкой многокомпонентных продуктов, и хранить символы с привязкой к версии компонент для них было трудно.
Решение
Вот как мы решаем описанные проблемы сейчас:
- используем виртуальный сервер с OS Windows Server;
- основной рабочий инструмент — входящий в пакет Windows SDK Symstore.exe, который используется для выкладывания символов на сервер;
- также мы написали отдельный метараннер для TeamCity.
У нас в компании реализована так называемая «релизная схема с продвижениями сборок», при которой протестированные артефакты сборок отдельных компонент перемещаются из «мусорного» .snapshot-репозитория в релизный — оттуда они в дальнейшем берутся для сборки релизных инсталляторов продуктов. Мы выкладываем символы релизных и фича-сборок на разные shared-серверы. Поэтому необходимо уметь отличать релизные сборки. Когда мы собираем обычную сборку, то бинарные файлы поступают в артифакторий, как и отладочные символы. При запуске продвижения сборки отдельной компоненты через специальную конфигурацию-промоутер, разработанный нами метараннер загружает символы в релизную папку на сервере символов.
Подробнее этот процесс выглядит так: когда происходит сборка, то мы смотрим на то, имеет ли он статус promote. Если мы имеем дело с такой сборкой, то символы помещаются в релизную расшаренную папку на сервере. Если же это обычная фича-сборка, то символы помещаются и в артифакторий, и в общую «разработческую» папку на сервере символов.
Что в итоге
В итоге на нашем сервере символов сейчас расположено два каталога:
- Release Symbols — в нем лежать символы релизных сборок, которые нужно хранить долго;
- Symbols — для символов девелоперских сборок.
Нам удалось решить проблему с нехваткой места на диске — каталог с девелоперскими символами очищается скриптом, который запускается планировщиком. Он удаляет все файлы, старше N дней, из определенного каталога дерева символов, а также файлы, отвечающие некоторому условию — например, все сборки одной версии, кроме самой последней.
Наш метараннер для TeamCity умеет работать со всеми бинарными файлами и встроен в процессы сборки многокомпонентных продуктов.
P. S. Рассказ о нашем опыте TeamCity и сервера символов был представлен в рамках DevOps-митапа, который состоялся осенью 2016 года в Москве.
Видео:
Слайды:
По ссылке представлены презентации 16 докладов, представленных в ходе мероприятия. Все презентации и видео выступлений добавлены в таблицу в конце этого топика-анонса.
Автор: Алексей Соловьев
