Как несложно догадаться из названия, на прошлой неделе я побывал в Берлине на очередной Jenkins User Conference. Я не планировал открыть для себя что-то новое, но скорее хотел посмотреть на тренды в области Continious Integration/Delivery и пообщаться с коллегами из крупных IT компаний.

Прилетел в Берлин я рано утром за день до самой конференции и это было правильным решением =). Нет, не потому, что можно было выспаться в отеле и погулять по городу. В этот день проходила еще одна встреча, посвященная вопросам CI/CD - #CDday, а две конференции лучше чем одна =).

Интересные доклады и идеи

CDday начался с доклада “Continuous Delivery: Lessons from the Aviation Industry”. Рассказ мало относился к заявленной теме, а был скорее больше про командную работу. В основном рассказывали про стандартные вещи - коачинг (как более эффективный метод управления), постоянную рефлексию (ретроспективный анализ как проблем, так и успехов), открытость в высказывании идей и т.п.. Интересной мне показалась идея “error prevention/error management”. Т.к. от всех ошибок защититься невозможно, пилоты должны знать, что делать в случае проблем и действовать слаженно. Проводя аналогию с разработкой, возникают следующие вопросы: Можете ли вы быстро откатить неудачный релиз? Можете ли вы быстро выкатить хотфикс, исправляющий эту проблему? Сколько человек из команды требуется чтобы это сделать?

Еще одним докладом, который мне запомнился, был “Continuous Delivery in the Real World” от software архитектора из компании Bosch. Он разделил весь процесс перехода к CD на 4 этапа:

унификация сборочной платформы (Jenkins Enterprise)
разбор монолитного приложения на множество отдельных артефактов (у них получилось ~10000 компонент)
унификация инструментов сборки и хранения артефактов (gradle, artifactory, bash)
разработка кастомных инструментов, чтобы люди, далёкие от разработки не выпадали из общего цикла (команда разработки около 500 человек, половина из них занимается созданием контента, другая половина - платформой, очевидно что уровень первых и вторых сильно разный)

В результате, полу-ручная сборка, которая занимала около недели, сейчас проходит за несколько минут и полностью автоматически. Действительно впечатляющий результат! Из интересных решений - они не настраивают билд вручную для каждой из компонент. Полный набор задач для сборки всего приложения генерируется автоматически, как только в репозитории появляется новая ветка. А еще они используют Jenkins для мониторинга Jenkins =).

Из докладов с самого JUC хочется отдельно отметить “Multi-Stage-CI with Jenkins in an Embedded World” от BMW. Разработка embedded приложений для автомобилей сильно отличается от всей остальной разработки. Прежде всего - невероятно высокой стоимостью дефекта в продакшн. Только представьте себе, во сколько обойдётся компании обновление прошивки на миллионах автомобилей по всему миру. Именно поэтому в компании решили максимально сократить время интеграции изменений, как внутри команд, так и между различными компонентами. В результате процесс “доставки строчки кода до продакшена” сократился с нескольких недель до десятков минут. В целом все изменения в процессах построены на основе принципов lean и сфокусированы на скорости и стабильности.

Глобальные тренды

Несмотря на разнообразие разрабатываемых приложений (веб, десктоп, embedded, мобильные) и используемых технологий, основной идеей многих докладов была configuration as code:

Тесная интеграция с инструментами конфигурации и деплоя (chef/puppet/ansible/salt). Хранение их в общем репозитории вместе с остальным кодом и, как следствие, полный релизный цикл - бранчи, статический анализ, ревью и тестирование на различных уровнях.
Автоматическая генерация задач в Jenkins на основе формального описания, хранящегося также в репозитории. Для этих целей существуют различные решения - Literate Plugin, Job DSL plugin или Template Plugin (в Enterprise Jenkins). Преимущества очевидны: повторяемость, отслеживание изменений (и простая их отмена), изоляция не только кода, но и процесса сборки (автоматическое создание джоб для новых бранчей и удаление устревших), автоматическое обновление процесса сборки после мёржа ветки, в общем - все прелести CVS-систем.
Деплой приложений в облако. В частности, везде и всюду упоминался Docker в качестве платформы.

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

Эта встреча была крупнейшей в Европе за последние годы и я был приятно удивлён количеством квалифицированных специалистов. Удивлён - потому что обычно общий уровень квалификации на конференциях ниже среднего. По отдельности мы умные люди, а вместе - подчиняемся распределению Пуассона, да-да =). Ну и конечно же, я не упустил возможности вживую пообщаться с создателем Jenkins - Koshuke Kawaguchi, как на самой конференции, так и вечером в баре за кружечкой немецкого пива =).