Комментарии 5
Статьи про CI, а тем-более про Jenkins это всегда здорово!
Кроме того после установки практически каждого plugin'a расширяются системные настройки и/или настройки проекта, что может усложнить процесс настройки для начинающего пользователя. Опираясь на свой незначительный опыт могу сказать, что незнакомые plugin'ы однозначно удобнее устанавливать по одному, особенно (!) если это plugin'ы схожи по назначению.
На мой взгляд выгода от данной рекомендации весьма сомнительна. По умолчанию Jenkins создает executer'ов по количеству ядер, что (при однопоточной сборке проектов) позволяет исключить взаимное влияние на наличие ресурсов между одновременно запущенными проектами. Если сборка проекта не однопоточнная, то за ней можно закрепить большее число executor'ов.
Если вы создадите большее число executor'ов чем количество ядер на вашем сервере, то, на мой взгляд, ваши проекты хоть и начнут собираться одновременно, но закончат они все-равно не раньше чем если бы они были запущенны один за другим.
Однозначно полезный совет. Касательно безопасности хочется добавить, что помимо настройки глобальных прав Jenkins позволяет «уточнять» права индивидуально для каждого проекта и я бы рекомендовал сразу же следовать этой практике. Т.е. глобально всем пользователям (кроме админа) уровень Read, а вот уже на каждом отдельном проекте индивидуально для каждого пользователя устанавливаются конкретные права; в 99% случаев для всех пользователей от проекта к проекту права будут одинаковы, но когда наступит тот самый 1%, то такой подход себя оправдает!
Обратите внимание на multi-configuration project, возможно это позволит сократить число проектов и сгруппировать их.
Все правильно! Синие кружочки это моветон! Кружочки должны быть исключительно зелеными ;)!
Вообще ничего не понял. Возможно сказывается тот факт, что я не знаком с Java, но я никак не могу понять для каких задач может потребоваться такое? «которые можно было завершить только по нажатию крестика», — а как разработчики у себя на рабочих машинах собирают эти проекты?
Не стоит устанавливать все plugin'ы которые видите.… Они могут… съедать лишние ресурсы… .
Кроме того после установки практически каждого plugin'a расширяются системные настройки и/или настройки проекта, что может усложнить процесс настройки для начинающего пользователя. Опираясь на свой незначительный опыт могу сказать, что незнакомые plugin'ы однозначно удобнее устанавливать по одному, особенно (!) если это plugin'ы схожи по назначению.
… Если у сервера маленькая производительность — продумайте расписание сборок так, что бы много ресурсоемких сборок не были запущены одновременно, а если вы не хотите следить за количеством используемых ресурсов — убедитесь, что максимальное число запускаемых сборок больше, или хотя бы такое же, как и число проектов.
На мой взгляд выгода от данной рекомендации весьма сомнительна. По умолчанию Jenkins создает executer'ов по количеству ядер, что (при однопоточной сборке проектов) позволяет исключить взаимное влияние на наличие ресурсов между одновременно запущенными проектами. Если сборка проекта не однопоточнная, то за ней можно закрепить большее число executor'ов.
Если вы создадите большее число executor'ов чем количество ядер на вашем сервере, то, на мой взгляд, ваши проекты хоть и начнут собираться одновременно, но закончат они все-равно не раньше чем если бы они были запущенны один за другим.
Безопасность. Не стоит о ней забывать. ...
Однозначно полезный совет. Касательно безопасности хочется добавить, что помимо настройки глобальных прав Jenkins позволяет «уточнять» права индивидуально для каждого проекта и я бы рекомендовал сразу же следовать этой практике. Т.е. глобально всем пользователям (кроме админа) уровень Read, а вот уже на каждом отдельном проекте индивидуально для каждого пользователя устанавливаются конкретные права; в 99% случаев для всех пользователей от проекта к проекту права будут одинаковы, но когда наступит тот самый 1%, то такой подход себя оправдает!
Например, если у вас несколько версий одного продукта запущены на разных портах, почему бы их не назвать в духе «ProjectAbbr9587», где 9587 — это номер порта. Такая политика имен, позволяет быстро понять, и уменьшает возможность перепутать о чем идет речь.
Обратите внимание на multi-configuration project, возможно это позволит сократить число проектов и сгруппировать их.
Естественно после первого запуска мне было непривычно смотреть на синие кружечки, но их цвет был изменен далеко не сразу.
Все правильно! Синие кружочки это моветон! Кружочки должны быть исключительно зелеными ;)!
С другой стороны, у меня были проекты, которые должны находиться в «бесконечной сборке». Ant task'и, которые запускали веб сервера и в сборку выводили лог действий, что было очень удобно. Естественно эти сервера могли находиться по несколько дней в запущенном состоянии, и без лишней надобности их останавливать нет смысла, т.к. на них могут вестись работы, показываться результаты заказчикам и прочее.
Допустим из-за скачка напряжения\отсутствия света сервер перезагрузили. На нем запустился JenkinsCI, но не запустились проекты, которые должны быть постоянно запущены? Каждый раз запускать ручками — глупо. Так что, очень хочется галочку: «запускать ли данный проект, после перезагрузки?»
Т.к. у меня были проекты, которые можно было завершить только по нажатию крестика(что означает «отмена сборки»), меня очень сильно угнетали серые шарики, по этому мне захотелось сделать сборку успешной(пусть не портит статистику, я же знаю, что все правильно).
Вообще ничего не понял. Возможно сказывается тот факт, что я не знаком с Java, но я никак не могу понять для каких задач может потребоваться такое? «которые можно было завершить только по нажатию крестика», — а как разработчики у себя на рабочих машинах собирают эти проекты?
Если сборка проекта не однопоточнная, то за ней можно закрепить большее число executor'ов.
Если вы создадите большее число executor'ов чем количество ядер на вашем сервере, то, на мой взгляд, ваши проекты хоть и начнут собираться одновременно, но закончат они все-равно не раньше чем если бы они были запущенны один за другим.
Тут скорее нужно бояться не длительности выполнения, а возможности невыполнения сборки. У нас ограниченное максимальное число запланированных сборок, и соответственно возможна ситуация, когда некоторые сборки будут проигнорированы, хот\ это и маловероятно.
Обратите внимание на multi-configuration project, возможно это позволит сократить число проектов и сгруппировать их.Случайно отправил недописав
Тут скорее нужно бояться не длительности выполнения, а возможности невыполнения сборки. У нас ограниченное максимальное число запланированных сборок, и соответственно возможна ситуация, когда некоторые сборки будут проигнорированы, хот\ это и маловероятно.
От мультиконфигураций отказались осознанно. Например на дженкинсе у нас запускаются тестовые сервера, и нам нужно уметь запускать конкретные сервера(конкретные бренчи) по требованию, а не сразу все. Более того в силу особенностей — это бесконечные сборки(подробнее ниже), и останавливать один сервер, что бы запустить два — не рационально.
Средства джава позволяют запускать подобные проекты и другими способами, просто гораздо удобнее читать основной лог веб сервера в логе сборки и на ходу понимать что к чему, чем копаться по логам сохраненным на сервере(выгрузить как артефакты их не удастся), к которому не у всех есть доступ.
ну а по поводу безопасности у дженкинса реализован отличнейший функционал плагинов, позволяющих быстро и удобно определять политику пользователей. Если интересно — могу более подробно написать
Если сборка проекта не однопоточнная, то за ней можно закрепить большее число executor'ов.
Если вы создадите большее число executor'ов чем количество ядер на вашем сервере, то, на мой взгляд, ваши проекты хоть и начнут собираться одновременно, но закончат они все-равно не раньше чем если бы они были запущенны один за другим.
Тут скорее нужно бояться не длительности выполнения, а возможности невыполнения сборки. У нас ограниченное максимальное число запланированных сборок, и соответственно возможна ситуация, когда некоторые сборки будут проигнорированы, хот\ это и маловероятно.
обратите внимание на multi-configuration project, возможно это позволит сократить число проектов и сгруппировать их
От мультиконфигураций отказались осознанно. Например на дженкинсе у нас запускаются тестовые сервера, и нам нужно уметь запускать конкретные сервера(конкретные бренчи) по требованию, а не сразу все. Более того в силу особенностей — это бесконечные сборки(подробнее ниже), и останавливать один сервер, что бы запустить два — не рационально.
Вообще ничего не понял. Возможно сказывается тот факт, что я не знаком с Java, но я никак не могу понять для каких задач может потребоваться такое? «которые можно было завершить только по нажатию крестика», — а как разработчики у себя на рабочих машинах собирают эти проекты?
Средства джава позволяют запускать подобные проекты и другими способами, просто гораздо удобнее читать основной лог веб сервера в логе сборки и на ходу понимать что к чему, чем копаться по логам сохраненным на сервере(выгрузить как артефакты их не удастся), к которому не у всех есть доступ.
ну а по поводу безопасности у дженкинса реализован отличнейший функционал плагинов, позволяющих быстро и удобно определять политику пользователей. Если интересно — могу более подробно написать
У нас ограниченное максимальное число запланированных сборок, и соответственно возможна ситуация, когда некоторые сборки будут проигнорированы,Хм, не сталкивался. Знаю, что один и тот же проект в очередь больше двух раз не встанет, но разные проекты становятся в очередь «без потерь».
ну а по поводу безопасности у дженкинса реализован отличнейший функционал плагинов, позволяющих быстро и удобно определять политику пользователей. Если интересно — могу более подробно написатьЕсли это удобнее чем тот вариант, который описал я, то однозначно нужно.
Хм, не сталкивался. Знаю, что один и тот же проект в очередь больше двух раз не встанет, но разные проекты становятся в очередь «без потерь».
средства дженкинса(а может и какие-то плагины точно не скажу) позволяют определять максимальное количество запланированных сборок. Я не уверен, но вроде как возможно запретить планировать сборки в принципе.
Если это удобнее чем тот вариант, который описал я, то однозначно нужно.
из того что могу сказать по памяти — был нехороший опыт с LDAP логинами. Ну и наиболее удобный мне способ, позволял определять правила не для каждого проекта, а для группы проектов названия которых совпадают с регулярным выражением(еще один плюс в пользу структурированных названий проектов)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Jenkins CI — вещи, которых мне не хватало