Мы продолжаем рассказывать о том, как внедряем практики и подходы 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 докладов, представленных в ходе мероприятия. Все презентации и видео выступлений добавлены в таблицу в конце этого топика-анонса.

Автор: Алексей Соловьев