Авто старт билда приложения на Дженкинсе

Доброго времени суток!
Поделитесь кто-нибудь вменяемым мануалом или видео по конфигурации и деплою билдов на Дженкинсе.
На офф. документацию просьба не отправлять — там все очень «сферично и вакуумно».

Заранее спасибо.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Десь так bit.ly/2gt7FHh

У випадку, якщо SCM в одній мережі з Jenkins-ом, краще post-merge хуком з SCM запускати задачу на Jenkins, а не постійно опитувати з Jenkins SCM на предмет змін.

Це те ж саме, що запитувати у вас чи не хочете ви їсти кожну хвилину, ніж якби ви просто прийшли на кухню і поїли, якщо ви зголодніли.

У випадку, якщо SCM в одній мережі з Jenkins-ом, краще post-merge хуком з SCM запускати задачу на Jenkins, а не постійно опитувати з Jenkins SCM на предмет змін.
Це те ж саме, що запитувати у вас чи не хочете ви їсти кожну хвилину, ніж якби ви просто прийшли на кухню і поїли, якщо ви зголодніли.
Аналогия в корне не верна.
.
Фактически, то что вы предлагаете — это размазать конфигурацию между 2-мя сервисами (ВЦС и ЦИ). Ваше решения может иметь место в определенных ситуациях, например, убогий ЦИ-сервер, специфическая структура проекта или ВЦС. Но это частные случаи.
.
В общем случае лучше иметь весь процес сборки в одном месте, так им проше управлять: вкл/выкл, переносить, создавать копиии и тд.

коли чесно — то я вас не зрозумів. Ви пропонуєте тримати Дженкінс і Гіт на одному сервері?

Ви пропонуєте тримати Дженкінс і Гіт на одному сервері?
Можліво мені краще перейти на українську, бо російську ви явно розумієте погано :)
Я сказав, що ваша аналогія некорректна, так само як і твердження, що хук в VCS краще ніж CI який опитує VCS.

Хук в VCS на білд задачі — це один запит. Опитування VCS і запуск задачі в CI — це багато запитів, адже не зрозуміло, коли зміни будуть в VCS. Що в моїх словах не логічно?

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

Так і Гіт за такою ж логікою може переїхати.

В тому і справа, шо сі завжди буде залежати від гіта, як би не проектувати інфраструктуру. Тому коли гіт переїде, в будь-якому випадку прийдеться переконфіжувати.
А гіт не обовязково має залежати від сі. Пінгуючи гіт, в нас стає на одну dependency менше, і це круто

>> Тому коли гіт переїде, в будь-якому випадку прийдеться переконфіжувати.

Ну якщо гіт переїде у випадку, коли гіт буде пост-мердж хуком запускати джоби, то айпі СІ відповідно переконфіговувати не треба буде. Тому як на мене це не аргумент. Все може переїхати, якщо вже так говорити.

Хук в VCS на білд задачі — це один запит. Опитування VCS і запуск задачі в CI — це багато запитів, адже не зрозуміло, коли зміни будуть в VCS. Що в моїх словах не логічно?
Ок, с украинским у вас не лучше. Я не говорил что в ваших словах что-то не логично.
Я сказал что ваша аналогия некорректна.
А некорректна она потому что «хочет кушать» не ВЦС, а ЦИ сервер.
А утверждение что «хук лучше» не верно потому что критерий для «лучше» выбран некорректный, количество пинг запросов между ВЦС и ЦИ, в большинстве систем, не является узким местом.
Куда важнее, возможность удобно управлять билдами, решение с хуком создаст кучу проблем с билдом, когда вам надо преехать в другой репозиторий, например.

Добавляете новую билд конфигурацию.
=> Управление исходным кодом
=> добавляете ваш репозиторий (добавте плагин с вашей системой контроля версии если нужно)
=> Триггеры сборки:

Опрашивать SCM об изменениях — в лупе дергает раз в какое-то время репу и если есть че то чекаутит и билдит проект
Собирать периодически — можно кроном например наконфигурировать когда или как часто собирать
Build after other projects are built — указываете автоматически билдить после другого билда

=>
Сборка тут все ± понятно, если java/maven указываете ваш помничек и например clean install в Goals
Больше особо делать особо ничего не нужно(если всякие там переменный и окружение настроенно), дальше все методом тыка и гугления легко делается.

Хоть один конкретный ответ на вопрос. Спасибо!

Переходи на ТимСити и забудь Дженкинс как страшный сон.
Он уже давно не в себе.

Я бы и рад забыть, но это не от меня пока зависит.

Что именно вас интересует ? Вам по времени запускать или привязатся к собыю?

Допустим, развернут на Линуксе Дженкинс, как в Дженкинсе сконфигурировать новый проект и привязать к каой-нибудь системе контроля версий типа Перфорс или Гит (желательно на примере) + как сконфигурировать билд на автобилд при изменениях в проекте?

как в Дженкинсе сконфигурировать новый проект и привязать к каой-нибудь системе контроля версий типа Перфорс или Гит (желательно на примере) + как сконфигурировать билд на автобилд при изменениях в проекте?
Это у вас шутки такие?
wiki.jenkins-ci.org/...ilding a software project
www.cloudbees.com/blog/using-git-jenkins
wiki.jenkins-ci.org/...isplay/JENKINS/Git Plugin
www.andyfrench.info/...gering-jenkins-build.html

А шо не так c Jenkins ? Хватит прикрывать свою безграмотность «использованием новых технологий» — этот вечный поиск framework который уж точно решит все проблемы ...

«использованием новых технологий»
«It was first released on October 2, 2006» — суперновая технология которой уже 10+ лет :)
А шо не так c Jenkins ?
Он не «продакшн реди» :)
Где-то лет 5 назад я выбирал куда бы перейти с круиза, я убил где-то 2 дня чтобы настроить простеникий билд на дженкинсе (под виндой) уперся во что-то специфическое для конкретного проекта.
Попробовал тимсити, потратил где-то 1.5 дня, на разоврачивани + настройку всех неявных зависимостей для проекта (билд рассчитывал что будут выставлены енв переменные, томкет в определенной папке и тд).
Конечно можно списать на то что тогда дженкинсу еще и года не исполнилось, но все же :) (это шутка для тех кто вкурсе)
.
Сборка проекта — это не то на что нужно тратить много времени, новый билд должен создаваться очень просто (даже для не админа). Тимсити позволяет это сделать, Дженкинс остался на уровне 2005 года — «УИ есть. Скажите спасибо что не XSLT-файлы правите!»

Хзхзхз — у меня проблем с переходом на него не случилось, единственное с мне прислошь порядочно почитать доки когда мне понабился очень витиеватый DSL (build flow) project — но то такое именно мне понабилось «стоя, в гамаке, в ластах и противогазе» :D Вполне используеися в проде, радует система плагинов и система подключения Linux/Windows/Mac удаленных нод ...

> Jenkins was originally developed as the Hudson project. Hudson’s creation started in summer of 2004 at Sun Microsystems. It was first released in java.net in Feb. 2005.[5]

Знову ж таки, 10 років тому — це той період, коли вже краще не ділитись досвідом використання технології.

Безкоштовний опенсорс продукт хороший вже тим, що він таким є. Це розмова по змісту схожа на тему «Що краще Photoshop чи Gimp?».

Jenkins — це стандарт де-факто для CI/CD, якщо не тратити грошей на ліцензії. Він має мільйон плагінів і т.п., які можливо і не працюють з самого початку. Звісно, це займе час.

Внезапно, бесплатной версии ТимСити хватает всем, и на разу не сталкивался с необходимостью докупки агентов/билдов.
Как и имеет 990 000 плагинов.

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

Знову ж таки, 10 років тому — це той період, коли вже краще не ділитись досвідом використання технології.
1) Если вы про
Конечно можно списать на то что тогда дженкинсу еще и года не исполнилось
то дочитайте строку до конца.
Це розмова по змісту схожа на тему «Що краще Photoshop чи Gimp?».
У фотошопа есть бесплатная версия с полной функциональность и без ограничений по времени использования?

Ви робите висновок з того, що 10 років тому ним користувались. За 10 років все могло дуже багато разів змінитись, особливо в ІТ. Я ось про це.

> У фотошопа есть бесплатная версия с полной функциональность и без ограничений по времени использования?

Я не знаю, 10 років тому, коли я його встановлював, її не було :)

Ви робите висновок з того, що 10 років тому ним користувались
Нет.
Я сказал что дженкинс в плане УИ (удобства и простоты) остался на уровне 2005 года.

Знову ж таки немає жодного сенсу порівнювати безкоштовні продукти і речі які варті серйозних грошей. Це досить таки різні класи продуктів.

Знову ж таки немає жодного сенсу порівнювати безкоштовні продукти і речі які варті серйозних грошей.
И снова здравствуйте :)
Есть бесплатная версия тимсити с 3-мя билд агентами, для коммады 15-30 человек, этого вполне достаточно. Нет абсолютно никакой проблемы под каждую команду/проект заводить свой ЦИ-сервер, а возможно даже нужно заводить отдельный ЦИ www.thoughtworks.com/...ci-instance-for-all-teams
Це досить таки різні класи продуктів.
От в том то и дело что Дженкинс и Тимсити — это явные конкуренты. Продукты для сравнения классифицируют по функциональности, а цена — это только пунк сравнения (вы же не предлагаете заменить дженкинс на либреоффис или гимп :) )
Если вопрос только цены, то она начнет иметь значение для больших компаний, для таких которые скорее всего таки пойдут покупать тот же дженкинс
суперновая технология которой уже 10+ лет :)
Как же вы Windows-то тогда пользуетесь, которой уже 30 лет?

Підписатись на коментарі