Развитие сообщества Open DevOps Community

Editor's Notes

1. Уважаемые коллеги, в прошлом году на завершении предыдущего митапа Op!DevOps! мы рассказывали про то, что нам разрешили выкладывать часть кода инструментов Компании в опенсорс и мы решили начать делиться некоторыми наработками с Сообществом в рамках проекта DevOpsHQ на GitHub-e.
2. Немного напомню о том, какие проблемы мы пытались решить. В начале прошлого 2016 года перед нами стояла проблема, что нет готового объединяющего решения для CI/CD-систем.
3. Немного подробнее: - Отсутствие готового каркаса открытой системы управления полным циклом процесса разработки, доставки, развёртывания и лицензирования. - Отдельные системы: Gitlab, TFS, Teamcity, Artifactory, статьи Best-Practise и блоги, разрозненная документация. - Уникальные знания отдельных специалистов Компании о продуктах и их сборке.
4. Для решения перечисленных проблем на нашем прошлогоднем митапе (см. все видео c Op!DevOps! 2016 по ссылке) мы анонсировали открытие сообщества devops-разработчиков Open DevOps Community на базе GitHub-проекта DevOpsHQ.
5. В сообществе DevOpsHQ мы попытались объединить труд различных специалистов в единую систему лучших практик, знаний, инструментов и документации.
6. Немного о наших целях
7. Цель сообщества Open DevOps Community — сформировать открытые готовые решения для управления полным циклом процесса разработки, тестирования и смежных процессов, а также доставки, развёртывания и лицензирования продуктов.
8. На данный момент сообщество находится в начальной стадии развития, но уже сейчас в нем можно найти некоторые полезные инструменты, написанные на Python. Да, мы его любим. Опубликованные проекты: crosspm — универсальный пакетный менеджер, который позволяет скачивать пакеты для сборок многокомпонентных продуктов, используя правила, заданные в манифесте. vspheretools — инструмент, который позволяет управлять виртуальными машинами на vSphere прямо из консоли. Также есть возможность подключать его как API-библиотеку в своих Python-скриптах. YouTrack Python 3 Client Library — Python-клиент для работы с API YouTrack.  TFS API Python client — Python-клиент для работы с API Team Foundation Server от Microsoft. A Python client for Artifactory — Python-клиент для работы с API хранилища бинарных данных Artifactory. FuzzyClassificator — универсальный нейронечёткий классификатор произвольных объектов, свойства которых могут быть оценены на нечёткой измерительной шкале. Каждый инструмент имеет автоматическую сборку в Travis CI с выкладкой в PyPI-репозиторий, где их можно найти и установить через стандартный механизм: python pip install.
9. Готовятся к публикации еще несколько инструментов:  CrossBuilder — система организации кросс-платформенных сборок build as a code, наподобие Travis CI, но независящая от используемой CI-системы (TeamCity, Jenkins, GitLab-CI и т. п.).  ChangelogBuilder — генератор релиз-нотов с описанием изменений по продукту, который получает и агрегирует данные из различных трекеров (TFS, YouTrack, GitLab и т. п.).  pyteamcity — свой доработанный python-клиент для работы с API TeamCity.  MSISDK — SDK для создания msi-пакетов для инсталляторов продуктов.
10. В качестве контрибьюторов любого инструмента приглашаются все желающие. У нас есть типовой проект ExampleProject, в котором содержатся общая структура и подробная инструкция по созданию собственного проекта в сообществе. Фактически достаточно его скопировать и сделать свой проект по аналогии. Если у вас есть идеи или инструменты для автоматизации чего-либо, давайте делиться ими с сообществом под MIT-лицензией! Это модно, почётно, престижно :) 
11. Далее расскажем немного о планах развития Сообщества DevOpsHQ
12. Для начала попытаемся понять, какие цели преследует DevOps в нашей компании? Подходит к концу 2017 год и уже можно провести ретроспективный анализ: 2015 год — настройка базовых сценариев и процессов, построение скелета-каркаса системы DevOps. 2016 год — активное наращивание объёмов сборок и тестовых процессов. 2017 год — закрепление успехов и стабилизация роста, качественный переход на удобство использования. 2017 год мы впервые в нашем отделе начали с годовым планом для крупных задач. В него входили задачи, решение которых требовало значительных трудозатрат и экспертизы, например, перевод сборочных окружений в docker и выделение двух единых пулов сборщиков под windows и linux. В 2017 мы стали рассматривать свои производственные процессы с позиции технологических цепочек и получения общего Конечного Полезного Результата (КПР).
13. Так зачем же нужен DevOps в нашей компании? Devops также как и другие подразделения работает на Конечный Полезный Результат. Поэтому считаем основной целью DevOps — обеспечение снижения себестоимости производства КПР. В качестве основной функции DevOps в компании мы видим макросборку частей в единый полезный конечный продукт и сокращение себестоимости цепочки: производство — доставка — развёртывание ПО.
14. За 2017 год у нас стабилизировалась система доставки обновлений SupplyLab. Система SupplyLab в 2017 году в цифрах: 1. Заказчики выкачали 80Тб обновлений. 2. Было опубликовано порядка 20 релизов продуктов. 3. Было опубликовано ~2000 пакетов обновлений с данными. Мы не смогли опубликовать систему SupplyLab в 2017 году на GitHub в DevOpsHQ. Причина: глубокая интеграция проверки лицензий в код самой системы. Сейчас мы разделили кодовую базу ядра и лицензионных проверок и рассчитываем начать публикацию SupplyLab в 2018 году.
15. У нас продуктовая компания — этим определяется вектор развития DevOps в компании. Вектор целей управления на 2018: 1. Обеспечение стабильности процессов разработки. 2. Регулярное проведение вебинаров о существующих наработках, чтобы переиспользовать решения в продуктах, то есть, обеспечить серийность производства. 3. Анализ процессов продуктовых команд для выявления узких мест, которые может решить DevOps. 4. Перевод на серийное дублирование процессов в командах.
16. Направления развития в 2018: 1. Расширение серийности — добавление новых типовых сборочных шаблонов, в первую очередь, за счёт CrossBuilder. 2. Ввод в эксплуатацию системы управления составом релиза и качеством входящих пакетов (CrossPM + DevOpsLab). 3. Типовой процесс поставки через систему обновления SupplyLab. 4. Выход на технологию Infrastructure As a Code — типовые сценарии развёртывания ВМ, классификация по потребляемым ресурсам, учёт и оптимальное использование ресурсов. 5. Профилирование и оптимизация процессов сборки, развёртывания, доставки.
17. Планы DevOpsHQ на 2018 год: найти партнёров, готовых развивать общую открытую систему DevOps. Где нам нужна помощь в первую очередь? 1. Разработка CrossBuilder — открытой системы Build As a Code и шаблонов типовых проектов для неё. 2. Управление составом дистрибутива на базе сборочных контрактов пакетов и их меток качества. 3. Разработка DevOpsLab — системы автоматизации и делегирования типовых задач в проектные команды (например, продвижение пакетов и инсталляторов, генерация типовых проектов, управление ресурсами проектов, выдача прав, простановка меток качества и т.п.). В конце хотелось бы поблагодарить всех коллег, развивающих правильные идеи автоматизации, и пригласить всех желающих к сотрудничеству. Давайте вместе делать инструменты, снижающие себестоимость производства Конечного Полезного Результата!