Компания
412,88
рейтинг
26 октября 2016 в 10:01

Администрирование → Личный опыт: как выглядит наша система Continuous Integration

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

Автор: Тимур Гильмуллин
Автор: @ptsecurity
Positive Technologies
рейтинг 412,88

Комментарии (6)

  • 0
    Расскажите пожалуйста:
    — Какие зависимости у вас необходимы чтобы протестировать одно собранное решение? ( один, сервер, группа серверов)
    — Если несколько серверов, то как вы их получаете\управляете? Vmware только для получения VM руками?
    — Для чего именно у вас используется Docker?
    • 0
      1. Под каждый проект (комплексный процесс, включающий в себя сборку инсталлятора и компонент для него, деплой их на тестовые сервера и автоматизированное тестирование):

      • в TeamCity выделяется пул сборочных серверов (обычно 1-4 машины на проект), за поддержку которых отвечает DevOps. На этих машинах запускаются только сборочные конфигурации, шаги которых компилируют исходный код (хранимый в GitLab), получают артефакт (одну версию собранной компоненты или всего инсталлятора) и выкладывают его в Artifactory для хранения.
      • в TeamCity выделяется пул деплойных серверов (также 1-4 машины на проект). В этом пуле запускаются только деплойные конфигурации, которые отвечают за доставку артефактов сборки на сервера тестирования. За деплойные конфигурации и пулы отвечать может как команда DevOps, так и QA.
      • в TeamCity выделяется пул серверов для тестирования (сколько угодно, в зависимости от требований команды QA), за которые отвечает команда QA. В этом пуле запускаются конфигурации, которые выполняют автоматические функциональные тесты на собранные компоненты или инсталляторы. По результатам тестов артефакты компонент или инсталляторов могут быть «продвинуты» (скопированы) в специальные репозитории на Artifactory для хранения протестированных сборок. Иногда деплойные и тестовые сервера могут быть в одном пуле (для небольших проектов).

      2. Для управления виртуальными машинами (включение, выключение, откаты ВМ на снапшоты, запуск процессов и прочее) мы используем vSphereTools. Про автоматическое управление виртуальными машинами будет рассказано в 6-й статье нашего цикла «vSphereTools — инструмент для автоматизации работы с vSphere». Предварительно презентацию с доклада по этому инструменту можно посмотреть здесь: www.slideshare.net/phdays/vspheretools-vsphere

      3. Docker используется в нашей инфраструктуре для различных целей:

      • для подготовки контейнеров со сборочным, деплойным и тестовым окружением для проектов,
      • сервисы, которые мы предоставляем как отдел DevOps (TeamCity, Artifactory, GitLab, Youtrack, UpSource, Zabbix и все остальные) для всех команд.
  • 0
    Интересно было бы узнать сколько у вас людей в DevOps-команде и участвует ли ИТ-отдел в этой деятельности?
    Девопс-команда из программистов набиралась, qa, админов или извне?
    Спасибо
    • +1
      Сейчас наша команда DevOps – это выделенный отдел в компании. Разумеется, мы тесно сотрудничаем с коллегами из ИТ-отдела: они помогают нам решать сетевые и инфраструктурные вопросы, и вопросы связанные с бекапами. Все наши сервисы расположены на машинах, «живущих» в облаке, предоставляемом ИТ-отделом.

      Команда у нас смешанная, с крайне размытой специализацией (но она всё же есть), коротко: есть QA + Dev + IT. Есть у нас сотрудники с большим опытом работы с трекинговыми системами, есть сотрудники, которые в основном занимаются разработкой типовых сборочных конфигураций, есть сотрудники поддерживающие сервисы мониторинга, есть разработчики внутренних инструментов и прочие.
      • 0

        Всё-таки можете сообщить количество? Или хотя бы процентное отношение к количеству Dev+QA непосредственно разрабатывающих продукт

        • 0
          Это довольно сложный вопрос. Сейчас нас больше десяти человек, самих продуктов – с десяток, людей, над ними работающих – пара сотен. Значит «девопсеров» 3-5% от продуктовой разработки.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Администрирование