Комментарии 7
Когда столкнулся с проблеммой переиспользования шагов перешел с pipeline синтаксиса на scripting, там можно степ писать прямо внутри пайплайна в виде функции и переиспользовать внутри.
Если интресно писал на хабре тут: habr.com/ru/company/dbtc/blog/508134
Если интресно писал на хабре тут: habr.com/ru/company/dbtc/blog/508134
Да, скриптовый пайплайн имеет место быть.
Он более гибкий в плане написания кода.
Однако, используя декларативное описание — имеем более читаемый и структурированный код, получая из коробки возможность определить стадии по завершению шагов или всей сборки.
Именно поэтому, в статье я рекомендовал использовать на верхнем уровне именно его.
Кроме того, в декларативном пайплайне можно вставить в steps секцию script{ } и внутри уже писать практически любой код.
А переиспользовать степы можно с помощью функциональности shared libraries — www.jenkins.io/doc/book/pipeline/shared-libraries
Поэтому мы используем смешанный подход, опираясь на плюсы и declarative, и scripting подходов:
1) На верхнем уровне описание пайплайна в декларативном стиле
2) Используем shared libraries для переиспользования шагов, в которых используется скриптовое описание
3) И если вдруг понадобилось на верхнем уровне (декларативное описание) добавить скрипт, то вставляем его в секцию script{ }
Он более гибкий в плане написания кода.
Однако, используя декларативное описание — имеем более читаемый и структурированный код, получая из коробки возможность определить стадии по завершению шагов или всей сборки.
Именно поэтому, в статье я рекомендовал использовать на верхнем уровне именно его.
Кроме того, в декларативном пайплайне можно вставить в steps секцию script{ } и внутри уже писать практически любой код.
А переиспользовать степы можно с помощью функциональности shared libraries — www.jenkins.io/doc/book/pipeline/shared-libraries
Поэтому мы используем смешанный подход, опираясь на плюсы и declarative, и scripting подходов:
1) На верхнем уровне описание пайплайна в декларативном стиле
2) Используем shared libraries для переиспользования шагов, в которых используется скриптовое описание
3) И если вдруг понадобилось на верхнем уровне (декларативное описание) добавить скрипт, то вставляем его в секцию script{ }
А как быть с тестом, который иногда падает? Если, допустим, у вас race condition. Такой подход не позволит его отловить. Мне кажется тестовые запуски наоборот, должны падать если любой параметр не такой, как ожидается.
В статье, возможно, недостаточно сделан акцент на то, что компромисс с «дожатиями» у нас на стадии интеграционного тестирования при прогонах e2e сценариев.
Ловить race condition ошибки лучше на уровне unit и component тестов в изолированном окружении.
На уровне приемочных тестов поймать, конечно, можно, но это неэффективно, особенно с учетом отличий в конфигурации типовой тестовой среды и продакшена.
В e2e тестах микросервисной архитектуры намного больше “плавающих” ошибок связано с нестабильностью сети или проблемами с констистентностью распределенных хранилищ (вроде kafka/redis),
чем с race condition в одном сервисе.
Ловить race condition ошибки лучше на уровне unit и component тестов в изолированном окружении.
На уровне приемочных тестов поймать, конечно, можно, но это неэффективно, особенно с учетом отличий в конфигурации типовой тестовой среды и продакшена.
В e2e тестах микросервисной архитектуры намного больше “плавающих” ошибок связано с нестабильностью сети или проблемами с констистентностью распределенных хранилищ (вроде kafka/redis),
чем с race condition в одном сервисе.
Прошу прощения, но не мог пройти мимо :)
"Дожим — это перезапуск автотестов в рамках их одного прогона." напоминает фильм где юный хакер вбивает пароли в попытках утомить компьютер, после чего его впстят в систему ;-)
ЗЫ. Я прекрасно понимаю разницу между желанием и реальностью, и я бы не стал выкладывать эту часть, это же ваш внутренний компромис.
Вы правы, данный подход несет в себе риски.
Но это тоже самое, что бриться опасной бритвой. Опасность порезаться высока, если нет теоретической подготовки и мало опыта.
Перед тем как принять решение мы, конечно же, проанализировали по каким причинам у нас происходят падения.
Вместе с девопсами мы работаем над стабилизацией тестовых стендов. Также, вместе с членами команд разработки чиним автотесты и работаем над надежностью тестовых данных. Нестабильность также привносят UI автотесты.
Но, к сожалению, исправить все проблемы на 100% единовременно не представляется возможным.
Уверен, что наши проблемы не уникальны и множество инженеров с ними сталкиваются каждый день.
В данной статье мы не рекомендуем всем сразу бросаться «дожимать» автотесты. Применять данный подход следует осознанно и с осторожностью.
Хотелось показать, что не стоит зацикливаться на общепринятых подходах при решении задач. Встречаются случаи, когда и антипаттерны работают и работают очень хорошо.
А также, что jenkins pipeline инструмент очень гибкий, позволяющий решать различные сложные и необычные задачи.
Ведь некоторые инженеры обходят его стороной или используют только для стандартной сборки, деплоя или запуска тестов.
Но это тоже самое, что бриться опасной бритвой. Опасность порезаться высока, если нет теоретической подготовки и мало опыта.
Перед тем как принять решение мы, конечно же, проанализировали по каким причинам у нас происходят падения.
Вместе с девопсами мы работаем над стабилизацией тестовых стендов. Также, вместе с членами команд разработки чиним автотесты и работаем над надежностью тестовых данных. Нестабильность также привносят UI автотесты.
Но, к сожалению, исправить все проблемы на 100% единовременно не представляется возможным.
Уверен, что наши проблемы не уникальны и множество инженеров с ними сталкиваются каждый день.
В данной статье мы не рекомендуем всем сразу бросаться «дожимать» автотесты. Применять данный подход следует осознанно и с осторожностью.
Хотелось показать, что не стоит зацикливаться на общепринятых подходах при решении задач. Встречаются случаи, когда и антипаттерны работают и работают очень хорошо.
А также, что jenkins pipeline инструмент очень гибкий, позволяющий решать различные сложные и необычные задачи.
Ведь некоторые инженеры обходят его стороной или используют только для стандартной сборки, деплоя или запуска тестов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Jenkins Pipeline. Что это и как использовать в тестировании