Отличное Интервью С Создателем Jenkins Косуке Кавагути

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

Мне всегда было интересно пообщаться с одним из разработчиков и задать пару непростых вопросов.

Здесь у нас не просто разработчик, а сам создатель Дженкинса — Косуке Кавагути .

Как вы знаете, Jenkins — это проект с открытым исходным кодом, имеющий лицензию MIT. Совсем недавно прошла конференция FOSDEM — крупнейшая в мире конференция, посвященная свободному программному обеспечению.

Бесплатное, открытое, с десятками спикеров со всего мира.

Это значит, что там можно встретить кого угодно — даже создателя Дженкинса.

С небольшой группой друзей и коллег из JUG.ru Group мы организовали там неожиданную посадку и смогли записать хорошее интервью с создателем Jenkins. Итак, в нашей виртуальной студии Косуке Кавагути (который представится и подробно все расскажет ниже), Руслан Ахметзянов АРГ89 от JUG.ru Group и Кирилл Толкачев TalkKV от ЦИАН, нашего постоянного спикера, гуру Groovy, Gradle, Spring и технологического стека Netflix, которого вы, возможно, знаете по подкасту «Разбор полетов».

Отличное интервью с создателем Jenkins Косуке Кавагути

Руслан: Привет. Для начала расскажите нам немного о себе и Дженкинсе?

Коске: Меня зовут Коске, я больше всего известен как создатель Jenkins и технический директор CloudBees. Jenkins — это инструмент, который помогает разработчикам автоматизировать различные этапы процесса доставки программного обеспечения.

Я лично знаю нескольких программистов из России, использующих Jenkins, и буду рад возможности познакомиться с другими.

Отличное интервью с создателем Jenkins Косуке Кавагути

Кирилл: Еще представлюсь — я разработчик, а также организую Moscow Jenkins Area Meetup (JAM).

У меня большой опыт использования Jenkins, особенно скриптового/декларативного конвейера.

Можете ли вы рассказать нам, чем занимается технический директор компании, разрабатывающей Jenkins? Коске: Одна из задач моей команды — взаимодействие с сообществом.

Успех нашей компании во многом зависит от успеха основного проекта с открытым исходным кодом.

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

Вы также спросили, какую функцию выполняет технический директор.

Дело в том, что эта функция развивалась по мере роста компании.

Сначала я был своего рода ведущим программистом и выполнял много технической работы.

Но по мере роста компании эту работу постепенно начали выполнять другие люди.

Например, Pipeline стала заниматься отдельная команда.

Я периодически с ними общаюсь, чтобы иметь представление о том, чем они занимаются, и иногда даю советы.

Но все решения, связанные с проектированием и разработкой, они принимают самостоятельно.

В целом, эта эволюция моей роли была очень интересной, и мне постоянно приходилось адаптироваться.

Кирилл: Если я вас правильно понял, ваше внимание переключилось с технических вопросов на работу с сообществом? Коске: Да, многое из того, что я делаю, связано с этим.

Есть вещи, которые может сказать только основатель компании.

Поэтому часть моей деятельности — это, так сказать, размахивать флагом и призывать сообщество в определенном направлении, когда необходима смена курса, как это было, например, в прошлом году.

Кроме того, вместе с командой мы занимаемся продвижением Jenkins: объясняем, какие у нас цели, какие трудности пытаемся преодолеть.

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

Вот как вкратце выглядит моя работа.

Кирилл: Сколько лет назад начался переход от технической работы к организационной? Можете ли вы рассказать нам историю Дженкинса и как изменилась ваша роль по мере роста проекта? Коске: Проект появился в 2004 году, и первое время я работал над ним по вечерам и выходным, то есть это было своего рода хобби.

Но постепенно проект разросся.

Я потратил довольно много времени на создание этой платформы, на которой другие люди могли бы писать свои приложения.

Со временем возникла экосистема и сообщество разработчиков, некоторые из которых были из России — например, Олег Ненашев (Твиттер: @oleg_nenachev ), который написал очень интересную подсистему поверх Jenkins. По мере того, как проект набирал популярность, необходимость улучшения взаимодействия с пользователем и обучения становилась все более острой.

Поэтому я начал делать больше подобных вещей.

Наконец, где-то в 2010 году Дженкинс стал настолько популярен, что я решил посвятить ему все свое время и создал компанию.

С этого момента к работе с сообществом добавилась работа по организации компании.

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

Постепенно они начали делать многие вещи, которые я раньше делал сам.

Вот, в общих чертах, как выглядел наш путь.

Кирилл: Спасибо.

Jenkins — самая популярная на сегодняшний день система CI. Насколько распространена коммерческая версия Jenkins по сравнению с другими коммерческими системами CI? Например, с Travis Enterprise или с системами, которые могут работать локально? Коске: Jenkins с открытым исходным кодом — большой проект, у него много пользователей.

CloudBees имеет гораздо меньший масштаб.

Поэтому, если нам удастся конвертировать хотя бы один процент пользовательской базы Jenkins в пользователей CloudBees, это будет очень большой результат. По этому принципу работают все компании, основанные на продуктах с открытым исходным кодом.

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

Кирилл: Вы имеете в виду тех, кто пользуется платной версией? Или те, у кого есть бесплатные, тоже? Коске: Оба из них.

То есть, если человек покупает продукт, ему будет оказана поддержка, но его можно получить и без использования фирменного ПО.

Кирилл: То есть вы выступаете в роли посредника между разработчиками и вашими пользователями, как с открытым исходным кодом, так и коммерческими.

Правильно ли я понимаю, что вы также отвечаете за видение продукта? Коске: Это не совсем так, у нас есть отдельная продуктовая команда.

Я не являюсь представителем пользователей, но постоянно провожу встречи со многими людьми, пользователями и другими людьми, то есть поддерживаю связь с сообществом.

Например, у меня есть раздел «Отчеты с фронта» для других сотрудников компании.

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

Так я пытаюсь влиять на решения, которые принимает продуктовая команда.

Кирилл: Судя по всему, вы играете важную роль в компании.

Перейдем к более личным вопросам.

Какая ваша любимая особенность в Jenkins, о которой вы могли бы говорить с утра до вечера? Коске: Ну, сложно будет разговаривать с утра до вечера.

Меня сейчас больше интересует, как работает организация – думаю, это связано с моей функцией в ней.

Когда я работал один, мое внимание было гораздо больше сосредоточено на отдельных особенностях.

Сейчас я уже так не думаю, поэтому мне сложно ответить на ваш вопрос.

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

Это прошлогодний проект Конфигурация Дженкинса как код .

Мы видели, как наши пользователи постепенно переходят от управления Jenkins с помощью щелчков мыши в графическом интерфейсе к его настройке через файл конфигурации в репозитории git. Необходимость в проекте «Конфигурация как код» ощущалась уже давно, и для выполнения этой функции было написано множество временных костылей.

Но ни одно из этих предприятий не было достаточно масштабным.

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

Можно вспомнить еще один проект Jenkins X, который представляет собой эволюцию совершенно в другом направлении.

Он был создан специально для работы с Kubernetes. Благодаря такой специализации мы можем добиться плавной интеграции и скрыть сложности, возникающие при интеграции и подключении процессов непрерывной доставки.

В результате мы упрощаем внедрение лучших, по нашему мнению, практик.

Я думаю, что благодаря этому проекту Jenkins станет доступен большому количеству людей, выполняющих достаточно стандартные действия и не желающих тратить много времени на настройку, которым нужно, чтобы все просто работало.

Руслан: Используете ли вы Jenkins, когда пишете Jenkins? Коске: Да, в проекте Jenkins есть свой Jenkins. Фактически, у нас есть большой экземпляр, который выполняет проверки запросов на включение каждого плагина и ядра.

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

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

Помимо этих трёх, у меня дома круглосуточно работает отдельный экземпляр.

Кирилл: Вы упомянули Jenkins X. Дженкинс сам по себе похож на швейцарский армейский нож: с плагинами он может делать все что угодно.

Jenkins X, напротив, узкоспециализирован; он существует для Pipeline и работы с Kubernetes. Какую техническую стратегию вы и ваша компания преследуете? Вы поддерживаете только Jenkins и Jenkins X? Или помимо этого будут еще Jenkins X X для кластеров Mesos, Jenkins X X X для Cloud Foundry и так далее? Коске: Я думаю, многое зависит от реакции сообщества.

Наличие универсальной платформы определенно очень важно.

Вопрос в том, кто именно реализует эту гибкость.

Сегодня пользователи обычно имеют к нему прямой доступ.

Это удобно, если вы большая компания и делаете что-то необычное.

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

Представьте, что вы пришли в столовую и попросили приготовить для вас бутерброд. Вам предлагается на выбор семь видов хлеба, пять видов масла, четыре вида сыра, а также вам необходимо определиться со всеми ингредиентами.

Но вам не нужен весь этот выбор, вы просто хотите вкусный бутерброд и не хотите думать, как его приготовить правильно.

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

Jenkins X — первый серьезный шаг в этом направлении.

Если этот проект продолжит быть успешным, я бы хотел попробовать что-то подобное для встроенного программного обеспечения и Интернета вещей, мобильных платформ или машинного обучения.

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

Вы из России, что вы, скорее всего, знаете о JetBrains? Кирилл: Конечно.

Коске: Я думаю, они придерживаются схожей стратегии.

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

Пользователи благодарны за это, и мне очень нравится их подход. Кирилл: Я уже много лет наблюдаю одну и ту же картину во многих сообществах, когда советую использовать те или иные плагины — мне, кстати, это сейчас очень помогает. https://plugins.jenkins.io , все одобренные плагины имеются.

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

Поэтому сейчас я обычно рекомендую только один инструмент — Pipeline, это идеальный инструмент для всех ситуаций.

Но возникает новая проблема.

Люди пытаются использовать скриптовый конвейер или декларативный конвейер, не понимая, как они работают внутри.

Есть проблемы с инфраструктурой, с маппингом между узлами, разделением данных, необычным трафиком между агентом и мастером или проблемами с масштабированием на мастере.

Какой инструмент, с вашей точки зрения, лучше: тот, который показывает единственно правильный путь решения проблемы, как Jenkins X? Или такой инструмент, как Scripted Pipeline, который спросит вас, что именно вы имели в виду? Коске: Не уверен, что правильно вас понял, но попробую ответить.

В японском языке есть слово «ката», я не знаю, как его точно перевести.

Его используют, в том числе, в дзюдо.

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

Я этим немного занимаюсь, поэтому знаю самые простые.

Цель — выучить набор простых движений, какие-то шаблоны или наработки.

Но это только начало.

Зная эту базу, вы сможете потом правильно от нее отходить, если того потребует ситуация, не нарушая при этом самих основных движений.

Ты изучаешь свое пространство, свою территорию, но при этом тебе еще помогает знание общей базы.

Если ты ее не знаешь, ты всегда будешь спрашивать себя – правильно ли я поступаю? Даже если то, что вы написали, сработает, у вас все равно останутся сомнения.

В любом случае, ваш вопрос напомнил мне ката.

Мне кажется, у нас с Дженкинсом похожая ситуация.

Jenkins X предоставляет основу, и по мере того, как вы углубляетесь в нее, вы можете при необходимости расширять ее с помощью плагинов и других вещей.

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

По большому счету это справедливо для любого программного обеспечения.

Просто с Jenkins X у нас произошел важный сдвиг в мышлении.

Ранее мы создали только ключевые элементы системы — платформу и плагины; собирать их должен был пользователь.

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

Кирилл: Если вы не возражаете, у меня еще два вопроса.

Какая функция доставила вам больше всего хлопот за последний год? В каждом проекте бывают трудные периоды.

Можете ли вы рассказать нам, как они выглядели для вас? Коске: Мы действительно несколько раз серьезно портили себе жизнь.

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

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

Это было особенно сложно, когда дело касалось функций, созданных сообществом.

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

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

Кирилл: Есть ли у вас какой-то руководящий орган, который решает, какие функции будут включены в релиз? Расскажите, пожалуйста, как принимаются такие решения и могут ли пользователи просить включить в релиз какие-то функции? Если могут, то кому отдается приоритет — пользователям CouldBees или Jenkins с открытым исходным кодом? Наконец, если возможно, расскажите о своих планах на ближайшие полгода-год. Коске: Здесь есть довольно интересный момент: CloudBees не является владельцем Jenkins, это два отдельных проекта, каждый со своей структурой принятия решений.

CloudBees просто является крупнейшим участником Jenkins, и многие сотрудники CloudBees одновременно работают в сообществе.

Последние несколько лет мы пытались создать в Дженкинсе более четкие структуры контроля, которые бы делали именно то, о чем вы только что спросили.

Для этого мы создали Процесс улучшения Дженкинса … Кирилл: Извините, что прерываю - это сокращенно JEP, так же, как в Java? Коске: Совершенно верно.

Очевидно, что не мы придумали эту концепцию, а позаимствовали ее у Python, Java и некоторых других сообществ, потому что там она уже зарекомендовала себя.

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

Это именно то, что мы делаем, когда CloudBees хочет создать новую функцию, поэтому у нас есть возможность изменить курс в зависимости от полученного ответа.

Это тот элемент планирования, который нам удалось внедрить в нашу работу.

Поскольку мы являемся проектом с открытым исходным кодом, мы не можем напрямую указывать другим участникам проекта, что им делать.

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

Дженкинс X. Над этим работают некоторые сотрудники CloudBees и многие сторонние участники.

Я надеюсь, что «Конфигурация как код» станет более популярной среди разработчиков плагинов.

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

Наконец, если возникнут новые JEP, мы будем над ними работать.

Кирилл: Что ж, будем надеяться, что JEP не запатентованы :) Вопрос к вам как к автору Jenkins — чья идея была Scripted Pipeline? Коске: Это интересный вопрос.

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

До того, как мы начали работать над Pipeline, люди уже пытались сделать что-то подобное в том же пространстве, и у нас была возможность ознакомиться с этими попытками.

Так что на самом деле мы не были изобретателями Pipeline. Одним из таких предшественников был плагин Build Flow, он был написан одним из сотрудников CloudBees еще до прихода в компанию.

Я считаю, что термин «экосистема» очень уместен — все действительно происходит как в реальной экосистеме, созданная кем-то технология постоянно развивается и меняется.

Руслан: Повлияли ли вы на реализацию Scripted Pipeline? Коске: Да, в оригинальной версии.

Кирилл: Как мы знаем, реализовать любой DSL можно двумя способами — статически и динамически.

Почему вы выбрали динамический подход для скриптового конвейера? Коске: Боюсь, я не совсем понимаю, что именно вы подразумеваете под статическим и динамическим подходами.

Кирилл: При использовании статического DSL у нас есть определенная уверенность в нашем коде перед выполнением.

Например, при использовании DSL в Java вам необходимо заранее знать все API и интерфейсы.

При динамическом подходе мы проверяем непосредственно во время выполнения.

Даже если код недействителен, машина все равно попытается его выполнить, просто при необходимости выдаст ошибку.

Декларативная версия конвейера позволяет устранить множество ошибок за счет сужения вариативности в скрипте сборки.

Коске: Честно говоря, мне не особо важно, когда именно происходит компиляция.

Но я могу рассказать об общих принципах, которым мы следовали при разработке Scripted Pipeline. На определенном этапе значительное количество пользователей Jenkins стало сильно сдерживать сложность автоматизации.

Необходимо было обеспечить правильное взаимодействие многих компонентов.

Код компилируется, запускаются тесты, затем нужно дождаться подтверждения развертывания и так далее.

К тому же, уже тогда было желание написать этот процесс в виде кода — примерно тогда Infrastructure as Code стала очень популярной.

Разработчики хотели, чтобы все управлялось через файл в системе управления проектами.

Из этих двух потребностей родился Scripted Pipeline. Однако его использование требовало нетривиальных знаний и было не очень интуитивно понятным, поэтому мы хотели сделать Pipeline более доступным для всех, а не только для тех, кому приходится работать с Scripted Pipeline для реализации сложных оркестровок.

Многие люди хотели ясности, удобства и доступности, а не полноты по Тьюрингу.

Так родился Declarative Pipeline. Кирилл: Сегодня у нас есть, во-первых, плагины Jenkins, которые обычно имеют статический API с аннотациями и метапрограммированием.

Во-вторых, существуют плагины Scripted Pipeline, которые объявляют дополнительные DSL. Декларативный конвейер делает почти то же самое, но у него меньше гибкости.

Что проще поддерживать — плагины для Pipeline или обычный Jenkins? Я имею в виду, со стороны Дженкинса.

Коске: Мне бы не хотелось, чтобы возникла мысль, что речь идет о двух отдельных языках.

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

Freestyle Job, в котором всегда участвовал Дженкинс, изначально был очень хорошо спроектирован.

Если вам нужно было сделать в нем что-то сложное, вы могли бы написать плагин, и Freestyle Job затем заполнял бы пространство между этими плагинами.

Это похоже на шоколадный батончик, который получается, если полить орехи шоколадом.

Я думаю, нам нужно реализовать подобное решение в Pipeline. Мы уже что-то делаем в этом направлении — например, функцию «Общие библиотеки».

Однако очевидно, что нам еще многое предстоит сделать в этой области.

Я давно рассказывал об этом нашей продуктовой команде и разработчикам.

Будем надеяться, что мне удалось на них повлиять.

Кирилл: Мой последний вопрос будет касаться жизненного цикла Jenkins. Важной вехой для проекта стал выпуск Jenkins версии 2. Многие функции и многие API в ней имели уязвимости.

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

С вашей точки зрения, можно ли будет в случае необходимости нарушить совместимость с предыдущими версиями и предыдущими архитектурами? Коске: Для проекта важно, чтобы он продолжал развиваться.

Действительно, по мере вашего роста накапливается определенная сумма технического долга.

Но я не могу согласиться с вашей оценкой сложности Дженкинса.

Речь идет о проекте, который пишут около 800 человек, имеет 1600 плагинов — с учетом этого мне кажется, что он очень доступен.

Ситуация не так критична, как вы ее описываете.

Однако развиваться действительно необходимо.

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

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

Руслан: Будет ли ваша политика обратной совместимости аналогична политике Java? Ведь он обратно совместим с версиями 15-ти, а то и 20-летней давности.

Или это будет что-то вроде ситуации с Python 2 и Python 3, которые до сих пор не работают друг с другом? Готовы ли вы нарушить обратную совместимость, чтобы реализовать важную функцию? Коске: Честно говоря, я не думаю, что справедливо спрашивать, будем ли мы совместимы как Java или как Python. Нам нужно подумать о том, какое программное обеспечение нужно пользователю.

Одна из больших проблем заключается в том, что плагины Jenkins создаются независимо друг от друга, и заставить их работать вместе неоправданно сложно.

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

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

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

Мы больше думаем о создании новой версии, например, Jenkins X. Пока конечный результат соответствует требованиям прямой совместимости, мы больше не думаем об этом вопросе.

Руслан: Отлично, спасибо большое за ответы!

5-6 апреля Коске выступит с докладом на конференции JPoint. «Сверхспособности приходят к твоему Дженкинсу» .
Кроме того, вы сможете пообщаться с ним в зоне обсуждения после доклада.
Вы можете узнать больше о JPoint и приобрести билеты.
официальный сайт конференции (Не забудь об этом первого марта цены на билеты вырастут).

Теги: #Администрирование серверов #Конференции #DevOps #java #jenkins