Кирилл, спасибо Вам за эти семь минут, что Вы "наболтали", сейчас хотя бы появилось понимание, что это, для чего это и как это должно работать. Это очень ценная информация, если Вам не сложно, прошу придерживаться такого стиля :) p.s. удачи в ГАИ!
Кирилл есть замечание по поводу cron синтаксиса. Вы говорите, что он рандомно может выбирать интервал. На самом деле он не рандом. Он берет хеш пайплайна и на основании хеша выбирает четко зафиксированный для конкретного правила и конкретного пайплайна интервал. Опция "H" по сути и является первой буквой в слове "Hash". Поэтому можно утверждать, что каждый пайплайн будет запускаться в свой промежуток времени и вероятность выполнения двух пайпов в одно время мала.
Очень интересный (и неприятный) эффект появляется когда необходимо настроить CI для большого проекта, например если репозиторий имеет размер 1-5 Гигабайт или более. Сталкивался с этим на 1С:ERP (конфигурации 1С можно выгружать в XML и использовать репозиторий на CI). Сборка может, а в некоторых случаях всегда происходит, дважды на один и тот же коммит. Причины следующие: 1) По расписанию Jenkins обнаруживает новый коммит и запускает сборку. И начинает выкачивать изменения из репозитория. Для большого репозитория время выкачки изменений может оказаться большим (например 3-5 минут, но зависит от размера репозитория и скорости сети). Также ситуация усугубляется если в задаче стоит настройка "Clean before checkout" (это увеличивает время операции если удаляемых файлов много) или репозиторий в рабочей директории задачи вычищается вручную. 2) Факт того, что этот коммит уже обработан самим Jenkins при запуске fetch/pull не фиксируется. Для задачи по прежнему последним обработанным считается предыдущий коммит (это ключевой момент). Коммит будет зафиксирован как обработанный только после завершения операции fetch/pull, но она ещё идет и будет идти несколько минут. 3) Проходит время заданное в расписании опроса SCM (git). Чтобы интервал между коммитом от разработчика и запуском сборки был минимальным обычно это время (как и в данном видео) устанавливается в 1-2 минуты. Jenkins сверяет последний обработанный по его данным коммит (он всё ещё предыдущий по отношению к уже обрабатываемому) видит что они отличаются и пытается запустить задачу. Благодаря опции "disable concurrent builds" она не запускается. НО...... 4) Запрет параллельных сборок (disable concurrent builds) приводит к тому, что сборка не запускается, но и не отменяется. Она становится в очередь. И ждет окончания уже запущенной. При этом ждет с теми параметрами, которые получила при старте. Одним из параметров является хеш коммита! 5) Как только первая сборка заканчивается сразу передается на выполнения стоявшая в очереди. И она начинает делать fetch/pull того же коммита. В итоге получаем две подряд идущие сборки на один и тот же коммит. Выходом является либо увеличение интервала опроса SCM, либо отсутствие "ощчищающих" операций с рабочим каталогом задачи.
Касательно виртуалок. Кирилл расскажи о своем HW окружении и на чем виртуалки поднимаешь. Мне очень нравится интерфейс макоси и я тут копил на жирный imac или макбук однако накопив у них цены поднялись и плюс мне некоторые продавцы стали говорить что мак это не совсем для виртуализации. Вот я щас с air'a коннекчусь к своему компу дома и там уже виртуалки поднимаю. Расскажи как у тебя пожалуйста. И огромное спасибо за видео!!!
Кирилл, добрый день.Огромное спасибо за продолжение. Кирилл, у меня к вам вопрос. Как лучше и правильней организовать процесс разработки и непрерывной интеграции. Ситуация по сути тривиальна наверное...Есть один разработчик. Пишет в C#. В основном это Unity разработка и серверная часть dotnet core. Я отвечаю как раз таки за часть devops. Есть ежемесячный лимит средств на Azure. Как лучше всего организовать все сущности и поставку в продакшен?
Ну это очень широкий вопрос с кучей нюансов) Я не знаю как на него коротко ответить. Организовать так, чтоб все по максимуму было автоматизировано, надежно и дешево
Кирилл, извиняюсь за бестактность. Складывается впечатление, что вы работает 24/7 и ничего кроме работы. Помнится были проекты у вас. Также вроде вы обещали делать видео по Centos.
не, я как раз стараюсь больше 8 часов не работать теперь, у меня перебор. В остальное время стараюсь не подходить к компу. Попробую раз в неделю видео, не реже теперь, пока снова не перекроет
А какой смысл усложнять себе жизнь и писать лишний код пайплайна, если можно тупо в дженкинс установить плагин, который будет делать все нужное? Метод "KISS - keep it stupid simle" никто не отменял!
я за равенство всех перед законом) Для меня это значит суд в данной ситуации. И всего лишь потому что я медленно объехал на аварийке трамвай который минуты три стоял, высадив всех пассажиров на тротуар и явно никуда не собирался ехать
Кирилл, нижайший Вам поклон! Если бы все так учили, наш мир бы расцвел!
Круто, спасибо, жду с нетерпением следующих роликов!
Благодарю, продолжайте в том же духе !
Спасибо Кирилл! Как всегда годный материал, без воды и очень доступно.
Кирилл, спасибо Вам за эти семь минут, что Вы "наболтали", сейчас хотя бы появилось понимание, что это, для чего это и как это должно работать. Это очень ценная информация, если Вам не сложно, прошу придерживаться такого стиля :)
p.s. удачи в ГАИ!
Кирилл есть замечание по поводу cron синтаксиса. Вы говорите, что он рандомно может выбирать интервал. На самом деле он не рандом. Он берет хеш пайплайна и на основании хеша выбирает четко зафиксированный для конкретного правила и конкретного пайплайна интервал. Опция "H" по сути и является первой буквой в слове "Hash".
Поэтому можно утверждать, что каждый пайплайн будет запускаться в свой промежуток времени и вероятность выполнения двух пайпов в одно время мала.
ооо, видосики раз в неделю, отлично, жду следующий.
В принципе, как мне кажется, достучаться до локального Дженкинса вполне реально, единственное, требуется соответствующая конфигурация сети.
Очень хорошо объяснил. Большое спасибо за это) Надеюсь и дальше будешь создавать такие уроки))))))
Подписчики, поможем материально и морально нашему учителю. Это тот самый момент, когда стоит и точно надо помочь
Скорейшего выздоровления, Кирилл
а что с ним??
@@George-mk7lp в описании канала написано, также информация есть в гугле
Отличное видео! СПАСИБО БОЛЬШОЕ!!!
Полезно! Спасибо!
Отлично, новое видео, спасибо !
спасииибо!
Большое спасибо!!
Очень интересный (и неприятный) эффект появляется когда необходимо настроить CI для большого проекта, например если репозиторий имеет размер 1-5 Гигабайт или более. Сталкивался с этим на 1С:ERP (конфигурации 1С можно выгружать в XML и использовать репозиторий на CI). Сборка может, а в некоторых случаях всегда происходит, дважды на один и тот же коммит. Причины следующие:
1) По расписанию Jenkins обнаруживает новый коммит и запускает сборку. И начинает выкачивать изменения из репозитория. Для большого репозитория время выкачки изменений может оказаться большим (например 3-5 минут, но зависит от размера репозитория и скорости сети). Также ситуация усугубляется если в задаче стоит настройка "Clean before checkout" (это увеличивает время операции если удаляемых файлов много) или репозиторий в рабочей директории задачи вычищается вручную.
2) Факт того, что этот коммит уже обработан самим Jenkins при запуске fetch/pull не фиксируется. Для задачи по прежнему последним обработанным считается предыдущий коммит (это ключевой момент). Коммит будет зафиксирован как обработанный только после завершения операции fetch/pull, но она ещё идет и будет идти несколько минут.
3) Проходит время заданное в расписании опроса SCM (git). Чтобы интервал между коммитом от разработчика и запуском сборки был минимальным обычно это время (как и в данном видео) устанавливается в 1-2 минуты. Jenkins сверяет последний обработанный по его данным коммит (он всё ещё предыдущий по отношению к уже обрабатываемому) видит что они отличаются и пытается запустить задачу. Благодаря опции "disable concurrent builds" она не запускается. НО......
4) Запрет параллельных сборок (disable concurrent builds) приводит к тому, что сборка не запускается, но и не отменяется. Она становится в очередь. И ждет окончания уже запущенной. При этом ждет с теми параметрами, которые получила при старте. Одним из параметров является хеш коммита!
5) Как только первая сборка заканчивается сразу передается на выполнения стоявшая в очереди. И она начинает делать fetch/pull того же коммита. В итоге получаем две подряд идущие сборки на один и тот же коммит.
Выходом является либо увеличение интервала опроса SCM, либо отсутствие "ощчищающих" операций с рабочим каталогом задачи.
А поменять на push политика безопасности не позволяет?
Спасибо за урок!
Спасибо большое!))
😎
Касательно виртуалок. Кирилл расскажи о своем HW окружении и на чем виртуалки поднимаешь. Мне очень нравится интерфейс макоси и я тут копил на жирный imac или макбук однако накопив у них цены поднялись и плюс мне некоторые продавцы стали говорить что мак это не совсем для виртуализации. Вот я щас с air'a коннекчусь к своему компу дома и там уже виртуалки поднимаю. Расскажи как у тебя пожалуйста. И огромное спасибо за видео!!!
"Магия девопса")))
Кирилл, добрый день.Огромное спасибо за продолжение. Кирилл, у меня к вам вопрос. Как лучше и правильней организовать процесс разработки и непрерывной интеграции. Ситуация по сути тривиальна наверное...Есть один разработчик. Пишет в C#. В основном это Unity разработка и серверная часть dotnet core. Я отвечаю как раз таки за часть devops. Есть ежемесячный лимит средств на Azure. Как лучше всего организовать все сущности и поставку в продакшен?
Ну это очень широкий вопрос с кучей нюансов) Я не знаю как на него коротко ответить. Организовать так, чтоб все по максимуму было автоматизировано, надежно и дешево
@@KirillSemaev А можно и не коротко)) Я буду только рад развернотому ответу.
Так в итоге, прав лишили или нет? )
How do with Jenkins for one job execute more near Jenkins Job?
not sure what you mean by "more near", but I will get to one job triggering another soon
@@KirillSemaev Ok, more near = jenkins jobs on same thing Jenkins server.
Кирилл, извиняюсь за бестактность. Складывается впечатление, что вы работает 24/7 и ничего кроме работы. Помнится были проекты у вас. Также вроде вы обещали делать видео по Centos.
не, я как раз стараюсь больше 8 часов не работать теперь, у меня перебор. В остальное время стараюсь не подходить к компу. Попробую раз в неделю видео, не реже теперь, пока снова не перекроет
А какой смысл усложнять себе жизнь и писать лишний код пайплайна, если можно тупо в дженкинс установить плагин, который будет делать все нужное? Метод "KISS - keep it stupid simle" никто не отменял!
над гайцам систему пересобрать чтоб вас игнорила.
я за равенство всех перед законом) Для меня это значит суд в данной ситуации. И всего лишь потому что я медленно объехал на аварийке трамвай который минуты три стоял, высадив всех пассажиров на тротуар и явно никуда не собирался ехать