Старый но, полезный доклад про развитие сообщества Open DevOps Community, в рамках которого создаются продукты объединяющего решения для continuous integration, continuous delivery систем.
Надеюсь что сообщество Open DevOps Community разовьется и усилится.

Уважаемые коллеги, в прошлом году на закрытии аналогичной встречи мы рассказали, что нам разрешили выкладывать код компании в open source. И частично в течение этого года мы постарались какие-то свои наработки представить в сообщество.

Делимся мы кодом в рамках сообщества Open DevOps Community, который в том же 2016-ом году открыли.

Хочу немножко напомнить о проблемах, с которыми мы столкнулись на начало 2016-го года. Основная проблема была в том, что у нас не было какого-то готового объединяющего решения для continuous integration, continuous delivery систем.

А также были следующие проблемы:

Отсутствие готового каркаса для системы управления всех циклов разработки, доставки, развертывания и лицензирования.
Отдельные системы: GitLab, TFS, TeamCity, JFrog Artifactory и статьи best practice, и разрозненная документация. По ним не было единой базы знания.
Разрозненные знания отдельных специалистов компании о продуктах и их сборке, которые они не передавали. И с их уходов мы эти знания просто теряли.

https://habrahabr.ru/company/pt/blog/310584/

https://www.youtube.com/playlist?list=PLEl1NAXHTFNxcKRN09VQThNbQ33neUyfn

Для решения перечисленных проблем на нашем прошлогоднем этапе мы объявили о создании сообщества DevOps разработчиков на базе GitHub. Это проект DevOpsHQ. Можно перейти по ссылочкам в этой презентации

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

Основной целью в Open DevOps Community является формирование открытого готового решения для управления:
Полным циклом процесса разработки,
Тестирования,
Доставки,
Развертывания,
Лицензирования продуктов.

Соответственно, мы готовим под это дело инструменты.

На данный момент сообщество находится в активной стадии своего развития. И за год нам удалось некоторые инструменты выложить.

Из активных проектов это:

Сейчас готовятся к публикации в ближайшее время еще несколько проектов.

Это:

CrossBuilder – система для организации кросс-платформенных сборок, которые будут использовать подход Build As a Code, но не зависящее от использования CI-систем.
ChangelogBuilder – инструмент, про который нам рассказывал Леша Гуров. Это генератор release notes с описанием изменений по продукту, который получает и агрегирует данные из различных источников, которые можно подключить как отдельный модуль.
Pyteamcity – доработанный python-клиент для работы с API TeamCity.
MSISDK – инструмент для упрощения и создания msi-пакетов для инсталляторов.

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

Все инструменты имеют автоматическую сборку в Travis Ci и выкладкой в PyPi репозитории.

Разработка у нас в основном идет на Python, потому что мы его очень любим.

И для упрощения вхождения в наше сообщество мы подготовили типовой проект из ExampleProject, в котором содержатся описание, документация, структура типового проекта.

И есть инструкция, как за 3 простых шага подготовить свой проект к выкладке в сообщество. Шаги простые:

Первый шаг. Подготовка репозитория. Это включает в себя настройку репозитория. Также нужно подготовить к ней документацию и оценить автоматически качество кода, при помощи инструмента c… .
Второй шаг. Это подготовка автосборки в Travis CI, т. е. необходима какая-то интеграция, которую мы включаем буквально одной галочкой. Также нужно подготовить сборочный скрипт setup.py. Настроить конфигурацию в travis.yml. И организовать выкладку в PyPI. Это все несложно, инструкции подробные есть.
Третий шаг. Публикация новости о релизе в канале проекта.

Т. е. если у вас есть инструменты для автоматизации чего-либо и вы готовы ими поделиться, давайте делиться ими со всем сообществом. Сейчас это модно, почетно, престижно.

Немного о планах развития нашего сообщества и о планах развития DevOps в целом расскажет мой коллега Саша Паздников. Я ему передаю слово.

(Саша Паздников) Всем привет!

2014-2015-ый год можно охарактеризовать, как становление каркаса нашей системы в компании.

В 2016-ом году мы активно росли и расширялись.

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

2017-ый год мы впервые открыли с годовым планом для крупных задач. И стали рассматривать DevOps не как отдельную структуру, а стали рассматривать DevOps с точки зрения, как он входит в общетехнологический процесс внутри компании. И цель – это получение общего конечного полезного результата. Все компании работают на получение конечного полезного результата.

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

Основная цель DevOps – это сокращение себестоимости производства конечного полезного результата.

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

И они в рамках нашей компании являются ключевыми вещами для DevOps.

В 2017-ом году мы активно вышли на уровень мышления поставки и развертывания наших продуктовых решений на инфраструктуру заказчика.

И система у нас называлась SupplyLab. В том году мы ее анонсировали.

Небольшие цифры за этот год. Видно, что в том году мы ее только запускали, там было буквально несколько релизов – 3-4, несколько обновлений – 10-20. И здесь цифры уже разнятся в сотни раз.

И мы планировали за 2017-ый год опубликовать систему SupplyLab в сообществе DevOpsHQ, но не смогли выполнить эту задачу по причине очень жесткой интеграции в самой системе наших лицензионных проверок. Не хватало именно по ресурсам.

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

Это обеспечение стабильности процессов разработки. Это самое важное, чтобы конвейер работал постоянно и без сбоев.
Мы сейчас начали выходить на подготовку и проведение вебинаров внутри компании. Для чего? Потому что то количество наработок, которое уже есть, о нем нужно рассказывать. Команд много. И чем конкретно кто-то занимается не всегда знают. Об этом могут просто не знать. Поэтому мы с середины лета начали проводить на регулярной основе вебенары по софту. Сейчас будем проводить по поставке и развертыванию обновлений инфраструктуры заказчиков. И выделили определенное функциональное направление внутри DevOps, по которому мы планируем проводить на регулярной основе вебинары. Цель – сокращать свою стоимость.
В 2015-2016-ом году мы сильно росли, масштабировались. При таком росте, скорее всего, есть какие-то неоптимальности. И для того чтобы их найти, мы сейчас более активно входим в процесс анализа процессов продуктовых команд, чтобы понять, как работают процессы внутри. Для чего? Для того, чтобы вносить какие-то рациональные предложения, которые, может быть, в DevOps уже решены или решены лучше. И, может быть, можно вынести какие-то решения для сплачивания с другими проектами. Возможно, каждый решает какую-то задачу, но по-своему. Т. е. требуется именно анализ процесса внутри команд.
И перевод на серийное тиражирование наших решений именно внутри продуктовых команд.

Ключевые направления – это:

Серийность, потому что не серийное производство – это очень дорого. У нас все-таки задача стоит именно снижать себестоимость. И в первую очередь это можно сделать за счет серийных и типовых процессов. По многим серийным вещам будут представлены доклады. Это и шаблоны, и infrastructure as code, и типовые сборочные шаблоны.
Ввод в эксплуатацию системы управления составом релиза и качеством входящих пакетов. У нас уже наработана схема по CrossPM. Мы планировали запустить эту модель еще в середине лета, но вышли другие приоритетные задачи. И сейчас мы подходим к работе именно по меткам качества и контрактов. Что это значит? Это значит, что есть большое количество сборок. И контракты меток качества – это умение нарезать это множество таким образом, которое нужно конкретной продуктовой команде. Собрать стабильный релиз, собрать фичи релиз из пакетов продуктов и т. д. Т. е. именно нарезки этого множества по критериям контрактов между компонентами и качеством с точки зрения, насколько эта версия компонентов готова к выпуску.
Сейчас приводились статистические данные по SupplyLab. У нас все больше и больше проектов входят в эту систему именно по поставке, доставке обновлений. Соответственно, мы видим, что есть типовые решения. И одно из направлений – предоставить типовой проект простого подключения: как можно подключить, как создать обновление. И как это у нас получается в системе SupplyLab, и как получается у нашего заказчика. Сейчас из ключевого – это типовой процесс на базе манифеста. Т. е. в продукте при выпуске релиза фиксируется из каких пакетов он состоит. Этот манифест публикуется на абуз. Система забирает с Artifactory по списку манифеста из разных репозиториев. И это становится доступно для кэширующих серверов, которые находятся в разных ЦОД и для скачивания уже на инфраструктуру заказчика.
Переход на технологию infrastructure as code – это одно из ключевых направлений развития. Потому что это оптимизация именно используемых ресурсов, т. е. использование их столько, сколько нужно, но не больше.
И еще ключевое одно из направлений – это профилирование. Мы, в принципе, от разработки мало чем отличаемся. У нас тоже где-то может быть неоптимальность, где-то может что-то периодически профилироваться. Что здесь мы видим под профилированием? Это классификация наших типовых шагов, понимание сбора метрик по времени, по которому они проходят. А также понимание, какие шаги мы можем оптимизировать.

Мы смотрим в первую очередь в сторону равноправного партнерства, т. е. мы готовы к равноправному партнерству. И это ключевая вещь всего нашего сообщества DevOpsHQ.

В чем нам наиболее необходима помощь? Это:

Разработка CrossBuilder. Т. е. это система очень похожая на Travis, но только …, т. е. те, кто не могут собирать на GitHub, но они не должны быть обделены тем, что им приходится исключать из своих процессов build as a code. Поэтому CrossBuilder – это как раз такая система.
Управление составом дистрибутива на базе сборочных контрактов пакетов и их меток качества. Это ключевая вещь, которая нам нужна. И здесь по управлению метками качества мы в этом году также не успели начать разработку, т. е. хотя бы сделать одну из ключевых частей по DevOpsLab.
И помощь в разработке DevOpsLab, конечно, мы бы очень хотели.

Вот три ключевых направлений и планов на 2018-ый год.

Благодарю за внимание! Присоединяйтесь, пожалуйста!

Телеграм канал DevOpsHQ https://t.me/devopshq

Развитие сообщества Open DevOps Community. Тимур Гильмуллин. Александр Паздников