Для чего изначально придумали jenkins hudson
Hudson, Oracle и Jenkins: что это было?
Цель Oracle — расширить сообщество и сделать Hudson сильнее. Возможно, вы просто не в курсе, но база пользователей Hudson весьма велика, гораздо больше, чем вы можете видеть в списках рассылки или на форумах. Что печально, так это то, как многие из этих пользователей не контрибьютят(ну не знаю, как это по-русски говорят — прим.перев.) к ядру, и не принимают участия в обсуждениях. Они этого хотят, просто им не кажется, что их услышат. А мы хотим, чтобы их слышали. Мы должны сделать сообщество Hudson таким местом, в которое смогут прийти и поучааствовать все, кто захочет. В ближайшие недели мы объявим о некоторых нововведениях, которые должны этому способствовать
Но сейчас мы останемся на java.net. Мы уверены, что для Hudson важно оставаться рядом с остальным сообществом java, как и использовать многие классные фичи, которые скоро появятся на java.net. Использовать GIT можно и на java.net, переезжать для этого на github вовсе не обязательно.
Поскольку проект открытый, мы не можем кому-либо помешать от него форкнуться. Однако, мы владеем торговой маркой, так что вы не можете использовать имя вне основного сообщества. Мы приобрели это вместе с Sun. Мы надеемся, что все, кто сейчас работает над Hudson, сделают именно так, как они утверждают, что хотят, и продолжать работать с нами, делая Hudson сильнее.
(Письмо Теда довольно длинное, целиком его можно почитать тут)
Как и следовало ожидать, ответ Теда встретили со смешанными эмоциями, начиная от непоняток и заканчивая разочарованием.
Найджел Магнэй(Nigel Magnay), контрибьютор плагина Git для Hudson, постарался очень сжато объяснить достоинства Github:
Что вы запретите сообществу разработчиков Hudson?
Т.Е: Вы что, говорите, что будучи владельцами имени Hudson, вы запрещаете сообществу (для себя же) выбрать, на какую инфраструктуру (баг трекер, вики) переезжать? И репозитории тоже выбирать нельзя?
Пока что разработчики активно голосовали за переход на google groups для почты, на github для контроля версий и на собственный сайт для баг трекера и информации.
Ответ Теда содержал одно из самых важных изречений для всего обсуждения: 
Найджел, я лишь хочу сказать, что считаю, что конечное решения насчёт того, что делать относительно инфраструктуры, принадлежит Oracle, и решение нужно принимать основываясь на пожеланиях сообщества.
Какое-то время шло бурление гособытий, а затем, 11 января, Эндрю публично предложил переименовать проект и окончательно переехать с серверов Oracle. Было проведено голосование, в результате которого 214 человек проголосовало за переименование и 14 — за сохранение статус-кво.
29 января зарегистрировали домен jenkins-ci.org и начали переименоввать группы, аккаунт в твиттер, и так далее.
Первоначальное руководство(governance board) будет состоять из Эндрю Байера, Кохсуке и, если Oracle и он сам захотят, Винстона. Если же Винстон не захочет или не сможет, выберут другого человека из сообщества.
Можем ждать дальнейшейго развития событий, хотя большая часть уже позади.
СОДЕРЖАНИЕ
История
Примерно в 2007 году Hudson стал известен как лучшая альтернатива круиз-контролю и другим серверам сборки с открытым исходным кодом. На конференции JavaOne в мае 2008 г. программное обеспечение получило награду Duke’s Choice Award в категории «Решения для разработчиков».
1 февраля 2011 года Oracle заявила, что намерена продолжить разработку Hudson, и считает Jenkins скорее форком, чем переименованием. Таким образом, Дженкинс и Хадсон продолжили свое существование как два независимых проекта, каждый из которых утверждал, что другой является вилкой. По состоянию на июнь 2019 года организация Jenkins на GitHub насчитывала 667 участников проекта и около 2200 общедоступных репозиториев по сравнению с 28 участниками проекта Hudson и 20 общедоступными репозиториями с последним обновлением в 2016 году.
В 2011 году создатель Косуке Кавагути получил премию O’Reilly Open Source Award за свою работу над проектом Хадсона / Дженкинса.
Дженкинс заменил Хадсона с 8 февраля 2017 года в Eclipse.
В марте 2018 года был публично представлен проект программного обеспечения Jenkins X для Kubernetes с поддержкой различных облачных провайдеров, в том числе AWS EKS.
Строит
Сборки можно запускать разными способами, например:
Плагины
Почтовая программа
Позволяет настроить уведомления по электронной почте о результатах сборки. Jenkins будет отправлять электронные письма указанным получателям всякий раз, когда происходит определенное важное событие, например:
Реквизиты для входа
Позволяет хранить учетные данные в Jenkins. Предоставляет стандартизированный API для других плагинов для хранения и получения различных типов учетных данных.
Мониторинг внешних вакансий
Добавляет возможность отслеживать результат выполняемых извне заданий.
Агенты SSH
Этот плагин позволяет управлять агентами (ранее называвшимися подчиненными), работающими на машинах * nix через SSH. Он добавляет новый тип метода запуска агента. Этот метод запуска будет
Javadoc
Этот плагин добавляет поддержку Javadoc в Jenkins. Раньше эта функция была частью ядра, но в Jenkins 1.431 она была разделена на отдельные плагины.
Плагин позволяет выбрать «Опубликовать Javadoc» в качестве действия после сборки, указав каталог, в котором будет собираться Javadoc, и если ожидается сохранение для каждой успешной сборки.
Онлайн-объяснение
Jenkins можно использовать для планирования и мониторинга запуска сценария оболочки через пользовательский интерфейс вместо командной строки.
Безопасность
Безопасность Jenkins зависит от двух факторов: контроля доступа и защиты от внешних угроз. Контроль доступа можно настроить двумя способами: аутентификация пользователя и авторизация. Также поддерживается защита от внешних угроз, таких как атаки CSRF и вредоносные сборки.
Jenkins CI — вещи, которых мне не хватало
Этапы постановки задачи
И так, первоначальной задачей была научить систему просто запускать web-сервера, отслеживать изменения в репозиториях и запускать jUnit, TestNG и Selenium тесты. Со временем эта задача обросла кучей мелочей, о которых будет рассказано позже. Вроде бы не сложно, но, как оказалось, первое мнение бывает ошибочным. С чистой совестью я установил centos 6 x64 на предоставленную мне виртуальную машину, и несколькими движениями установил CI:
Естественно нужно не забыть установить jdk и проверить, добавился ли jenkins в автозагрузку. Примерно так, произошел мой первый неудачный запуск Jenkins CI — ajp порты Jenkins’a конфликтовали с одним из ранее установленных веб серверов(по совместительству нереляционной БД). После отключения ajp в конфигурационном файле все стало на свои места, и наконец-то я смог увидеть все чудеса воочию.
Ошибки
Первые попытки
Формально мы ждем пока сервер запустится, запускаем на нем юнит тесты, и выключаем сервер по завершению тестов. Собственно что и требовалось. Мне кажется, что средствами Jenkins одним проектом, подобное сделать невозможно.
Branches
На мой взгляд в Дженкинсе плохо реализована поддержка бренчевания. «svn://svn.adress:port/$
Вывод: иногда все же стоит создать на один проект больше, чем писать очередной велосипед.
Так же к проблеме бренчевания я бы отнес Build Name Setter Plugin. Довольно приятно вместо номера сборки видеть имя бренча, но и тут все не так просто. Т.к. не у всех переменных есть атрибут length(например у переменных среды), с помощью которого можно обрезать максимальную длину строки. Согласитесь, подобный вид не очень мотивирует, а что если длина будет не 30, а 255 символов? 
Эту проблему опять же можно решить с preBuild groovy script. Но в моей ситуации было проще попросить делать названия бренчей информативными и не очень длинными. Очень удобно, когда какие-то неудобства решаются не велосипедами, а здравым смыслом.
Велосипеды
Все мы люди, и все хотим какого-то комфорта. Писать свой плагин мне не хотелось, на компромиссы идти было не с кем, а добиться результата — хотелось. По этому здесь я опишу, все те велосипеды, которые каким-либо образом мне облегчили жизнь.
Т.к. у меня были проекты, которые можно было завершить только по нажатию крестика(что означает «отмена сборки»), меня очень сильно угнетали серые шарики, по этому мне захотелось сделать сборку успешной(пусть не портит статистику, я же знаю, что все правильно). Plugin’a реализующего это я не нашел, зато нашел Groovy Postbuild Plugin, который я активно пиарил и антипиарил выше. Так вот, groovy postbuild API (назовем его так), предлагает метод buildSuccess(), для задания успешного состояния сборки, и подобные для других состояний. Проблема в том, что данный метод ничего не делает. Все семейство может только ухудшить текущее состояние сборки, а т.к. Aborted намного хуже чем Success, то состояние сборки не менялось. В свое время на Jenkins’e я нашел три issue с просьбой реализации полноценного функционала изменения статуса сборок. Представленный выше кусок кода, настолько прост, что он просто не мог уложиться мне в голову. Задав себе вопрос: «а может быть у groovy реализован аналог reflections?» решение проблемы пришло моментально. Надеюсь любители извращений изысков оценят.
Build promotion. Да, я знаю про существование Promoted Builds Plugin’a, но в моем случае он опять же не помог. Был один сервер, который обновлялся только руками и поднимал прописываемый в ручную бренч, и был проект, который запускался раз в 2 часа, узнавал гитовую ветку первого проекта, скачивал ее и запускал юнит тесты. Количество сборок в проектах было разное. По договоренности было решено давать звезду, если последние юнит тесты были успешны. При чем звезда присваивается только по завершению работы первого сервера. Согласитесь, довольно необычная реализация promoted plugin заточенная чисто под личные нужды:
Борьба с ручным тестированием
Так уж сложилось, что тестеры бывают разные. И очень обидно, когда они скорее всего знают, почему что-то работает не так, но заблаговременно пытаются спихнуть ответственность, аргументируя «я все делал(а) хорошо, а оно сломалось, ты виноват, ты чини». Именно для таких случаев очень хорошо помогает AnsiColor Plugin. Если и это не подействует, то настоятельно рекомендую воспользоваться более обидными мерами: Build User Vars Plugin — личное обращение делает ваши действия более постыдными(откуда вообще машина узнала как меня зовут?). Главное не переусердствовать, возможна ситуация, когда скрипт некорректно работает, а тестеры боялись 3 дня спросить, ибо им в консоли писалось: «а ты точно все сделал правильно?». В этом случае все камни полетят в вас. Никто не любит выглядеть дураком. Но если накосчячил — получай что-то подобное(! красный цвет использовать обязательно): 
Jenkins Pipeline: заметки об оптимизации. Часть 1
Меня зовут Илья Гуляев, я занимаюсь автоматизацией тестирования в команде Post Deployment Verification в компании DINS.
В DINS мы используем Jenkins во многих процессах: от сборки билдов до запуска деплоев и автотестов. В моей команде мы используем Jenkins в качестве платформы для единообразного запуска смоук-проверок после деплоя каждого нашего сервиса от девелоперских окружений до продакшена.
Год назад другие команды решили использовать наши пайплайны не только для проверки одного сервиса после его обновления, но и проверять состояние всего окружения перед запуском больших пачек тестов. Нагрузка на нашу платформу возросла в десятки раз, и Jenkins перестал справляться с поставленной задачей и стал просто падать. Мы быстро поняли, что добавление ресурсов и тюнинг сборщика мусора могут лишь отсрочить проблему, но не решат ее полностью. Поэтому мы решили найти узкие места Jenkins и оптимизировать их.
В этой статье я расскажу, как работает Jenkins Pipeline, и поделюсь своими находками, которые, возможно, помогут вам сделать пайплайны быстрее. Материал будет полезен инженерам, которые уже работали с Jenkins, и хотят познакомиться с инструментом ближе.
Что за зверь Jenkins Pipeline
Jenkins Pipeline — мощный инструмент, который позволяет автоматизировать различные процессы. Jenkins Pipeline представляет собой набор плагинов, которые позволяют описывать действия в виде Groovy DSL, и является преемником плагина Build Flow.
Скрипт для плагина Build Flow исполнялся напрямую на мастере в отдельном Java-потоке, который выполнял Groovy-код без барьеров, препятствующих доступу к внутреннему API Jenkins. Данный подход представлял угрозу безопасности, что впоследствии стало одной из причин отказа от Build Flow, и послужило предпосылкой для создания безопасного и масштабируемого инструмента для запуска скриптов — Jenkins Pipeline.
Подробнее об истории создания Jenkins Pipeline можно узнать из статьи автора Build Flow или доклада Олега Ненашева о Groovy DSL в Jenkins.
Как работает Jenkins Pipeline
Теперь разберемся, как работают пайплайны изнутри. Обычно говорят, что Jenkins Pipeline — совершенно другой вид заданий в Jenkins, непохожий на старые добрые freestyle-джобы, которые можно накликать в веб-интерфейсе. С точки зрения пользователя это, может, и выглядит так, но со стороны Jenkins пайплайны — набор плагинов, которые позволяют перенести описание действий в код.
Сходства Pipeline и Freestyle джобы
Правда в том, что параметры, описанные в Pipeline, автоматически добавятся в раздел настройки в веб-интерфейсе при запуске джобы. Верить мне можно потому, что этот функционал в последней редакции писал я, но об этом подробнее во второй части статьи.
Отличия Pipeline и Freestyle джобы
Запуск Jenkins Declarative Pipeline
Процесс запуска Jenkins Pipeline состоит из следующих шагов:
При старте pipeline-джобы Jenkins создает отдельный поток и направляет задание в очередь на выполнение, а после загрузки скрипта определяет, какой агент нужен для выполнения задачи.
Для поддержки данного подхода используется специальный пул потоков Jenkins (легковесных исполнителей). Можно заметить, что они выполняются на мастере, но не затрагивают обычный пул исполнителей:
Количество потоков в данном пуле не ограничено (на момент написания статьи).
Работа параметров в Pipeline. А также триггеров и некоторых опций
Обработку параметров можно описать формулой:
Из параметров джобы, которые мы видим при запуске, сначала удаляются параметры Pipeline из предыдущего запуска, а уже потом добавляются параметры заданные в Pipeline текущего запуска. Это позволяет удалить параметры из джобы, если они были удалены из Pipeline.
Непрерывная интеграция на примере Hudson
Все мы прекрасно понимаем, что тестирование является неотъемлемой частью жизненного цикла разработки ПО. Чем чаще мы тестируем наш код, тем быстрее мы сможем обнаружить ошибку, вкравшуюся в него в ходе разработки, и быстрее её исправить. При этом стоит понимать, что тестирование крайне желательно проводить в окружении, максимально близком к боевому (ОС, ПО, Hardware, Нагрузка), что бы иметь возможность обнаружить ошибки, которые не проявляются на сервере разработки, но могут появиться в бою. Компануя два вышесказанных тезиса вместе мы получаем концепцию, называемую Continuous Integration.
Для автоматизации процесса непрерывной сборки существуют готовые решения (Hudson, CruiseControl), интеграцию одного из которых (Hudson) я и опишу в этой статье.
Задача
И так, допустим у нас есть два проекта: Java-сервис (со своей БД), и PHP-клиент (со своей БД) для него. Оба проекта распространяются в виде deb-пакетов. Необходимо настроить инфраструктуру непрерывной интеграции этих проектов.
Реализация
Для того, что бы иметь представление о том, чего же мы хотим в итоге добиться — начнём с конца: рассмотрим схему, которую мы хотим реализовать:
Для проектов без web-интерфейса запускаются интеграционные тесты, для проектов с web-интерфейсом запускаются тесты Selenium. Сервер CI формирует отчёты и при необходимости (в случае провала на любом из этапов сборки проекта) отправляет email-уведомление пользователю.
Выкладка пакетов проекта в репозитарий для боевых серверов производится разработчиком вручную во время релиза.
Hudson
Главным и самым интересным узлом в нашей системе является сервер CI. В данном случае это будет Hudson как одно из самых популярных и распространённых бесплатных решений.
Первым делом установим его. Hudson доступен в виде пакета, поэтому его установка довольно проста. Кроме того, всю свою конфигурацию Hudson хранит в файлах (/var/lib/hudson), в виду чего не требует интеграции с какой-либо БД.
Обратите внимание, что некоторые плагины требуют запуска Hudson под Java 6. Изменить путь к JVM (ровно как и остальные конфигурационные опции) можно в файле /etc/default/hudson. В остальном все конфигурационные параметры касающиеся непосредственно работы Hudson могут быть отредактированы через браузер в web-интерфейсе.
Относительно настроек плагинов стоит также упомянуть, что плагин имеет как общие настройки («Настройка / Конфигурирование системы»), так и настройки проекта («Настройка / Имя проекта / Настроить проект»).
Теперь, когда все необходимые плагины установлены, мы можем создать новый проект/задачу, указав его имя и настройки для соответствующих плагинов: URL в репозитарии SVN и команду для сборки.
Обратите внимание, что вы можете производить сборку не по какому-то расписанию или при опросе репозитария при наличии изменений в проекте, а по коммиту в SVN. Благодаря тому, что Hudson имеет «Remote Access API», позволяющее кроме прочего инициировать сборку проекта, сделав GET-запрос, вы можете легко добавить соответствующий post-commit hook (например, с помощью svnlook) для вашего проекта.
Рассмотрим этап сборки:
На данный момент сборка пакета включает в себя получение данных из репозитария и выполнение цели Phing (сборка пакета). В принципе сюда же можно добавить запуск unit-тестов и deploy проекта на staging-сервер. Однако, тут стоит обратить внимание на несколько моментов.
Во-первых, конфиг для работы приложения на staging-сервере может отличаться от боевого конфига. В этом случае очевидным решением будет хранение в проекте конфига для staging-сервера и подмене им оригинального проекта при сборке (отдельная цель для сборки в случае Phing или профиль для Maven).
Во-вторых установить пакет на staging-сервер с помощью плагинов SCP и SSH (для работы плагина необходимо убедится, что параметр PasswordAuthentication в конфиге sshd выставлен в yes, а хост staging-сервера добавлен в known-хостов) не получится, так как плагин SSH относится этапу сборки проекта, а plugin SCP — к послесборочным операциям. Поэтому проблему deployment’a проекта на staging-сервер придётся решать с помощью Phing или Maven + AntRun.
Для того, что бы наш сценарий сборки мог производить действия на удалённых серверах необходимо сгенерировать ssh-ключи: приватный ключ оставить на сервере CI, a публичный раскидать по всем серверам, с которыми будет происходить взаимодействие: staging, repo, svn — добавив их в список известных хостов (known_hosts). Кроме того, для того, что бы Hudson смог установить пакет на удалённом сервере потребуется завести на удалённом сервере соответствующего пользователя (hudson) и дать ему sudo.
В-третьих, для успешной сборки java-приложений с помощью Maven потребуется определить настройки Maven для пользователя hudson на сервере CI (имеется ввиду каталог
Следующим шагом после установки пакета на staging-сервер должен стать запуск интеграционных тестов. Они могут быть запущены на самом сервере CI, однако, предпочтительнее сделать это на staging-сервере. В первом случае всё довольно просто: вызываем соответствующую цель Phing / Maven или настраиваем плагин SeleniumHQ.
Однако, открытым остаётся вопрос, что же делать, если требуется запустить процесс тестирования на внешнем сервере — например, обратиться к серверу Selenium RC? Ответ тут как нельзя прост: Selenium RC имеет HTTP API для работы с ним, поэтому самым тривиальным решением в данном случае будет написание небольшого скрипта на любом угодном вам языке, который инициирует процесс тестирования и время от времени опрашивает удалённый сервер на предмет завершения теста. Далее этот скрипт подключается к сценарию сборки через плагин ”Execute Shell”. Добавлю ещё, что успех или неуспех работы скрипта определяется Hudson’ом на основе кода возврата вашего скрипта.
Настроив процесс сборки не забудем о самой важной части процесса — уведомлении разработчика о результатах сборки. Hudson позволяет настроить почтовые уведомления как для конкретных получателей, так и для авторов commit’ов, чьи изменения вызвали поломку.
В дополнение рекомендую всем, кто будет использовать Hudson для PHP-проектов ознакомиться с соответствующими статьями из Wiki Hudson’а.
Сервер Staging
Установка пакетов
Кроме того, между устанавливаемыми на staging-сервер пакетами возможны зависимости. Так, например, проект «клиент» зависит от проекта «сервер». В этом случае мы должны явно следить за тем, что бы на staging-сервере при установке пакета «клиент» происходила установка необходимого ему пакета «сервер».
Однако, данный подход имеет ряд недостатков. Во-первых, зависимости могут быть установлены только на этот же сервер. Во-вторых, такой подход довольно значительно усложняет всю систему в целом, что противоречит принципу KISS (ну или «ЧМОКЕ», если по-русски :D).
Лучшим решением, на мой взгляд, тут будет использовать репозитарий только для взаимодействия с боевым сервером. При этом выкладка пакетов в репозитарий должна осуществляться не автоматически, а по решению разработчика. Что же касается staging-сервера — на нём будут устанавливаться пакеты из trunk’ов основного пакета и всех его зависимостей, что позволит значительной снизить сложность системы CI, при этом дав нам возможность иметь на staging-сервере последние актуальные версии
пакетов.
Работа с БД
Отдельно в данном случае встаёт вопрос об изменениях данных БД в ходе тестирования. Понятно, при написании модульных тестов мы не работаем с БД, а используем mock-объекты (мне, например, нравится Mockito).
Однако, как быть с интеграционными тестами, которым просто необходимо работать в «реальных» условиях? В случае XUnit-тестов мы можем выполнять каждый тест в рамках транзакции к БД. Такой подход на мой взгляд является более предпочтительным, так как с учётом версионирования БД через dbdeploy мы всегда знаем, какие данные у нас есть в БД на текущий момент и можем смело привязываться к ним в наших тестах. Однако, в случае тестирования web-интерфейса (например, с помощью Selenium) у нас нет возможности запускать каждый тест в рамках транзакции.
Поэтому вариантов тут на мой взгляд остаётся два: либо перед запуском тестирования web-интерфейса полностью переинициализировать данные в БД на основе имеющихся
патчей, либо строить тесты так, что бы они не привязывались к каким-то конкретным данным из БД (например, создавали необходимые для тестирования данные через web-интерфейс сами) и по возможности не оставляли после себя «мусора».
Cервер Selenium
В случае, когда приложение не имеет web-интерфейса, интеграционный тест на staging-сервере, как я уже писал выше, вполне может заключаться в запуске XUnit-тестов. Однако, при наличии пользовательского интерфейса крайне удобно провести полное тестирование всей цепочки от HTML до БД с помощью Selenuim’a.
Замечания
Стоит заметить, что CI можно проводить и в ручном режиме, каждый раз компилируя и тестируя код перед commit’ом. Однако, автоматизация данного процесса с помощью сервера CI на много целесообразней. Кроме того важно понимать, что CI и ночные сборки (nightly builds) — не одно и тоже. Последние позволяют выявить баги, но с большим запозданием, в то время как цель CI — скорейшее обнаружение ошибок. На мой взгляд ночные сборки могут послужить частичной заменой CI только в том, случае когда сборка и тестирование проекта — процесс, занимающей довольное большое количество времени. Кроме того, если в проекте есть как unit, так и интеграционные тесты, можно разбить сборку проекта на две части: первая (с unit-тестами) запускается каждый раз при commit’e, вторая с интеграционными тестами — раз в час/сутки.
Вывод
Описанное выше решение работает и приносит профит. Однако, как мы все знаем, теория, к сожалению, далеко не всегда соответствует практике. Внедрение системы CI потребовало решения ряда проблем, не все из которых были решены идеально.
Вероятность того, что для staging-сервера кто-то даст вам ресурсы, сравнимые про характеристикам с боевыми, крайне мала — скорее всего это будет средней мощности виртуальник на полузаброшенной хост-машине, что в корне подрывает один из принципов CI — тестирование в схожем окружении. Это в свою очередь влечёт за собой то, что интеграционные тесты, могут начать занимать гораздо большее время, чем планировалось изначально. Поэтому «непрерывностью» в моём случае пришлось поступиться и начать запускать тесты не по hook’ам SVN, а по расписанию.
В целом же при наличии в вашей команде некоторой культуры разработки (я имею в виду понимание того, что CI — не панацея, а лишь инструмент, который при должном умении обращения с ним может улучшить качество их работы) внедрение CI вполне оправдано.
Ну и наверное самое главное: как показала практика, интеграция системы CI — задача командная. Для её решения потребуется работа разработчиков, тестировщиков и администраторов.