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