Комментарии 7
Спасибо, пригодится в качестве шаблона.
Спасибо, сохранил себе. Небольшая ремарка-правильно называть "свит", а не "сьют".
А в чем преимущество такого подхода перед, например, freestyle job? Кроме того, что этот jenkinsfile можно хранить в vcs.
С моей точки зрения, freestyle job используется при "несложных" проектах. Если же нужно, что-то более кастомное, то тут нам на помощь приходит Pipeline. Пример: отправка уведомления на почту. В freestyle нет возможности указать тело сообщения, в Pipeline - можно.
Ну и если верить официальному сайту Jenkins к преимуществам Pipeline относится:
Код: Pipelines реализованы в коде и обычно возвращаются в систему управления версиями, что дает командам возможность редактировать, просматривать и итерировать конвейер доставки.
Долговечность: Pipelines могут выдерживать как запланированные, так и незапланированные перезапуски контроллера Jenkins.
Пауза: Pipelines могут при желании останавливаться и ждать ввода или утверждения человеком, прежде чем продолжить выполнение конвейера.
Универсальность: Pipeline поддерживает сложные требования CD реального мира, включая возможность разветвления/соединения, зацикливания и выполнения работы параллельно.
Расширяемость: плагин Pipeline поддерживает настраиваемые расширения для своего DSL (domain-specific language) и несколько вариантов интеграции с другими плагинами.
Также более детально они рассказывают о разнице в видео: https://youtu.be/IOUm1lw7F58
Смотрите, что я увидел.
Вы для автотестов предлагаете писать pipeline, при этом в вашем примере я не вижу ничего такого, чего нельзя было бы сделать через freestyle job. Если я перепишу ваш пайплайн на freestyle job, он разве станет "несложным"?
Как инженер, я хотел бы видеть какую-то аргументацию посильнее, чем Если же нужно, что-то более кастомное, то тут нам на помощь приходит Pipeline. Пример: отправка уведомления на почту. В freestyle нет возможности указать тело сообщения, в Pipeline - можно. Как минимум по той причине, что для тех же уведомлений на почту есть плагин Email Extension (https://plugins.jenkins.io/email-ext/), который позволяет настраивать что угодно и сейчас ставится чуть ли не по дефолту. Аналогично и с плагином для слака — полная кастомизация (справедливости ради добавлю, что через пайплайн можно настроить еще лучше, но для автоматизации это излишне — нам же по сути нужен статус прогона и ссылка на него).
Аргументы с официального сайта, конечно, хороши, но это не ваш опыт. Сравните хотя бы картину пайплайна по ссылке с тем, что описано у вас. И далее по списку преимуществ — часто ли у вас перезапускается контроллер Jenkins, часто ли вам нужно писать реально сложные пайплайны с ветвлениями и зацикливаниями, часто ли вы используете настраиваемые расширения для своего DSL? Почему-то кажется, что вообще нет. Что по всем этим пунктам ответ будет отрицательный. И в таком случае получается, что у такого подхода для автотестов нет преимущества. Для полноценного процесса развертки + тестирования + деплоя — да. Но статья не про это. Ну и следом был бы вопрос — а чем этот подход лучше написания скрипта на груви?
Не поймите неправильно, статья отличная, но для автоматизации тестирования я только один аргумент увидел — хранение в vcs. Но и на это можно возразить, что если джобы настолько сложные, что их нужно где-то хранить, то скорее всего что-то делаете не так.
Все верно, данный пример можно реализовать не только через 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. прошу прощения, если несколько сумбурно. Это очень похожий вопрос про сам код. Насколько сложным/простым он должен быть и стоит ли гнаться за сложностью как у разработчиков.
Jenkins Pipeline для АТ