Автоматизация процессов разработки: как мы в Positive Technologies внедряли идеи DevOps



    Привет, хабр! В этой статье расскажу, как мы в Positive Technologies создавали и развивали отдел автоматизации разработки, внедряли идеи DevOps в практику разработки и какие инструменты и технологии для этого использовали, а также как организовали процессы CI/CD. В том числе поделюсь успехами и планами на будущее.

    Кто мы и что мы делаем


    Positive Technologies ― мультипродуктовый вендор в области информационной безопасности. Продукты Positive Technologies поставляются по традиционным моделям (в виде устанавливаемого ПО), SaaS, виртуальных машин и «bare metal appliance». Наш отдел, неформально называемый у нас отделом DevOps, занимается автоматизацией и поддержкой процессов разработки всех наших продуктов: сетевого сканера ИБ XSpider, системы контроля защищенности и соответствия стандартам MaxPatrol 8, решения для управления событиями, активами и инцидентами ИБ MaxPatrol SIEM, системы управления инцидентами кибербезопасности АСУ ТП ― PT ISIM, защитного экрана уровня приложений PT Application Firewall, анализатора кода PT Application Inspector, многопоточной системы выявления вредоносного контента PT MultiScanner и всех остальных продуктов компании.

    Мы считаем, что работа по принципам DevOps и обязанности соответствующих отделов автоматизации сильно зависят от специфики работы конкретной компании. Специфика работы нашей компании накладывает на нас обязанность по организации поставки конечным заказчикам коробочного продукта и поддержку нескольких версий каждого продукта одновременно.

    На данный момент наш отдел отвечает за весь конвейер по серийному производству продуктов компании и сопутствующую инфраструктуру, начиная от сборки отдельных компонент продуктов и интеграционных сборок, до их отправки на тестирование на наших серверах и доставку обновлений на географически распределенную инфраструктуру серверов обновлений и затем ― на инфраструктуру заказчиков. Несмотря на большой объем задач, с ними справляется всего 16 человек (10 человек решает задачи Continuous Integration и 6 — задачи Continuous Delivery), при этом количество людей, участвующих в разработке продуктов, более 400.

    Ключевым принципом для нас является «DevOps as a Service». DevOps в современном IT уже давно выделился в самостоятельную инженерную дисциплину — очень динамичную и технологичную. И мы должны оперативно приносить эти технологии нашим разработчикам и тестировщикам. Кроме того, мы делаем их работу более комфортной, эффективной и продуктивной. Также мы разрабатываем внутренние вспомогательные инструменты, регламентируем и автоматизируем процессы разработки, сохраняем и распространяем технологические знания внутри компании, проводим технические воркшопы и делаем еще много всего полезного.

    О наших первых шагах в развитии идей DevOps у нас в компании можно почитать в статье «Миссия выполнима: как развить DevOps в компании со множеством проектов».

    Модель Continuous Integration и Continuous Delivery


    Когда мы в Positive Technologies решили развивать идеи DevOps, то столкнулись с необходимостью их внедрения в ситуации, при которых десятки команд одновременно работали над проектами как публичными, так и непубличными. Они сильно отличались по размеру, использовали различные релизные модели и технологический стек. К нам пришло понимание того, что централизованные решения и высокий уровень организации автоматизации разработки — это лучше, чем «творческий хаос» обычной разработки. Кроме того, любая автоматизация призвана сокращать себестоимость процесса разработки и внедрения продуктов. В компаниях, где есть выделенная служба для реализации методик DevOps, обеспечивается серийность всех внедряемых инструментов, благодаря чему разработчики могут более эффективно работать, используя готовые шаблоны автоматизации.

    Continuous Integration ― это лишь один из процессов, соединяющих разработчиков и конечных пользователей продуктов. Инфраструктура Continuous Integration в Positive Technologies развивалась вокруг связки из трех базовых сервисов:

    • TeamCity — основная система организации Continuous Integration;
    • GitLab — система хранения исходного кода;
    • Artifactory — система хранения собранных бинарных версий компонент и продуктов.

    Исторически сложилось так, что для хранения кода, организации сборок и хранения их артефактов мы выбрали GitLab, TeamCity, Artifactory. GitLab мы начали использовать очень давно из-за его удобства по сравнению с svn, который у нас был раньше. Преимущества GitLab были в том, что в нем стало проще применять изменения (merge). Что касается Artifactory, то ему нет серьезной альтернативы для хранения бинарей (компонент и инсталляторов). Впрочем, можно использовать файловые шары или MS SharePoint, но это, скорее, для тех, кто не ищет легких путей, а не для автоматизаторов. На TeamCity мы перешли после долгого периода эксплуатации и сборок на MS TFS. Переезд долго тестировался, обкатывался на небольших продуктах, и лишь затем его провели полностью. Основная причина — необходимость в простых типовых решениях и масштабируемости сборочной и тестовой инфраструктуры для многокомпонентных продуктов, написанных на различных языках программирования. TFS этого нам дать не мог.

    Отдельное внимание мы уделили разработке типовых проектов для системы непрерывной интеграции. Это позволило нам добиться унификации проектов, выделив так называемую релизную схему сборок с продвижениями в TeamCity. Все проекты при этом выглядят одинаково: они включают в себя конфигурации для сборок, артефакты которых попадают в Artifactory, оттуда их можно взять для развертывания, тестирования и продвижения в релизный репозиторий проекта (см. схему на рисунке 1). Подробнее об используемой терминологии и организации типового CI-процесса мы написали в статье «DevOps best practices: рекомендации по организации конфигураций в TeamCity».



    Рисунок 1. Базовые элементы типового проекта для релизной схемы сборок с продвижениями (по клику откроется в полном размере)

    Мы развивали нашу систему Continuous Integration более двух лет, и к настоящему моменту, помимо стандартных конфигураций для сборки, деплоя, тестирования и продвижения сборок, мы дополнили ее разработанной нами системой Continuous Delivery, названной SupplyLab, для публикации протестированных релизных сборок на Global Update-серверы, откуда они забираются и распространяются через Front Update-серверы дальше, вплоть до инфраструктуры заказчиков, на которой разворачиваются и обновляются.

    Как было отмечено выше, все решения, предоставляемые нашей DevOps-командой, — типовые, масштабируемые и построенные на шаблонах. Несмотря на то, что пожелания к инфраструктуре, языки программирования и алгоритмы сборки, используемые командами, различаются, общая концепция CI/CD процесса остается неизменной (см. схему на рисунке 2):

    коммит в git — автоматическая сборка — деплой на тестовые серверы — функциональное и прочие виды автотестирования — продвижение сборки в стабильные — публикация на GUS — распространение через FUS на инфраструктуре заказчика — установка или обновление продукта на конкретных серверах.

    На каждом из этих этапов DevOps-отдел помогает разработчикам решать конкретные задачи:

    • обеспечить хранение кода в системе GitLab (выделить им проект);
    • разработать сборочную конфигурацию на базе одного из типовых шаблонов и обеспечить хранение собранных артефактов в системе Artifactory;
    • реализовать конфигурации для деплоя артефактов на серверах тестировщиков и помочь им с реализацией тестовых конфигураций;
    • в случае успешного тестирования — «продвинуть сборку» — то есть, переместить ее в хранилище протестированных артефактов в Artifactory, для чего также создается специальная конфигурация;
    • далее сборка может быть опубликована на Global Update сервере компании, откуда автоматически будет распространена на FUS-серверы у заказчиков;
    • при помощи скриптов инсталляции, реализованных на базе SaltStack, сборка развернется на конкретном сервере.

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



    Рисунок 2. Верхнеуровневая IDEF0-модель процессов Continuous Integration и Continuous Delivery в компании Positive Technologies

    Подробнее о том, как мы строили и развивали нашу систему CI/CD в начале 2017 года, — в статье «Личный опыт: как выглядит наша система Continuous Integration».

    Немного о мониторинге


    В нашей команде выделены ответственные за направление работ, связанное с мониторингом: от заявки на подключение сервера или сервиса на мониторинг, до конечного красивого дашборда системы управления (графики, метрики, система оповещения), предоставляемого в команды. Функциональные обязанности этой группы: настройка и предоставление службы мониторинга как сервиса, предоставление типовых шаблонов для мониторинга серверов и служб различных типов, проектирование иерархической системы мониторинга, прогнозирование нехватки ресурсов.

    Мы используем систему мониторинга Zabbix. Для упрощения постановки служб на мониторинг, мы решили разграничить зоны ответственности между командой DevOps, разработчиками и тестировщиками, а также написали собственные инструменты для взаимодействия с Zabbix (zabbixtools) и используем подход «monitoring as code». Поясним на примере: так, если у нас есть тестовый стенд, который нужно мониторить, то тестировщик назначает ему определенную роль. У каждого хоста — только одна роль, в которой может быть несколько профилей для мониторинга процессов, служб, API и другие — их предоставляет команда DevOps (см. отношения между сущностями Zabbix на рисунке 3).



    Рисунок 3. Модель отношений между сущностями в Zabbix

    Для упрощения конфигурирования реализована система, при которой Zabbix забирает с целевого сервера как можно больше данных о наблюдаемых показателях. Для этого в zabbixtools используется функциональность Low Level Discovery (LLD). Это позволяет вносить любые настройки мониторинга на самом отслеживаемом сервере, а не в админке Zabbix. Файлы настроек сохраняются и обновляются при этом через git.

    Про внедрение системы мониторинга можно почитать в статье «Zabbix для DevOps: как мы внедряли систему мониторинга в процессы разработки и тестирования».

    Недостатки в функциональности используемых нами решений для CI/CD


    Все обнаруженные проблемы и недостатки элементов наших CI/CD-систем мы фиксируем в нашей базе знаний DevOps. Обобщить проблемы каждого конкретного сервиса в пределах одной статьи довольно сложно, поэтому отмечу только наиболее показательные, например, для CI-системы TeamCity.

    На данный момент все сборочные конфигурации в TeamCity сопровождаются только силами нашего отдела. Мы вносим изменения в них по заявке от разработчиков, чтобы избежать проблем с поломкой ими конфигураций из-за незнания наших шаблонов и инструментов. Также наша команда следит за окружением на сборочных серверах — агентах TeamCity. У разработчиков к ним нет доступа. Мы ограничили его для того, чтобы избежать внесения несанкционированных изменений на серверах и для упрощения локализации возможных проблем и отладки сборок: раз есть гарантия, что конфигурации и окружение не меняются самовольно, значит проблема может быть либо в коде, либо сетевая. Получается, что мы не можем предоставить разработчикам возможность самостоятельно отлаживать на TeamCity сборочный процесс и настраивать окружение на сборочном агенте.

    Таким образом, первая проблема заключается в том, что нам не хватает возможности делегирования сборочного процесса в команды, используя подход «build as a code». У TeamCity нет простого для использования DSL (специфического языка описания сборки). Хотелось бы, чтобы код описания сборки хранился в репозитории рядом с кодом продукта, как, например, в Travis CI. Сейчас эту проблему мы решаем путем разработки своей системы сборки — CrossBuilder. Планируется, что она предоставит разработчикам возможность давать простое описание сборки, хранить и изменять его в своем проекте, а также не будет зависеть от используемой CI-системы, реализуя сборку через систему плагинов. Кроме того, эта система позволит запускать сборки локально, через standalone-клиент.

    Вторую проблему с внесением изменений в сборочные окружения, как и многие другие инженеры, мы решили для Linux с переходом на docker-образы, за подготовку которых, в том числе хранение dockerfiles, команды отвечают самостоятельно. Это позволило выделить нам пул однотипных сборочных Linux-серверов, на каждом из которых может запуститься сборка любой команды в собственном окружении. Для Windows аналогичную схему мы только начинаем прорабатывать и сейчас проводим эксперименты.

    Наш инструментарий


    Мы перепробовали множество различных сервисов и инструментов и со временем эволюционным путем сложился их определенный набор. Для решения задач нашего отдела мы используем: TeamCity и GitLab CI как CI-системы, GitLab для хранения кода, Artifactory как хранилище бинарных артефактов и проксирующий репозиторий, SaltStack для автоматизации сценариев развертывания окружений, Docker для изолированного сборочного окружения, SonarQube для анализа качества кода, UpSource для проведения командного код-ревью, TeamPass для безопасного хранения секретов, VMware как средство виртуализации, Zabbix для мониторинга всей нашей инфраструктуры, TestRail для хранения результатов тестранов, Kubernetes для управления контейнерами Linux и некоторые другие.

    Из почтовых клиентов по корпоративному стандарту мы используем Outlook/OWA и Skype for Business, во всем остальном мы не ограничены регламентами, поэтому все используют то, что им удобно: браузеры Chrome, Thunderbird (Mozilla), Opera; файловые менеджеры Total Commander, FAR, ConEmu и обычный shell; редакторы MS Word, Notepad++ и, конечно, vim; ssh-клиенты Putty, WinSCP; снифферы и анализаторы трафика (tcpdump, windump, wireshark, burpsuite etc); из IDE любим PyCharm, Visual Studio, WebStorm; для целей виртуализации используем vSphere Client и VirtualBox.

    Следуя за разработчиками нашей компании нам приходится автоматизировать процессы в основном под Linux (Debian, Ubuntu) и Windows (2003-2016). Соответственно, языковая экспертиза у нас такая же, как и у разработчиков, — это Python, C#, batch/bash. Для разработки типовых модулей, например, скриптов-метараннеров для TeamCity, у нас предусмотрен регламент, который четко описывает все шаги разработки: начиная от именования скриптов, методов, код-стиля и заканчивая правилами подготовки юнит-тестов на новый модуль и функционального тестирования всей сборки devops-tools (наши внутренние скрипты для автоматизации). В процессе разработки скриптов мы придерживаемся стандартной модели git-flow с релизными и фича-сборками. Перед тем как слить ветки, код в них обязательно проходит код-ревью: автоматический, при помощи SonarQube, и ручной от коллег.

    Открытое сообщество Open DevOps Community на GitHub


    Особых преимуществ для организации CI/CD процессов на базе open-source решений мы не видим. На эту тему множество споров, но каждый раз приходится выбирать, что лучше: коробочное решение, заточенное под конкретные цели, или решение «as is», которое придется допиливать и поддерживать, но предоставляющее широкие возможности кастомизации. Однако, в прошлом году на завершении нашего митапа Op!DevOps! 2016 мы рассказали о том, что нам разрешили выкладывать часть кода инструментов компании в open-source. Тогда мы только анонсировали сообщество DevOps-разработчиков Open DevOps Community. А уже в этом году, на митапе Op!DevOps! 2017 мы подвели промежуточные итоги по его развитию.

    В этом сообществе мы пытаемся объединить труд различных специалистов в единую систему лучших практик, знаний, инструментов и документации. Мы хотим делиться с коллегами тем, что умеем сами, а также перенимать их опыт. Согласитесь, ведь бывает так полезно обсудить сложную задачу с понимающим коллегой. Все, что мы делаем, — открытые инструменты. Приглашаем всех пользоваться ими, улучшать, делиться знаниями и подходами в DevOps. Если у вас есть идеи или инструменты для автоматизации чего-либо, давайте делиться ими через сообщество Open DevOps Community под MIT-лицензией! Это модно, почетно, престижно.

    Цель сообщества Open DevOps Community — сформировать открытые готовые решения для управления полным циклом процесса разработки, тестирования и смежных процессов, а также доставки, развертывания и лицензирования сложных, многокомпонентных продуктов.

    На данный момент сообщество находится в начальной стадии своего развития, но уже сейчас в нем можно найти некоторые полезные инструменты, написанные на Python. Да, мы его любим.

    • crosspm — универсальный менеджер для скачивания пакетов для сборок многокомпонентных продуктов, по правилам, заданным в манифесте (подробнее на видео по ссылке);
    • vspheretools — инструмент для управления виртуальными машинами на vSphere прямо из консоли, с возможностью подключения в качестве API-библиотеки в Python-скриптах (подробнее на видео по ссылке);
    • YouTrack Python 3 Client Library — Python-клиент для работы с API YouTrack;
    • TFS API Python client — Python-клиент для работы с API MS TFS;
    • Artifactory — Python-клиент для работы с API хранилища бинарных данных Artifactory;
    • FuzzyClassificator — универсальный нейронечеткий классификатор произвольных объектов, свойства которых могут быть оценены на нечеткой измерительной шкале (подробнее на видео и в статье).

    Каждый инструмент имеет автоматическую сборку в Travis CI с выкладкой в PyPI-репозиторий, где их можно найти и установить через стандартный механизм: python pip install.

    Готовятся к публикации еще несколько инструментов:

    • CrossBuilder — система организации кросс-платформенных сборок Build As a Code, наподобие Travis CI, но не зависящая от используемой CI-системы (TeamCity, Jenkins, GitLab-CI);
    • ChangelogBuilder — генератор release notes с описанием изменений по продукту, который получает и агрегирует данные из различных трекеров: TFS, YouTrack, GitLab, Jira (подробнее на видео по ссылке);
    • pyteamcity — доработанный python-клиент для работы с API TeamCity;
    • MSISDK — SDK для создания msi-пакетов для инсталляторов.
    • SupplyLab — система для публикации, хранения, доставки, развертывания и лицензирования продуктов и обновлений для них (подробнее на видео).

    Мы приглашаем всех желающих к участию в развитии сообщества! У нас есть типовой проект ExampleProject, в котором содержатся общая структура и подробная инструкция по созданию собственного проекта в сообществе. Достаточно его скопировать и сделать свой проект по аналогии (см. шаги для подготовки на рисунке 4).



    Рисунок 4. Несколько простых шагов для подготовки своего инструмента к публикации в Open DevOps Community

    Ретроспектива и планы на будущее


    Подходит к концу 2017 год и уже можно провести небольшой ретроспективный анализ проделанной нашей командой работы по развитию идей DevOps в Positive Technologies:

    1. 2014 год — осознание того, что на имеющихся у нас тогда технологиях (svn, SharePoint, TFS) далеко не уедешь, после чего были начаты работы по исследованию и пилотированию новых CI/CD-систем.
    2. 2015 год — подготовлены и настроены типовые сценарии и процессы, построен каркас системы DevOps на базовой связке TeamCity + GitLab + Artifactory (подробнее на видео).
    3. 2016 год — активное наращивание объемов сборочных и тестовых конфигураций (до +200 в месяц!), перевод всех процессов на типовую релизную схему сборок с продвижениями, обеспечении стабильности и отказоустойчивости сборочной инфраструктуры.
    4. 2017 год — закрепление успехов и стабилизация роста проектов, качественный переход на удобство использования всех сервисов, предоставляемых DevOps-командой. Немного подробнее:
      • по статистике, только за ноябрь 2017 для имеющихся сейчас ~4800 активных сборочных конфигураций на нашей инфраструктуре было запущено ~110000 сборок, общей длительностью ~38 мес., в среднем по 6.5 мин. на сборку;
      • 2017 год мы впервые в нашем отделе начали с годовым планом, в который входили нестандартные задачи, выходящие за обычную рутину, с которой может справиться один инженер, и решение которых потребовало значительных трудозатрат, совместных усилий и экспертизы;
      • завершили перевод сборочных окружений в docker и выделили два единых пула сборщиков под windows и linux, вплотную подошли к описанию сборок и инфраструктуры на DSL (для парадигм build as a code и infrastructure as code);
      • стабилизировали систему доставки обновлений SupplyLab (немного статистики по ней: заказчики выкачали ~80Тб обновлений, опубликовано 20 релизов продуктов и ~2000 пакетов обновлений).
      • в этом году мы стали рассматривать свои производственные процессы с точки зрения используемых технологических цепочек и получения так называемого конечного полезного результата (КПР).

    Так зачем же нужен отдел автоматизации в нашей компании? Мы так же, как и другие подразделения, работаем на конечный полезный результат, поэтому основная цель, преследуемая от внедрения идей DevOps в наши производственные процессы, — это обеспечить последовательное снижение себестоимости производства КПР.

    В качестве основной функции нашего DevOps-отдела мы видим макросборку отдельных частей в единый полезный продукт и сокращение себестоимости цепочки: производство — доставка — развертывание ПО.

    У нас продуктовая компания и исходя из ее будущих потребностей были определены глобальные задачи для нашего отдела на 2018 год:

    1. Обеспечение стабильности процессов разработки за счет:
      • соблюдения SLA по сборкам и времени решения типовых задач
      • профилирования и оптимизации «узких» мест по всем направлениям работ и процессам в командах;
      • ускорения локализации проблем в сложных производственных цепочках за счет более точной диагностики и мониторинга).
    2. Регулярное проведение вебинаров о существующих наработках, чтобы переиспользовать решения в продуктах и обеспечить серийность производства.
    3. Перевод на серийное дублирование процессов и инструментов в командах. Например, ускорение подготовки типовых сборочных проектов, в первую очередь, за счет CrossBuilder.
    4. Ввод в эксплуатацию системы управления составом релиза и качеством собранных компонент и инсталляторов, за счёт использования возможностей CrossPM и DevOpsLab.
    5. Разработка DevOpsLab — системы автоматизации и делегирования типовых задач в проектные команды. Например, продвижение пакетов и инсталляторов, генерация типовых сборочных, деплойных и тестовых проектов, управление ресурсами проектов, выдача прав, простановка меток качества компонент и инсталляторов.
    6. Разработка типового и тиражируемого процесса поставки наших продуктов через систему обновлений SupplyLab.
    7. Перевод всей инфраструктуры на использование парадигмы infrastructure as code. Например, подготовить типовые сценарии развертывания виртуальных машин и окружения на них, разработать классификацию машин по потребляемым ресурсам, учет и оптимизация использования виртуальных ресурсов.

    Вместо заключения


    Нас иногда спрашивают, что нам особенно запомнилось в нашей работе, какие ситуации из нашей практики внедрения DevOps были примечательны и чем. Однако, сложно выделить какой-то один случай, ведь, как правило, запоминаются авралы и их разрешение. Мы не приветствуем авралы, а любим четко запланированную работу по выстроенному процессу — когда все стабильно, предсказуемо, ожидаемо, а в случае форс-мажоров предусмотрены запасные варианты. Именно по такому принципу мы и стараемся строить наш сервис год за годом.

    Нам интересно работать с любыми задачами по автоматизации: выстраивать CI/CD, обеспечивать отказоустойчивость релизных сборочных процессов, заниматься мониторингом и оптимизацией ресурсов, а также помогать людям выстраивать процессы в командах и разрабатывать полезные инструменты. Для нас важен планомерный, последовательный процесс построения DevOps как сервиса — ведь это стремление к лучшему.

    P.S. А вот немного наших Telegram-стикеров для DevOps-ов.

    Статья подготовлена на основе интервью в журнале Системный администратор и доклада на Op!DevOps! 2017 (слайды).

    Автор: Тимур Гильмуллин, руководитель группы поддержки процессов разработки, Positive Technologies
    Positive Technologies
    182,37
    Компания
    Поделиться публикацией

    Комментарии 13

      0
      Очень интересно, спасибо, буду ждать публикации ваших продуктов, в особенности интересно посмотреть на CrossBuilder
        0
        Спасибо! Постараемся довести их до ума в следующем году. PS/ Надо же, я удивился увидев, что когда то читал и использовал вашу статью про гугл-апи – она была полезной.
          0
          Рад, что статья помогла. Загляните в мой блог, может и там что найдете ;)
        –2

        OMFG! и ведь эти люди на полном серьёзе уверены, что у них DevOps, CI и даже CD...

          –1
          Ребята, вы решили заопенсорсить несколько своих тулов, это похвально, спору нет.
          Но при этом вешать туда шильдик Open DevOps Community, и я цитирую: «Tools, best practices and examples for the open community of automation engineers.» это перебор.
            +1
            Я удивился, увидев такой ваш комментарий. Возможно, возникло какое-то недопонимание сути статьи. Более того, когда-то я с удовольствием прочитал вашу статью про девопс. Ещё раз перечитав её, я не нашёл противоречия с нашей: у нас нет ни «отдела девопс из 35 человек», мы не «нанимаем сисадминов с кучей доп.компетенций», и в то же время мы и пытаемся в нашей большой компании создать и внедрять «простые работающие решения». Кроме того, мы уже 4й год, также как и описывали вы в своей статье, работаем в направлении взаимодействия между разработчиками, тестировщиками и ИТ-службами. За что отвечает наша служба автоматизации и какие на неё возложены роли, мы честно и подробно написали в 3-4-5 абзацах статьи.

            Что касается названия «Open DevOps Community» и всего прочего – да, частично согласен, возможно мы немного поспешили с его анонсом. Но с другой стороны – где нашим парням выкладывать свой код? Кроме того, опять же, почему «Tools, best practices and examples for the open community of automation engineers» — это перебор? Если мы именно это и хотим сделать в итоге, то зачем писать что то другое? А как бы вы предложили назвать? Кроме того, как я и написал в статье, проект фактически только стартовал и не претендует на мега-систему девопса и истину в последней инстанции. Будем развиваться потихоньку.
              0
              1. Я не автор статьи, это перевод. Это не к тому, что я с ней не согласен, а просто мне режет слух «ваша статья».
              2. Я не критикую по теме DevOps в вашей компании, потому что это не мое дело и потому что, если результат положительный, какая разница.
              3. Почему так резко отозвался на тему названия на github? Просто, честно говоря, каждый день вижу появление этих «всероссийских» devops сообществ, а толку нет почти. А description намекает, что для вас DevOps = automation.

              А так, призываю еще поучаствовать в инициативе Саши Титова devopsrussia.org
              Он рассказывал о ней на DevOops Piter.
            0
            Зачем нужен TeamCity, если его функции может выполнять Gitlab?
              0
              Спасибо за вопрос. Возможно я повторюсь, но мне кажется, в статье я уже подробно ответил на него:

              «На TeamCity мы перешли после долгого периода эксплуатации и сборок на MS TFS. Переезд долго тестировался, обкатывался на небольших продуктах, и лишь затем его провели полностью. Основная причина — необходимость в простых типовых решениях и масштабируемости сборочной и тестовой инфраструктуры для многокомпонентных продуктов, написанных на различных языках программирования. TFS этого нам дать не мог.»

              К этому могу добавить только то, что это был 2014 год (когда мы искали замену CI на базе TFS), а что-то вменяемое для CI на базе GitLab начинает появляться только сейчас. Мы тоже сейчас экспериментируем с GitLab-CI и переводом «простых» сборок на него, но TeamCity, всё-таки, сейчас гораздо приятнее внешне и мы хорошо отладили в нём масштабирование наших сборочных проектов. Можно долго спорить по этому поводу, но для больших многокомпонентных продуктов сейчас GitLab-CI ещё не очень удобен в эксплуатации. Но мы не теряем надежды на переезд в GitLab-CI и, кроме того, с помощью инструмента CrossBuilder мы надеемся сохранить и перенести все наши скриптовые наработки для TeamCity-метараннеров (которых у нас уже несколько сотен) в GitLab-CI.
              0
              Можете подробней описать об использовании Kubernetes. Используете ли вы его в production или только в dev и test среде? какова стабильность работы? и т.п.
                0
                К сожалению, сейчас прокомментировать что-то по сценариям использования Kubernetes для DevOps-задач я не могу, т.к. активно он в нашей команде не применяется. Возможно, в статье нужно было уточнить, что Kubernetes используется в разработке (dev+test) некоторых наших продуктов, которым мы помогаем, но не непосредственно нами. Подробнее про эти продукты я пока рассказать не могу.
                0
                Ребят, статья прекрасная. Пару вопросов: Почему перепрыгивали с TFS на TeamCity, а не на Jenkins, чем он для вас оказался хуже (и оказался ли)? И исходя из вот такой вот записи
                и Windows (2003-2016)
                решил что у вас имеется legacy (может ошибаюсь). Но если всё же есть, то как вам его удается подружить с CI/CD, если оно писалось тогда, когда у вас еще DevOps не было и в помине? Спасибо.
                  0
                  Большое спасибо, за высокую оценку! Мы рады, что добавили свою копеечку в общее дело! Насчёт Jenkins. В 2014 году мы не стали рисковать пересаживаться на опен-сорс решения в виде Jenkins – в то время, нам показалось, что может быть множество проблем с обновлениями самого Jenkins, его поддержкой и многочисленных плагинов, которые нам были нужны. Также, в то время были не очень хорошие отзывы о нём со стороны инженеров. Которые работали с ним более плотно, а TeamCity очень хорошо себя показал на пилотных испытаниях проектов, продемонстрированных тем, кто принимал тогда решение о его использовании.

                  Насчёт легаси. Как и у всех достаточно крупных компаний, есть оно и у нас, но, что касается CI/CD инфраструктуры – его у нас минимально: из «старья» на поддержке остался только 1 сборочный сервер, со своей самописной CI-системой. Всё остальное было переведено на новые рельсы, описанные в статье. Сборочные сервера у нас имеются различных типов с различными ОС, это зависит от требований разработчиков, собирающих тот или иной модуль. На каждом из них стоит сборочный агент, поэтому проблем с их дружбой с текущей CI-системой не возникает.

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

                Самое читаемое