Строгий замер по скорости новых фич мы не вели, поэтому тут скорее оценка команды, а не бенчмарк.
По онбордингу стало заметно проще: раньше человеку нужно было разбираться сразу в Jenkins, Groovy, shared library и наших внутренних соглашениях. Сейчас вход ближе к обычной разработке: Python-проект, тесты, CLI и готовая среда исполнения. По ощущениям, вместо месяцев это стало ближе к паре недель.
Dev experience тоже улучшился: меньше цикла “закоммитил → запустил job → читаешь лог”, больше локальной разработки и нормальной отладки. Но метрику по lead time новых фич отдельно, да, стоило бы померить.
Спасибо, у вас как раз очень здоровая модель получилась.
По сути, вы с самого начала сделали то, к чему мы пришли позже: Jenkins отдельно, среда исполнения отдельно, логика не живёт в Jenkins, а агенты и образы можно пересоздавать без особой драмы.
Про плагины и миграции тоже полностью согласен. Пока логика размазана по Jenkins, плагинам и Groovy, любое обновление или переезд превращается в отдельный проект с сюрпризами.
Ansible в вашем случае выглядит естественным местом для логики, особенно для инфраструктурных задач. У нас контекст был другой, поэтому пришли к своему runtime в образе, но принцип тот же: Jenkins лучше работает как запускалка/оркестратор, а не как место, где живёт вся автоматизация.
Овраги, конечно, есть - с этим спорить не буду. ПСИ, сканирование образов и обязательные корпоративные shared library никуда не исчезают.
Я бы только не формулировал подход как “вынести вообще всё в образ”. Скорее так: всё, что можно сделать самостоятельной, тестируемой и версионируемой средой исполнения, лучше постепенно уносить из Jenkins. А то, что жёстко завязано на корпоративные контуры или legacy, может оставаться отдельными шагами/shared library.
С pipeline на 100500к строк как раз и видно, что Jenkins уже стал внутренней платформой. Одним движением это не лечится, но держать всю эту логику внутри Groovy/CPS тоже, на мой взгляд, не лучший финальный вариант.
Идея понятная, но у меня тут сразу несколько вопросов.
ci.sh один общий на все проекты или в каждом репозитории свой? Если в каждом свой, то как потом раскатывать изменения в десятки/сотни репозиториев? Если общий, то где он живёт и как версионируется?
Ещё интересно, насколько разные у вас типы проектов. Одно дело, когда все плюс-минус одинаковые, и совсем другое - когда есть backend, frontend, mobile, legacy, разные платформы, разные способы сборки и публикации артефактов.
И главный риск, который я вижу: со временем такой ci.sh может стать тем же pipeline, только написанным на bash. Вроде CI уже не важен, но появляется своя точка сложности: условия, флаги, исключения, версии, договорённости и ручное обновление по репозиториям.
Как вы решаете эту часть? Есть какой-то общий шаблон/генератор/версионируемый tool, или это именно набор скриптов внутри каждого проекта?
Да, с этим во многом согласен. Jenkins как раз и живёт так долго потому, что он очень гибкий и почти любой кейс в нём можно дожать.
Но, как вы правильно написали, гибкость - это и сильная сторона, и ловушка. Если есть дисциплина, понятные границы, аккуратные shared libraries и в основном declarative pipeline, то жить можно вполне спокойно. Особенно если команда давно в этом контексте и хорошо понимает, где остановиться.
У нас боль началась не от самого факта использования Jenkins, а от масштаба и разрастания логики вокруг него: много команд, много интеграций, много исключений, и постепенно Jenkins стал не только оркестратором, но и средой, где живёт существенная часть автоматизации.
Поэтому я бы не спорил с тезисом “Jenkins можно использовать нормально”. Можно. Просто статья скорее про тот момент, когда “нормально используем” незаметно превращается в “у нас внутри Jenkins уже своя платформа”. Вот эту границу, как мне кажется, важно вовремя поймать.
Да, связка Jenkins + Ansible как раз хорошо ложится в мысль статьи. Jenkins в такой схеме не пытается быть местом, где живёт вся логика, а скорее выступает оркестратором: запустить нужный ранбук, передать параметры, показать результат.
А сама логика уже живёт там, где ей естественнее жить - в Ansible. Для VM, baremetal и особенно историй с БД это вообще очень понятный вариант.
У нас похожая идея, только в другом контексте: не обязательно “всё в образ”, главное - не превращать Jenkinsfile в место, где постепенно разрастается вся автоматизация. Потому что потом это и читать сложно, и переносить страшно, и отлаживать больно.
Как в вашем подходе организована работа с секретами? Это делает jenkins?
Спасибо, хороший вопрос.
Строгий замер по скорости новых фич мы не вели, поэтому тут скорее оценка команды, а не бенчмарк.
По онбордингу стало заметно проще: раньше человеку нужно было разбираться сразу в Jenkins, Groovy, shared library и наших внутренних соглашениях. Сейчас вход ближе к обычной разработке: Python-проект, тесты, CLI и готовая среда исполнения. По ощущениям, вместо месяцев это стало ближе к паре недель.
Dev experience тоже улучшился: меньше цикла “закоммитил → запустил job → читаешь лог”, больше локальной разработки и нормальной отладки. Но метрику по lead time новых фич отдельно, да, стоило бы померить.
Спасибо, у вас как раз очень здоровая модель получилась.
По сути, вы с самого начала сделали то, к чему мы пришли позже: Jenkins отдельно, среда исполнения отдельно, логика не живёт в Jenkins, а агенты и образы можно пересоздавать без особой драмы.
Про плагины и миграции тоже полностью согласен. Пока логика размазана по Jenkins, плагинам и Groovy, любое обновление или переезд превращается в отдельный проект с сюрпризами.
Ansible в вашем случае выглядит естественным местом для логики, особенно для инфраструктурных задач. У нас контекст был другой, поэтому пришли к своему runtime в образе, но принцип тот же: Jenkins лучше работает как запускалка/оркестратор, а не как место, где живёт вся автоматизация.
Овраги, конечно, есть - с этим спорить не буду. ПСИ, сканирование образов и обязательные корпоративные shared library никуда не исчезают.
Я бы только не формулировал подход как “вынести вообще всё в образ”. Скорее так: всё, что можно сделать самостоятельной, тестируемой и версионируемой средой исполнения, лучше постепенно уносить из Jenkins. А то, что жёстко завязано на корпоративные контуры или legacy, может оставаться отдельными шагами/shared library.
С pipeline на 100500к строк как раз и видно, что Jenkins уже стал внутренней платформой. Одним движением это не лечится, но держать всю эту логику внутри Groovy/CPS тоже, на мой взгляд, не лучший финальный вариант.
Идея понятная, но у меня тут сразу несколько вопросов.
ci.sh один общий на все проекты или в каждом репозитории свой? Если в каждом свой, то как потом раскатывать изменения в десятки/сотни репозиториев? Если общий, то где он живёт и как версионируется?
Ещё интересно, насколько разные у вас типы проектов. Одно дело, когда все плюс-минус одинаковые, и совсем другое - когда есть backend, frontend, mobile, legacy, разные платформы, разные способы сборки и публикации артефактов.
И главный риск, который я вижу: со временем такой ci.sh может стать тем же pipeline, только написанным на bash. Вроде CI уже не важен, но появляется своя точка сложности: условия, флаги, исключения, версии, договорённости и ручное обновление по репозиториям.
Как вы решаете эту часть? Есть какой-то общий шаблон/генератор/версионируемый tool, или это именно набор скриптов внутри каждого проекта?
Да, с этим во многом согласен. Jenkins как раз и живёт так долго потому, что он очень гибкий и почти любой кейс в нём можно дожать.
Но, как вы правильно написали, гибкость - это и сильная сторона, и ловушка. Если есть дисциплина, понятные границы, аккуратные shared libraries и в основном declarative pipeline, то жить можно вполне спокойно. Особенно если команда давно в этом контексте и хорошо понимает, где остановиться.
У нас боль началась не от самого факта использования Jenkins, а от масштаба и разрастания логики вокруг него: много команд, много интеграций, много исключений, и постепенно Jenkins стал не только оркестратором, но и средой, где живёт существенная часть автоматизации.
Поэтому я бы не спорил с тезисом “Jenkins можно использовать нормально”. Можно. Просто статья скорее про тот момент, когда “нормально используем” незаметно превращается в “у нас внутри Jenkins уже своя платформа”. Вот эту границу, как мне кажется, важно вовремя поймать.
Спасибо!
Да, связка Jenkins + Ansible как раз хорошо ложится в мысль статьи. Jenkins в такой схеме не пытается быть местом, где живёт вся логика, а скорее выступает оркестратором: запустить нужный ранбук, передать параметры, показать результат.
А сама логика уже живёт там, где ей естественнее жить - в Ansible. Для VM, baremetal и особенно историй с БД это вообще очень понятный вариант.
У нас похожая идея, только в другом контексте: не обязательно “всё в образ”, главное - не превращать Jenkinsfile в место, где постепенно разрастается вся автоматизация. Потому что потом это и читать сложно, и переносить страшно, и отлаживать больно.
Как в вашем подходе организована работа с секретами? Это делает jenkins?