Хабрахабр

Большое интервью с создателем Jenkins, Kohsuke Kawaguchi

Скорей всего да, потому что это самый популярный на сегодняшний день проект этого класса. Пользуетесь ли вы Jenkins? Здесь же у нас не просто разработчик, а сам создатель Jenkins — Коске Кавагучи (Kohsuke Kawaguchi). Мне всегда интересно было пообщаться с кем-нибудь из разработчиков и задать пару жестких вопросов.

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

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

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

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

Имею богатый опыт использования Jenkins, особенно Scripted/Declarative Pipeline. Кирилл: Тоже представлюсь — я разработчик и также организую Moscow Jenkins Area Meetup (JAM). Можете рассказать, чем занимается CTO компании, развивающей Jenkins?

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

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

Кирилл: Если я правильно вас понял, то ваш фокус переключился с технических вопросов к работе с сообществом?

Есть вещи, которые может сказать только основатель компании. Коске: Да, многое из того, что я делаю, связано с этим. Кроме того, мы вместе с командой занимаемся пропагандой Jenkins: объясняем, какие у нас цели, какие трудности мы пытаемся преодолеть. Поэтому часть моей деятельности — условно говоря, размахивать флагом и призывать сообщество в определённом направлении, когда бывает необходима смена курса., как это, например, было в прошлом году. Так вкратце выглядит моя деятельность. Помимо этого, когда надо сделать выступление об общем положении дел, я вызываю больше доверия.

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

Но постепенно проект рос. Коске: Проект появился в 2004 году, и поначалу я занимался им вечерами и по выходным, то есть это было своего рода хобби. Со временем возникла экосистема и сообщество разработчиков, некоторые из которых были из России — например, Олег Ненашев (Twitter: @oleg_nenashev), написавший очень интересную подсистему поверх Jenkins. Я потратил довольно много времени на создание этой платформы, на которой другие люди могли бы писать свои приложения. Поэтому я стал больше заниматься этими вещами. По мере того, как проект набирал популярность, более острой становилась необходимость в улучшении взаимодействия с пользователями и обучении их. С этого момента к работе с сообществом добавилась работа по организации компании. Наконец, где-то в 2010 году Jenkins стал настолько популярен, что я решил посвятить ему всё своё время и создал компанию. И в компании, и в сообществе очень много способных людей, которые с радостью готовы взять на себя дополнительную ответственность. Компания росла, и я начал задавать себе вопрос — какую деятельность не может выполнять никто, кроме меня? Так, в общем и целом, выглядел наш путь. Постепенно они стали делать многое из того, что я раньше делал сам.

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

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

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

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

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

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

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

Я сейчас больше интересуюсь тем, как работает организация — думаю, это из-за моей функции в ней. Коске: Ну, говорить с утра до вечера будет сложно. Сейчас я так уже не мыслю, поэтому мне сложно ответить на ваш вопрос. Когда я работал в одиночку, моё внимание значительно в большей степени принадлежало отдельным фичам.

Кирилл: Тогда, возможно, вы помните какую-нибудь фичу, которую реализовали годы назад и которой были очень горды?

Это проект прошлого года, Jenkins Configuration as Code. Коске: Я могу рассказать об одной из недавних значимых фич, над которыми мы работали — думаю, пользователям это будет более интересно. Нужда в проекте Configuration as Code чувствовалась давно, и было написано много временных костылей для выполнения этой функции. Мы видели, что наши пользователи постепенно переходили от управления Jenkins щелчками мыши в GUI к настройке посредством файла конфигурации в git-репозитории. Наконец, нам удалось собрать вместе тех людей из сообщества, которые были заинтересованы в этом новом проекте, и создать достаточно крупный и продуманный инструмент. Но ни одно из этих начинаний не было достаточно масштабным. Многие аспекты этого проекта получились очень хорошо, и он обрёл достаточно широкую популярность, что не может не радовать.

Он был создан специально для работы с Kubernetes. Можно вспомнить и другой проект, Jenkins X, который представляет из себя эволюцию в совершенно другом направлении. В итоге мы позволяем с лёгкостью реализовывать лучшие, на наш взгляд, практики. Благодаря этой специализации мы можем добиться гладкой интеграции и скрыть сложность, возникающую из-за интеграции и из-за подключения процессов непрерывной доставки. Я думаю, что благодаря этому проекту Jenkins станет доступен большому количеству людей, которые выполняют вполне стандартные действия и не хотят тратить много времени на конфигурацию, которым нужно, чтобы всё просто заработало.

Руслан: Пользуетесь ли вы Jenkins, когда пишете Jenkins?

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

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

Иметь универсальную платформу, безусловно, очень важно. Коске: Думаю, здесь многое зависит от реакции сообщества. Сегодня пользователи, как правило, имеют прямой доступ к ней. Вопрос в том, кто именно реализует эту гибкость. Но при этом я знаю много людей, которым такая гибкость не нужна. Это удобно, если вы крупная компания и делаете нечто необычное. Вам предлагают на выбор семь видов хлеба, пять видов масла, четыре вида сыра, и вам нужно определиться со всеми ингредиентами. Представьте, что вы пришли в столовую и попросили, чтобы вам сделали бутерброд. Я знаю, что многие именно так относятся к Jenkins и хотят, чтобы вся гибкость осталась на нашей стороне. Но вам не нужен весь этот выбор, вам просто нужен вкусный бутерброд, и вы не хотите разбираться в том, как его правильно сделать. Если этот проект будет продолжать пользоваться успехом, я с радостью попробовал бы сделать нечто подобное для встроенного ПО и IoT, мобильных платформ или машинного обучения. Jenkins X — первый серьёзный шаг в этом направлении. Вы из России, так что, скорее всего, знаете про JetBrains? Думаю, есть много вертикальных рынков, на которых людям просто нужен инструмент, который позволит быстрее довести продукт до продакшна.

Кирилл: Конечно.

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

Проблема в том, что люди пытаются для всех случаев использовать один универсальный инструмент, который зачастую не подходит для конкретного случая. Кирилл: В течение многих лет я наблюдаю одну и ту же картину во многих сообществах, когда советую использовать те или иные плагины — кстати, сейчас мне сильно помогает https://plugins.jenkins.io, там лежат все одобренные плагины. Но возникает новая проблема. Поэтому теперь я обычно рекомендую только один инструмент — Pipeline, это идеальный инструмент, который подходит во всех ситуациях. Возникают неполадки с инфраструктурой, с установлением соответствия между узлами, расшариванием данных, появляется необычный трафик между агентом и мастером или проблемы с масштабированием на мастере. Люди пытаются использовать Scripted Pipeline или Declarative Pipeline, не понимая, как они устроены внутри. Или инструмент вроде Scripted Pipeline, который спрашивает вас, что именно вы имели в виду? Какой инструмент, с вашей точки зрения, лучше: тот, который указывает единственно правильный путь решения проблемы, наподобие Jenkins X?

В японском языке есть слово «ката», я не знаю, как точно его перевести. Коске: Не уверен, что правильно вас понял, но попробую ответить. Речь идёт о строго определённых движениях, которые разучивают ученики: например, поднимать руку определённым образом, чтобы отклонить определённый удар. Оно используется, помимо прочего, в дзюдо. Задача в том, чтобы заучить набор простых движений, своего рода шаблонов или лучших практик. Я немного занимался этим, поэтому знаю самые простые из них. Зная эту базу, вы дальше можете правильно от неё уходить, если этого требует ситуация, при этом не нарушая самих базовых движений. Но это только начало. Если вы её не знаете, вы будете всё время спрашивать себя — правильно ли я поступаю? Вы изучаете своё собственное пространство, свою территорию, но при этом знание общей базы вам всё равно помогает. Даже если то, что вы написали, работает, у вас всё равно будут сомнения.

Мне кажется, с Jenkins у нас похожая ситуация. В общем, ваш вопрос напомнил мне о ката. Конечно, в Jenkins X приходится жертвовать гибкостью ради того, чтобы обеспечить лучшее взаимодействие с Kubernetes. Jenkins X предоставляет базу, а по мере того, как вы начинаете глубже в ней разбираться, вы можете при необходимости уходить от неё при помощи плагинов и прочего. По большому счёту, это верно по отношению к любому софту. Но тот факт, что Jenkins X подталкивает вас к лучшим практикам, не значит, что вас лишают выбора. Раньше мы создавали только ключевые элементы системы — платформу и плагины, собрать их уже было дело пользователя. Просто с Jenkins X у нас произошла важная смена образа мышления. С Jenkins X сообщество перешло к новому подходу, и, на мой взгляд, это очень важный шаг.

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

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

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

CloudBees — просто крупнейший участник Jenkins, многие сотрудники CloudBees параллельно работают в сообществе. Коске: Тут есть достаточно интересный момент: CloudBees не является владельцем Jenkins, это два отдельных проекта, каждый со своей структурой принятия решений. С этой целью мы создали Jenkins Enhancement Process… Последние несколько лет мы пытаемся создать более ясные управляющие структуры в Jenkins, которые занимались бы ровно тем, о чём вы сейчас спросили.

Кирилл: Извините, что перебиваю — он сокращается как JEP, так же, как и в Java?

Очевидно, мы не изобрели эту концепцию, а заимствовали у Python, Java и некоторых других сообществ, потому что там она себя уже зарекомендовала. Коске: Абсолютно верно. Именно так мы и делаем, когда CloudBees собирается создать новую фичу, поэтому у нас есть возможность изменить курс в зависимости от получаемого отклика. Основная мысль здесь в том, что сообщество должно иметь возможность высказать своё мнение и прийти к консенсусу прежде, чем начнётся крупная работа над некоторой фичей. Поскольку мы являемся опенсорсным проектом, мы не можем напрямую указать другим участникам проекта, что им делать. Это — тот элемент планирования, который нам удалось внедрить в нашу работу. Иногда к нашему голосу прислушиваются, иногда нет.

Jenkins X. Что касается наших планов на ближайшие полгода, то, скорее всего, мы будем продолжать работать над многими из наших текущих начинаний, в т.ч. Я надеюсь, что Configuration as Code станет более популярным среди разработчиков плагинов. Над ним работают некоторые сотрудники CloudBees и многие сторонние участники. Наконец, если возникнут новые JEP, будем работать над ними. По большому счёту, мы уже создали основание для неё, так что теперь нужно настроить некоторые плагины, чтобы они могли быть правильно подключены через эту систему.

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

Дело в том, что многие начинания в сообществе зачастую не доходят до критической массы и остаются на уровне эксперимента. Коске: Это интересный вопрос. Так что мы не были, собственно, изобретателями Pipeline. До того, как мы начали работать над Pipeline, в том же пространстве люди уже пытались сделать нечто подобное, и у нас была возможность познакомиться с этими попытками. Думаю, термин «экосистема» очень удачный — всё действительно происходит так, как в настоящей экосистеме, созданная кем-либо технология постоянно эволюционирует и изменяется. Одним из таких предшественников был плагин Build Flow, его написал один из сотрудников CloudBees до того, как пришёл в компанию.

Руслан: А повлияли ли вы на реализацию Scripted Pipeline?

Коске: Да, на её первоначальную версию.

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

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

Например, с DSL в Java необходимо заранее знать все API и интерфейсы. Кирилл: При статическом DSL у нас есть некоторая уверенность в нашем коде до исполнения. Даже если код недопустим, машина всё равно попытается его выполнить, просто она выбросит ошибку в случае необходимости. При динамическом подходе мы осуществляем проверку уже непосредственно при выполнении. Декларативная версия пайплайна позволяет исключить многие ошибки за счёт сужения вариативности в скрипте сборки.

Но я могу рассказать об общих установках, которых мы придерживались при проектировании Scripted Pipeline. Коске: Если честно, мне не особо важно, когда именно происходит компиляция. Нужно было обеспечить правильное взаимодействие множества компонентов. На определённом этапе значительному числу пользователей Jenkins стала сильно мешать сложность автоматизации. Кроме того, уже тогда появилось желание писать этот процесс в виде кода — примерно тогда большую популярность имела Infrastructure as Code. Код компилируется, запускаются тесты, затем нужно ждать, пока будет подтверждён деплоймент и так далее. Из этих двух потребностей и родилась Scripted Pipeline. Разработчики хотели, чтобы всем можно было управлять через файл в системе управления проектом. Многим нужны были ясность, удобство и доступность, а не полнота по Тьюрингу. Однако его использование требовало нетривиальных знаний и не отличалось интуитивностью, поэтому мы хотели сделать более доступный Pipeline для всех, а не только для тех, кто вынужден работать со Scripted Pipeline, чтобы реализовывать сложные оркестрации. Так возникла Declarative Pipeline.

Во-вторых, есть плагины Scripted Pipeline, которые объявляют дополнительные DSL. Кирилл: Сегодня у нас есть, во-первых, плагины Jenkins, у которых обычно статический API с аннотациями и метапрограммированием. Что проще поддерживать — плагины для Pipeline или для обычного Jenkins? Declarative Pipeline делает примерно то же, просто там меньше гибкости. Я имею в виду, со стороны Jenkins.

Мне кажется, что пока что нам не удалось найти язык для Pipeline, который одновременно был бы удобным для выполнения простых задач, доступным для новых пользователей, но при этом обладал бы большой гибкостью. Коске: Я не хотел бы, чтобы возникло представление, будто бы речь идёт о двух отдельных языках. Если в ней нужно было сделать что-либо сложное, можно было написать плагин, и Freestyle Job затем заполняла пространство между этими плагинами. Freestyle Job, на которой всегда стоял Jenkins, была изначально очень удачно спроектирована. Думаю, в Pipeline нам нужно применить похожее решение. Это как батончик, который получается, если залить орехи шоколадом. И всё же очевидно, что нам ещё предстоит многое сделать в этой области. Мы уже делаем кое-что в этом направлении — например, фича Shared Libraries. Будем надеяться, что мне удалось на них повлиять. Я давно уже говорю об этом нашей продуктовой команде и разработчикам.

Важной вехой для проекта был выход версии Jenkins 2. Кирилл: Мой последний вопрос будет касаться жизненного цикла Jenkins. Если сейчас взглянуть на исходный код Jenkins и его плагинов, то перед нами предстанет очень сложная архитектура, со значительным количеством проблем, разобраться в которой крайне тяжело, если человек сам не был частью истории проекта. Многие фичи и многие API в нём имели уязвимости. С вашей точки зрения, можно ли будет нарушить совместимость с предыдущими версиями и предыдущими архитектурными решениями, если в этом будет необходимость?

Действительно, по мере роста накапливается определённый технический долг. Коске: Для проекта важно, чтобы он продолжал развиваться. Речь идёт о проекте, который пишет около 800 человек, в нём 1600 плагинов — с учётом этого, мне кажется, он очень доступен. Но я не могу согласиться с вашей оценкой сложности Jenkins. Тем не менее, развиваться действительно необходимо. Ситуация не настолько критическая, насколько вы её описываете. Я надеюсь, что в сообществе эта тема ещё будет обсуждаться, но пока что слышно не слишком много. В прошлом году я написал пост с заголовком «Смена передачи», в котором я, образно говоря, размахивал флагом и призывал пересмотреть некоторые из наших первоначальных обещаний пользователям, в том числе относительно строгого соблюдения обратной совместимости за исключением случаев, связанных с безопасностью.

Ведь у неё обратная совместимость с версиями 15-летней, а то и 20-летней давности. Руслан: Будет ли ваша политика обратной совместимости похожа на ту, которой придерживается Java? Готовы ли вы нарушить обратную совместимость для реализации важной фичи? Или будет нечто больше похожее на ситуацию с Python 2 и Python 3, которые до сих пор друг с другом не работают?

Надо думать о том, какого рода софт нужен пользователю. Коске: Честно говоря, мне не кажется, что правильно ставить вопрос о том, будем ли мы соблюдать совместимость как Java или как Python. Если при решении этой проблемы мы сломаем инстансы у пользователей, то такое решение никому не нужно. Одна из серьёзных проблем заключается в том, что плагины для Jenkins создаются независимо друг от друга, и заставить их работать вместе неоправданно сложно. Думаю, у нас в этом отношении больше гибкости, чем у разработчиков языков, мы не обещаем настолько же жёстко придерживаться совместимости. А если в результате мы получим систему, которая работает лучше и быстрее, то некоторые нарушения совместимости могут быть оправданы. До тех пор, пока конечный результат отвечает требованиям прямой совместимости, мы больше об этом вопросе не задумываемся. Мы больше думаем о том, чтобы создать новую версию, например, Jenkins X.

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

Кроме того, можно будет пообщаться с ним в дискуссионной зоне после доклада. 5-6 апреля Коске выступит на конференции JPoint с докладом «Superpowers coming to your Jenkins». Узнать подробней о JPoint и приобрести билеты можно официальном сайте конференции (не забывайте, что первого марта цены на билеты вырастут).

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть