27 июля 2017 года прошла совместная встреча сообществ jug.msk.ru и Jenkins MSK. На встрече с докладами о Jenkins выступили Олег Ненашев («Groovy DSL в Jenkins и Pipeline. Как оно работает?») и Кирилл Толкачёв с Александром Тарасовым («DSL много не бывает. Мигрируем со Scripted Pipeline на Declarative (Live)»).
Рубрика «Jenkins» - 5
Олег Ненашев, Кирилл Толкачёв и Александр Тарасов про Groovy DSL и Pipeline в Jenkins на jug.msk.ru
2017-08-01 в 21:46, admin, рубрики: groovy, Groovy & Grails, java, Jenkins, JUG, jug.msk.ru, pipeline, Блог компании JUG.ru Group
Релизный цикл для Infrastructure as Code
2017-07-22 в 21:00, admin, рубрики: devops, Jenkins, kitchen-ci, linux, saltstack, serverspec, sonatype nexusНа просторах интернета можно встретить немало статей на тему Infrastructure as Code, утилит SaltStack, Kitchen-CI и так далее, однако, сколько я не встречал различного рода примеров IaC, они зачастую остаются только кодом, как правило, с делением на бранчи в VCS соответствующие наименованию типа среды, например dev/int, возможно даже с тэгами, а говорить о полноценном цикле разработки конфигураций как правило не приходится. Во всяком случае с компаниями, с которыми знаком именно такая ситуация, да и статей не находил.
Может быть оно и понятно — тотальный Agile и "раз-раз и в продакшен".
Попробую исправить ситуацию данной статьей.
Непрерывная интеграция: CircleCI vs Travis CI vs Jenkins
2017-07-18 в 6:00, admin, рубрики: circleci, continuous delivery, continuous integration, devops, Jenkins, travis, Блог компании Southbridge, метки: circleci
Под катом вы найдете перевод статьи ознакомительного характера, в которой сравниваются три системы непрерывной интеграции: CircleCI, Travis CI и Jenkins.
Трудные уроки: пять лет с Node.js
2017-04-21 в 8:53, admin, рубрики: Async.js, callback, coffeescript, express, Gatsby, javascript, Jenkins, jshint, mocha, NaN, New Relic, node.js, pg, react.js, toobusy-js, Проектирование и рефакторинг, Разработка веб-сайтов, Тестирование веб-сервисовПосле пяти лет работы с Node.js я многое понял. Я уже делился некоторыми историями, но в этот раз хочу рассказать о том, какие знания дались труднее всего. Баги, проблемы, сюрпризы и уроки, которые вы можете использовать в собственных проектах!
Базовые концепции
В каждой новой платформе есть свои хитрости, но в данный момент эти концепции для меня вторичны. Разобраться в своём баге — хороший способ гарантированного обучения. Даже если это немного болезненно!
Классы
Когда я только начал работать с Node.js, то написал скрапер. Очень быстро я понял, что если ничего не предпринять, то он будет осуществлять много запросов параллельно. Одно это стало важным открытием. Но поскольку я ещё не полностью усвоил мощь экосистемы, то сел и написал собственный ограничитель параллелизма. Он работал и проверял, что в каждый момент времени активны не более N запросов одновременно.
Читать полностью »
Версионирование артефактов сборки в Gradle используя git имена тегов, бранчей и коммитов
2017-02-12 в 19:16, admin, рубрики: ci, Git, gradle, java, Jenkins, packaging, versioning, Программирование, системы сборкиС переездом из SVN на GIT и gitlab (плюс переезд из Jenkins на Gitlab-CI, но его использование также упомянём), встал вопрос версионирования получаемых артефактов сборки приложения.
В SVN был всем привычный номер ревизии, монотонно увеличивающийся с каждым коммитом. Его было удобно добавлять в номер версии, и это решало большинство проблем. Но git конечно предоставляет множество плюшек, и стоило убеждать руководство и всё команду перевести проект на него…
Зато пришлось отстроить заново процесс версионирования получаемых артефактов сборки.
В итоге остановились на очень хорошем Gradle плагине github.com/nemerosa/versioning, о его использовании я и собираюсь рассказать.
Читать полностью »
Переход с CruiseControl.NET на Jenkins в команде разработчиков PVS-Studio
2017-02-07 в 13:28, admin, рубрики: continuous integration, cruisecontrol, Jenkins, Jenkins CI, pvs-studio, Блог компании PVS-Studio, системы сборки, Тестирование IT-систем
Сейчас трудно представить разработку программного обеспечения без автоматизированных сборок проекта и тестирования. Для минимизации временных затрат на интеграцию изменений разработчиков в проект, существуют разные готовые решения. В данной статье я расскажу о замене сервера непрерывной интеграции CruiseControl.NET на Jenkins в команде разработчиков PVS-Studio. А также о том, что нас к этому побудило, какие цели мы преследовали и с какими проблемами столкнулись.
Читать полностью »
Автоинкремент версий в pom.xml через Jenkinsfile
2016-11-28 в 20:40, admin, рубрики: ci, Git, java, JenkinsРано или поздно все разработчики Java решают мелкие задачи в области Continuos Integration. Не обошла эта участь и меня. Озадачился я проблемой автоматического инкремента версий в pom.xml при каждой итерации сборки проекта.
Дано: maven проект с несколькими модулями, мастер pom.xml и Jenkins-сервер (все как у настоящих пацанов).
Нужно: чтобы при каждом коммите автоматически собирался проект в любом бранче, а в ветке develop проект не только собирался, но и инкрементился номер билда, который задан третьим числом в версии вида 1.0.100-SNAPSHOT.
Для автоматической сборки Java-проекта в бранчах у нас используется Jenkins-проект на основе модного нынче Multibranch pipeline.
Суть этого workflow — периодически (например, раз в минуту), в Multibranch pipeline запускается задача, которая определяет изменения в бранчах и запускает сборку для тех бранчей, в которых что-то закоммитили. При этом, как у настоящих пацанов, для сборки бранча используется самый настоящий Jenkinsfile. Немного ликбеза: Jenkinsfile — это код на языке Groovy который определяет последовательность и инструкции по сборке проекта. Даже придумали для этого специальный термин «pipeline as code». Казалось, ничего вроде бы сложного нет — через groovy-скрипт инкрементим номер версии, коммитим и запускаем maven-сборку. Но тут нарисовывается главная проблема — как предотвратить последующие (бесконечные) сборки после того, как мы автоматом обновили pom.xml? Да, в Jenkins-плагине под названием 'git' (тот самый, который предназначен для детекта изменений в бранчах) есть даже специальная фича — «Pooling ignores commit», но вот незадача — она не работает в Multibranch-pipeline. По этому поводу жаловались многие пользователи и даже завели специальный Jira-айтем. Поэтому — вперед, будем изобретать свой велосипед!
Читать полностью »
Установка Jenkins и Bonobo Git Server под ОС Windows для сборки Android приложений
2016-10-25 в 20:48, admin, рубрики: android development, Bonobo git server, gradle, Jenkins, Разработка под android, системы сборки, Системы управления версиямиДобрый день. Не имея времени копаться в LinuxСтолкнувшись с пробелами в информации при поиске по сети инструкций по установке и настройке под ОС Windows сервера непрерывной сборки Jenkins для приложений Android, Git сервера и их интеграции решил поделиться информацией о том, что у меня получилось.
Читать полностью »
OpenShift + Jenkins + Bitbucket, непрерывная интеграция и публикация из коробки
2016-10-20 в 2:55, admin, рубрики: bitbucket, docker он везде, Git, Jenkins, openshift, php, Разработка веб-сайтов, системы сборки, Системы управления версиями, Тестирование IT-систем
В этой статье я покажу, как быстро развернуть среду для сборки, тестирования и публикации приложений используя платформу OpenShift на примере PHP проекта. Использовать буду OpenShift online, но всё это же можно развернуть и на собственных серверах или в VirtualBox (есть готовая сборка). Git-сервером для хранения и версионирования кода будет Bitbucket.
Читать полностью »
Получаем управление обратно в Jenkins Pipeline
2016-09-07 в 13:20, admin, рубрики: continuous delivery, Jenkins, Jenkins CI, open source, ПрограммированиеJenkins Pipeline Plugin очень удобная штука, чтобы организовать у себя непрерывную доставку ПО (Continuous Delivery). Плагин даёт возможность разбить доставку ПО до конечного потребителя на стадии (stage), каждой из которых можно управлять (на каком узле, что и как нужно сделать) и, в конечном счёте, визуализировать процесс доставки. Вкупе с Blueocean plugin всё это выглядит очень вкусно. В реальной же жизни подчас оказывается так, что кроме Jenkins-а есть ещё и другие системы, которые участвуют в этом процессе (workflow), и встаёт вопрос — как их интегрировать с имеющимися решениями. Примером тут может служить Jira, в которой есть некий issue падающий на тестировщика, прокликивающего интерфейс (ну или совершающего другую полезную работу), и только после его благословения, наш артефакт имеет право двигаться дальше в сторону ожидающего его клиента.
Так какие у нас есть варианты реализации?