Может возникнуть вопрос - что такое groovy.lang.Script? По сути это аналог Object для Groovy скриптов. Да, в Groovy код может быть не только в классах, но и в скриптах https://docs.groovy-lang.org/latest/html/documentation/#_scripts_versus_classes
5) В API своих классов не используем def, всегда объявляем типы явно.
def - это как var в Java, но опаснее, т.к в отличие от Java его можно использовать везде вместо указания типа. Как по мне - использовать def можно только для локальных переменных, т.е по сути я за подход Java.
6) кроме подсветки синтаксиса рекомендую периодически вызывать Inspect Code в IDEA, а лучше повесить его на commit. Не все проверки по умолчанию актуальны для Jenkins pipeline кода, лишние можно отключить.
7) ну и возвращаясь к тестам - по максимуму покрываем код в src тестами. Можно использовать JUnit и Mockito. Тесты при этом пишем на Groovy, чтобы воспользоваться преимуществом компактного синтаксиса Groovy.
to be continued
#devops #ci #unittests #jenkins #groovy
5) В API своих классов не используем def, всегда объявляем типы явно.
def - это как var в Java, но опаснее, т.к в отличие от Java его можно использовать везде вместо указания типа. Как по мне - использовать def можно только для локальных переменных, т.е по сути я за подход Java.
6) кроме подсветки синтаксиса рекомендую периодически вызывать Inspect Code в IDEA, а лучше повесить его на commit. Не все проверки по умолчанию актуальны для Jenkins pipeline кода, лишние можно отключить.
7) ну и возвращаясь к тестам - по максимуму покрываем код в src тестами. Можно использовать JUnit и Mockito. Тесты при этом пишем на Groovy, чтобы воспользоваться преимуществом компактного синтаксиса Groovy.
to be continued
#devops #ci #unittests #jenkins #groovy
Продолжим про тестирование кода джобов Jenkins.
Что еще у нас есть для тестирования.
8) JenkinsPipelineUnit - https://github.com/jenkinsci/JenkinsPipelineUnit По сути набор моков для запуска кода pipeline.
Что может:
а) запуск пайплайн из файла и из строки
б) передача параметров и переменных среды
в) проверка статуса выполнения джобы
г) моки для ряда методов pipeline
д) загрузка shared library
е) возможность добавлять свои моки на команды pipeline или конкретные вызовы sh
ж) печать стектрейса выполнения pipeline
з) сравнение стректрейсов, поиск по вхождению - можно искать были ли выполнена та или иная команда
Из мелких косяков - требует наследования тестового класса от BasePipelineTest, что вышло из моды с появлением Unit 4)))
Из более крупных косяков - по умолчанию многие команды Jenkins DSL не замоканы, при появлении такой команды джоба падает.
То что падает - это правильно, мы же тестируем pipeline. Но часто приходится писать свои mock, примеры: readYaml, readProperties, findFiles.
Mock по умолчанию - ничего не делать. echo выводит данные в лог на машине разработчика.
Могу рекомендовать с ремаркой - моки придется дописывать.
9) Jenkins Test Harness - https://www.jenkins.io/doc/developer/testing/,
Это интеграционное тестирование pipeline. В документации фреймворк предлагается для тех, кто разрабатывает Jenkins или плагины для него.
Можно ли использовать для тестирования своего pipeline и shared libraries - вопрос, дам на него ответ позже.
Коммиты в репозитории есть с 2016 года, но в документации по ссылке выше до сих пор встречаются TODO.
Подключение к тестам в примерах происходит через Rule из JUnit 4 - что тоже намекает.
Что он может:
а) б) в) из списка выше
г) мок для загрузки из SCM
д) проверка записей в логе - как я понял, это в большинстве случаев будет заменой Assert
е) загрузка файлов из среды разработки в workspace
Пока рекомендовать не могу, буду исследовать.
10) com.mkobit.jenkins.pipelines.shared-library - https://github.com/mkobit/jenkins-pipeline-shared-libraries-gradle-plugin,
Это плагин Gradle для разработки shared libraries. Включает в себя два предыдущих фреймворка. Есть тестовый репо https://github.com/mkobit/jenkins-pipeline-shared-library-example, если взять его как основу для своего проекта - получите из коробки подключение ряда библиотек Jenkins для declarative pipeline, некую версию gdsl и готовый проект, который содержит модульные и интеграционные тесты и проходит build.
Выглядит интересно для начала разработки, я к сожалению в свое время его упустил, по сути сделав аналогичный каркас)
Причем для разработки scripted pipeline мой каркас подходит лучше)
Пока рекомендовать не могу, учитывая комментарии выше.
11) любые тесты не на 100% заменяют запуск с реальными интеграциями. Как организовать интеграционное и функциональное тестирование pipeline, что для этого нужно?
а) создаем или копируем тестовый Java проект, который будем собирать. Ключевое требование - небольшой размер кода, чтобы сборка была быстрой и максимальное использование фичей pipeline. Использование настоящих проектов - плохо, т.к. создаются левые tags, build statuses, что может вводить разработчиков в заблуждение
б) тестовые джобы на Jenkins для всех созданных вами pipeline. Можно даже создать джобу, запускающую в параллель все эти джобы
в) тестовый проект SonarQube
г) тестовые репозитории в Nexus\Artifactory
д) тестовый проект на вашем Git сервере если джобы что-то делают в Git
е) важно: описываем в документации чек-лист - что и когда нужно тестировать при внесении изменений в pipeline
ж) придеживаемся описанных нами правил, это важно)
#devops #ci #unittests #jenkins #groovy
Что еще у нас есть для тестирования.
8) JenkinsPipelineUnit - https://github.com/jenkinsci/JenkinsPipelineUnit По сути набор моков для запуска кода pipeline.
Что может:
а) запуск пайплайн из файла и из строки
б) передача параметров и переменных среды
в) проверка статуса выполнения джобы
г) моки для ряда методов pipeline
д) загрузка shared library
е) возможность добавлять свои моки на команды pipeline или конкретные вызовы sh
ж) печать стектрейса выполнения pipeline
з) сравнение стректрейсов, поиск по вхождению - можно искать были ли выполнена та или иная команда
Из мелких косяков - требует наследования тестового класса от BasePipelineTest, что вышло из моды с появлением Unit 4)))
Из более крупных косяков - по умолчанию многие команды Jenkins DSL не замоканы, при появлении такой команды джоба падает.
То что падает - это правильно, мы же тестируем pipeline. Но часто приходится писать свои mock, примеры: readYaml, readProperties, findFiles.
Mock по умолчанию - ничего не делать. echo выводит данные в лог на машине разработчика.
Могу рекомендовать с ремаркой - моки придется дописывать.
9) Jenkins Test Harness - https://www.jenkins.io/doc/developer/testing/,
Это интеграционное тестирование pipeline. В документации фреймворк предлагается для тех, кто разрабатывает Jenkins или плагины для него.
Можно ли использовать для тестирования своего pipeline и shared libraries - вопрос, дам на него ответ позже.
Коммиты в репозитории есть с 2016 года, но в документации по ссылке выше до сих пор встречаются TODO.
Подключение к тестам в примерах происходит через Rule из JUnit 4 - что тоже намекает.
Что он может:
а) б) в) из списка выше
г) мок для загрузки из SCM
д) проверка записей в логе - как я понял, это в большинстве случаев будет заменой Assert
е) загрузка файлов из среды разработки в workspace
Пока рекомендовать не могу, буду исследовать.
10) com.mkobit.jenkins.pipelines.shared-library - https://github.com/mkobit/jenkins-pipeline-shared-libraries-gradle-plugin,
Это плагин Gradle для разработки shared libraries. Включает в себя два предыдущих фреймворка. Есть тестовый репо https://github.com/mkobit/jenkins-pipeline-shared-library-example, если взять его как основу для своего проекта - получите из коробки подключение ряда библиотек Jenkins для declarative pipeline, некую версию gdsl и готовый проект, который содержит модульные и интеграционные тесты и проходит build.
Выглядит интересно для начала разработки, я к сожалению в свое время его упустил, по сути сделав аналогичный каркас)
Причем для разработки scripted pipeline мой каркас подходит лучше)
Пока рекомендовать не могу, учитывая комментарии выше.
11) любые тесты не на 100% заменяют запуск с реальными интеграциями. Как организовать интеграционное и функциональное тестирование pipeline, что для этого нужно?
а) создаем или копируем тестовый Java проект, который будем собирать. Ключевое требование - небольшой размер кода, чтобы сборка была быстрой и максимальное использование фичей pipeline. Использование настоящих проектов - плохо, т.к. создаются левые tags, build statuses, что может вводить разработчиков в заблуждение
б) тестовые джобы на Jenkins для всех созданных вами pipeline. Можно даже создать джобу, запускающую в параллель все эти джобы
в) тестовый проект SonarQube
г) тестовые репозитории в Nexus\Artifactory
д) тестовый проект на вашем Git сервере если джобы что-то делают в Git
е) важно: описываем в документации чек-лист - что и когда нужно тестировать при внесении изменений в pipeline
ж) придеживаемся описанных нами правил, это важно)
#devops #ci #unittests #jenkins #groovy
GitHub
GitHub - jenkinsci/JenkinsPipelineUnit: Framework for unit testing Jenkins pipelines
Framework for unit testing Jenkins pipelines . Contribute to jenkinsci/JenkinsPipelineUnit development by creating an account on GitHub.
Привет!
Большинство DevOps pipeline, что я видел, мягко говоря не быстрые. Даже в теории чтобы просто докатить commit до ПРОМа нужны часы. Возможно у компаний с лучшими практиками DevOps это десятки минут. Можно ли быстрее?
Теоретически - да, и существует даже действующая модель:
https://medium.com/darklang/how-dark-deploys-code-in-50ms-771c6dd60671
https://docs.darklang.com/tutorials/first-dark-application#open-the-editor
В чем суть: ребята объединили язык, среду разработки, среду выполнения, хранилище данных и DevOps включая запуск тестов в одном продукте. В язык и среду встроены feature toggles, т.е. любое несовместимое изменение должно включаться по своему feature toggle. Естественно в выключенном состоянии. Это касается кода, таблиц в БД, новых библиотек. Таблицы и библиотеки получают новые версии, использование которых нужно явно включать. Сохранение срочки кода = commit. Невалидный код сохранить нельзя. Коммит идет сразу на ПРОМ после прогона тестов. Возможности языка ограничены, т.к. среда управляет инфраструктурой. По сути получаем serverless. Среда хранит логи и трасировки запросов, в т.ч. невалидные запросы, для последних можно быстро создать обработчик, т.е. получаем trace based development.
Мои выводы по результатам краткого знакомства.
1) концепт интересный, я бы даже сказал крутой
2) разработка в браузере смущает
3) возможности языка ограничены, но возможно спасают библиотеки
4) и главное - непонятно как с этим работать более чем одному разработчику и\или если число строк кода более 100. Если разработчики где-то будут пересекаться по коду - есть риск, что они не будут знать про чужие feature toggles и проверять их не будут. Или если фича большая, включает десятки функций и обработчиков, а у каждого свой feature toggle, спроектировать и проверить их в нужном порядке не совсем элементарная задача. В обоих случаях получаем feature toggle hell.
Но концепт красивый)
#devops #lang #concepts
Большинство DevOps pipeline, что я видел, мягко говоря не быстрые. Даже в теории чтобы просто докатить commit до ПРОМа нужны часы. Возможно у компаний с лучшими практиками DevOps это десятки минут. Можно ли быстрее?
Теоретически - да, и существует даже действующая модель:
https://medium.com/darklang/how-dark-deploys-code-in-50ms-771c6dd60671
https://docs.darklang.com/tutorials/first-dark-application#open-the-editor
В чем суть: ребята объединили язык, среду разработки, среду выполнения, хранилище данных и DevOps включая запуск тестов в одном продукте. В язык и среду встроены feature toggles, т.е. любое несовместимое изменение должно включаться по своему feature toggle. Естественно в выключенном состоянии. Это касается кода, таблиц в БД, новых библиотек. Таблицы и библиотеки получают новые версии, использование которых нужно явно включать. Сохранение срочки кода = commit. Невалидный код сохранить нельзя. Коммит идет сразу на ПРОМ после прогона тестов. Возможности языка ограничены, т.к. среда управляет инфраструктурой. По сути получаем serverless. Среда хранит логи и трасировки запросов, в т.ч. невалидные запросы, для последних можно быстро создать обработчик, т.е. получаем trace based development.
Мои выводы по результатам краткого знакомства.
1) концепт интересный, я бы даже сказал крутой
2) разработка в браузере смущает
3) возможности языка ограничены, но возможно спасают библиотеки
4) и главное - непонятно как с этим работать более чем одному разработчику и\или если число строк кода более 100. Если разработчики где-то будут пересекаться по коду - есть риск, что они не будут знать про чужие feature toggles и проверять их не будут. Или если фича большая, включает десятки функций и обработчиков, а у каждого свой feature toggle, спроектировать и проверить их в нужном порядке не совсем элементарная задача. В обоих случаях получаем feature toggle hell.
Но концепт красивый)
#devops #lang #concepts
Medium
How Dark deploys code in 50ms
Speed of developer iteration is the single most important factor in how quickly a technology company can move. In Dark, deploys take 50ms!