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

Автор: Тимур Гильмуллин