Все верно, данный пример можно реализовать не только через Pipeline, это базовый набор от чего можно оттолкнуться, если будет принято решение использовать Pipeline. А вот использовать его или нет, в статье про это не было.
Если говорить про мой опыт, то он разный и с Pipeline и без него.
На одном из проектов был кейс по переходу от mvn проекта на Pipeline? Сказать, что mvn-проект перестал справляться? - Нет. Одним из аспектов выбора инструментов - это то кто эти инструменты будет поддерживать и каким стеком они владеют. В моем варианте - это были разработчики с Pipeline. Вторым аспектом стало наличие нескольких стендов. Автотесты отличались только содержанием в файле с конфигами. Соответственно, мы не тратили время на создание для каждого стенда freestyle job, которые дублировали друг друга, а переиспользовали Pipeline, который подтягивался из GitLab.
Также аспектом влияющим на то, что Pipeline надо знать (я не говорю про использовать, но получение навыка включает в себя опыт) является потребность быть "в рынке". И когда у Заказчика используется Pipeline, то мы вынуждены быть к этому готовы. Но это уже следующий глобальный вопрос. Возможно, даже не про Pipeline или frestyle job, а Jenkins или ,например, GitLab CI.
Ну и по поводу нотификации нас интересует не только результат, но и как оно прошло. Я формирую в письме сразу ссылку на allure-отчет. А также иногда отправляю в теле сообщения Junit-отчет.
По поводу сложности скрипта, что его нужно хранить. В любом случае его восстановление- это время, а значит деньги. В моем опыте были случаи когда сервер с Jenkins падал и требовалось восстановление. Также бывают кейсы, когда автотесты переезжали на ресурсы Заказчика и доступа к редактированию сборки у нас не было. И в случае необходимости если бы это был freestyle job пришлось бы обращаться к админам Заказчика, а это не всегда быстро.
А также большинство проектов однотипные и достаточно просто скопировать файл с Pipeline при переходе на новый проект.
И повторюсь, в статье ни коим образом не говорится, что надо обязательно использовать только Pipline. Моя статья про то, с чего начать, если мы решили использовать Pipeline.
P.s. прошу прощения, если несколько сумбурно. Это очень похожий вопрос про сам код. Насколько сложным/простым он должен быть и стоит ли гнаться за сложностью как у разработчиков.
С моей точки зрения, freestyle job используется при "несложных" проектах. Если же нужно, что-то более кастомное, то тут нам на помощь приходит Pipeline. Пример: отправка уведомления на почту. В freestyle нет возможности указать тело сообщения, в Pipeline - можно.
Код: Pipelines реализованы в коде и обычно возвращаются в систему управления версиями, что дает командам возможность редактировать, просматривать и итерировать конвейер доставки.
Долговечность: Pipelines могут выдерживать как запланированные, так и незапланированные перезапуски контроллера Jenkins.
Пауза: Pipelines могут при желании останавливаться и ждать ввода или утверждения человеком, прежде чем продолжить выполнение конвейера.
Универсальность: Pipeline поддерживает сложные требования CD реального мира, включая возможность разветвления/соединения, зацикливания и выполнения работы параллельно.
Расширяемость: плагин Pipeline поддерживает настраиваемые расширения для своего DSL (domain-specific language) и несколько вариантов интеграции с другими плагинами.
Спасибо за комментарий, даже никогда не задумывалась как Suite корректно произносится. Будем избавляться от жаргонизмов и называть своими словами - тестовый набор)
Все верно, данный пример можно реализовать не только через Pipeline, это базовый набор от чего можно оттолкнуться, если будет принято решение использовать Pipeline. А вот использовать его или нет, в статье про это не было.
Если говорить про мой опыт, то он разный и с Pipeline и без него.
На одном из проектов был кейс по переходу от mvn проекта на Pipeline? Сказать, что mvn-проект перестал справляться? - Нет. Одним из аспектов выбора инструментов - это то кто эти инструменты будет поддерживать и каким стеком они владеют. В моем варианте - это были разработчики с Pipeline.
Вторым аспектом стало наличие нескольких стендов. Автотесты отличались только содержанием в файле с конфигами. Соответственно, мы не тратили время на создание для каждого стенда freestyle job, которые дублировали друг друга, а переиспользовали Pipeline, который подтягивался из GitLab.
Также аспектом влияющим на то, что Pipeline надо знать (я не говорю про использовать, но получение навыка включает в себя опыт) является потребность быть "в рынке". И когда у Заказчика используется Pipeline, то мы вынуждены быть к этому готовы. Но это уже следующий глобальный вопрос. Возможно, даже не про Pipeline или frestyle job, а Jenkins или ,например, GitLab CI.
Ну и по поводу нотификации нас интересует не только результат, но и как оно прошло. Я формирую в письме сразу ссылку на allure-отчет. А также иногда отправляю в теле сообщения Junit-отчет.
По поводу сложности скрипта, что его нужно хранить. В любом случае его восстановление- это время, а значит деньги. В моем опыте были случаи когда сервер с Jenkins падал и требовалось восстановление.
Также бывают кейсы, когда автотесты переезжали на ресурсы Заказчика и доступа к редактированию сборки у нас не было. И в случае необходимости если бы это был freestyle job пришлось бы обращаться к админам Заказчика, а это не всегда быстро.
А также большинство проектов однотипные и достаточно просто скопировать файл с Pipeline при переходе на новый проект.
И повторюсь, в статье ни коим образом не говорится, что надо обязательно использовать только Pipline. Моя статья про то, с чего начать, если мы решили использовать Pipeline.
P.s. прошу прощения, если несколько сумбурно. Это очень похожий вопрос про сам код. Насколько сложным/простым он должен быть и стоит ли гнаться за сложностью как у разработчиков.
С моей точки зрения, freestyle job используется при "несложных" проектах. Если же нужно, что-то более кастомное, то тут нам на помощь приходит Pipeline. Пример: отправка уведомления на почту. В freestyle нет возможности указать тело сообщения, в Pipeline - можно.
Ну и если верить официальному сайту Jenkins к преимуществам Pipeline относится:
Код: Pipelines реализованы в коде и обычно возвращаются в систему управления версиями, что дает командам возможность редактировать, просматривать и итерировать конвейер доставки.
Долговечность: Pipelines могут выдерживать как запланированные, так и незапланированные перезапуски контроллера Jenkins.
Пауза: Pipelines могут при желании останавливаться и ждать ввода или утверждения человеком, прежде чем продолжить выполнение конвейера.
Универсальность: Pipeline поддерживает сложные требования CD реального мира, включая возможность разветвления/соединения, зацикливания и выполнения работы параллельно.
Расширяемость: плагин Pipeline поддерживает настраиваемые расширения для своего DSL (domain-specific language) и несколько вариантов интеграции с другими плагинами.
Также более детально они рассказывают о разнице в видео: https://youtu.be/IOUm1lw7F58
Спасибо за комментарий, даже никогда не задумывалась как Suite корректно произносится. Будем избавляться от жаргонизмов и называть своими словами - тестовый набор)