Личный опыт: как выглядит наша система Continuous Integration
Мы в Positive Technologies не только проводим исследования безопасности различных ИТ-систем, но и разрабатываем продукты, которые помогают обнаруживать и предотвращать угрозы, а также минимизировать ущерб от возможных атак. За последние несколько лет линейка наших продуктов серьезно расширилась — к известной многим на рынке системе MaxPatrol добавился целый ряд новых инструментов от межсетевых экранов уровня приложений до инструментов управления инцидентами. Такой развитие поставило нас перед необходимостью адаптации процессов разработки в компании — поэтому мы активно внедряем в свою работу практики DevOps и связанные с этим технологии.
Сегодня мы хотим рассказать вам о модели созданной нами системы Continuous Integration.
Предыстория
Много лет назад мы выбрали в качестве системы Continuous Integration для автоматизации сборки и тестирования кода инструмент TFS. С течением времени нам стало очевидно, что у этой системы есть целый ряд недостатков. В частности, при ее использовании:
- Трудно поддерживать шаблоны сборочных, деплойных и тестовых конфигураций.
- Возникают проблемы с интеграцией не C#-проектов.
- Невозможно оперативное расширение инфраструктуры.
Чем дольше мы ее использовали, тем острее становилась потребность в типизации и шаблонизации создания всех типов конфигураций, ускорения создания типовых проектов в наших системах Continuous Integration и обеспечения расширяемости проектов с упрощением добавления новых конфигураций.
На решение этих задач у нас ушло почти два года. Вот, как сейчас выглядит инфраструктура Continuous Integration в Positive Technologies. Она состоит из связки трех базовых сервисов:
- TeamCity — основная система организации Continuous Integration.
- GitLab — система хранения исходного кода.
- Artifactory — система хранения собранных бинарных версий компонент и продуктов.
Отдельное внимание мы уделили разработке типовых проектов для системы непрерывной интеграции. Это позволило нам добиться унификации проектов, выделив так называемую релизную схему сборок с продвижениями в TeamCity.
Вот как это работает. Все проекты выглядят одинаково: они включают конфигурацию сборок, которые попадают в артифакторий, после чего осуществляется их развертывание, тестирование и продвижение в релизный репозиторий проекта.
В итоге все проекты имеют стандартную трехуровневую организацию. Первый уровень — это уровень проекта, например, в TeamCity на этом уровне хранятся всевозможные сборочные шаблоны, следом идет уровень подпроекта, включающий различные компоненты общего продукта, а каждый подпроект включает в себя стандартные группы конфигураций для сборки, деплоя, тестирования и инструментов.
Как результат — сейчас у всех проектов в нашем TeamCity одинаковая иерархия, что очень удобно. Подробнее об этом можно почитать здесь.
Что в итоге
Мы занимаемся развитием системы Continuous Integration уже почти два года, и в настоящий момент она выглядит следующим образом. Помимо стандартных групп конфигураций для сборки, деплоя, тестирования и продвижения сборок, сейчас у нас добавилась система публикации протестированных релизных сборок на Global Update-сервера, откуда они распространяются дальше вплоть до инфраструктуры заказчика.
Верхнеуровневая IDEF0-модель процессов Continuous Integration в компании Positive Technologies на 2016 год. По клику картинка откроется в полном размере
Кроме того, мы используем и ряд других технологий, среди которых Docker, SaltStack, TeamCity, Teampass, TestRail, VMware, Zabbix и другие.
Однако, несмотря на все плюсы унификации, созданная нами на первом этапе система имела и свои недостатки.
Не все так просто
Прежде всего, логика конфигураций в TeamCity оказалось довольно сложной, что затрудняло работу. Поддержка этих конфигураций осуществлялась только силами DevOps-команды компании, и уже очень скоро мы достигли пределов масштабирования проектов при работе в таком формате. Однако частично эта проблема была решена с помощью создания скриптов для автоматической генерации типовых проектов.
Также у нас отсутствовали механизмы доставки и инсталляции продуктов, интегрированные с нашей системой Continuous Integration. Неудобства доставлял и тот факт, что процессы сборки собственно на сборочных серверах и машинах разработчиков отличались —, а обеспечить их «одинаковость» нам было не под силу.
Стало понятно, что нужно двигаться дальше и развивать нашу систему.
Планы
Мы планируем создать на базе TeamCity два сборочных пула машин под Windows и Linux. Предполагается и дальнейшее развитие системы оптимизации сборочных процессов под названием CrossBuilder. С ее помощью можно будет решать целый ряд задач:
- Обеспечить идентичные сборочные процессы на серверах сборки и машинах разработчиков.
- Возможность использования различных CI-систем.
- Декларативное описание процесса сборки с помощью специальных файлов-манифестов делегируется в команды разработки, освобождая время сотрудников DevOps.
Решение этих задач позволит нам еще больше повысить эффективность работы нашей системы Continuous Integration.
На сегодня все, спасибо за внимание! В комментариях мы будем рады услышать замечания по поводу выбранных нами решений, делитесь своим опытом построения систем Continuous Integration!
P. S. Рассказ о нашей системе Continuous Integration был представлен в рамках DevOps-митапа, который состоялся недавно в Москве.
По ссылке представлены презентации 16 докладов, представленных в ходе мероприятия. Все презентации и видео выступлений будут добавлены в таблицу в конце этого топика-анонса.
Автор: Тимур Гильмуллин
