Особистий досвід: як виглядає наша система 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 доповідей, представлених в ході заходу. Всі презентації та відео виступів будуть додані в таблицю в кінці цього топіка-анонсу.

Автор: Тимур Гильмуллин
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.