Пайплайны Jenkins - программирование и настройка. Загружаемые модули. Цикл "Многопоточный CI для 1С", часть 5

0. Vladimir Litvinenko 2365 17.03.20 07:49 Сейчас в теме
Рассмотрим создание пайплайнов Jenkins и библиотек собственных методов, язык Groovy, подходы к хранению настроек и обработке ошибок.

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. kuzyara 1042 17.03.20 09:06 Сейчас в теме
Любое исправление в коде пайплайна требует сделать коммит в репозиторий и отправку его на git-сервер.
...
переключиться обратно на задание кода через веб-интерфейс

Частично спасает https://www.jdoodle.com/execute-groovy-online/
А вообще да, отладка на грувях - это мрак...
SinoSin; Vladimir Litvinenko; +2 Ответить
3. ImHunter 197 17.03.20 12:02 Сейчас в теме
(1) Мда, особенно @NonCPS "радуют" время от времени.
8. Vladimir Litvinenko 2365 17.03.20 16:40 Сейчас в теме
(3) Плагин "Permissive Script Security", настройка которого рассмотрена в разделе, посвященному таймаутам операций, ведь решает эту проблему. И директива @NonCPS становится ненужна.

Или есть случаи, когда при включенном плагине всё равно требуется @NonCPS?
12. ImHunter 197 18.03.20 06:31 Сейчас в теме
(8) Гм... Приму к сведению про плагин.
Случаев уже нет, т.к. пайплайны и библиотеки больше не допиливаю.
Кстати, начал готовить статью - тоже свои наработки выложу.
Vladimir Litvinenko; +1 Ответить
13. Vladimir Litvinenko 2365 18.03.20 11:02 Сейчас в теме
(12) Подпишусь тогда )) Информация по этой теме всегда интересна.
2. Dach 296 17.03.20 11:30 Сейчас в теме
Отличная статья. Ваши статьи по devops реально как справочник инженера! Синтаксис groovy рассмотрен чуть ли не подробнее, чем в известной и не очень бесплатной книжке от все мы знаем кого. Очень радует, что Вы делитесь этими знаниями на вполне доступном языке!

Попробую дать обратную связь.

1. Интересна параметризация скриптов дженкинса. В статье это рассмотрено в виде отдельного модуля. А что если у меня 3 базы, каждую хочу обновлять из разных хранилищ или разных входящих cf? Ну то есть хочется пример, где есть функция сборки и ей на вход подается все что нужно, а все что нужно берется из файлов: дженкинсБД1, дженксинсБД2, дженкинсБД3. Надеюсь, понятно объяснил.

В идеале неплохо бы рассмотреть методику программирования функций для каждого шага, заворачивание этих функций в стэйдж и параметризацию каждого стейджа по отдельности или целиком.

2. Хотелось бы увидеть примеры и больше описания по каждой секции: stage, post и т.д. Зачем нужны секции, последовательность обработки их и т.д.

3. Хотелось бы увидеть сквозной пример для задачи деплоя.

Например:

- запускаем, обновляемся из гит-репо;
- удаляем зависшие сеансы 1С (вызвав произвольный cmd-скрипт например);
- чистим кэш 1С;
- восстанавливаем БД из файла или из бэкапа на СУБД;
- обновляем из хранилища или внешнего cf;
- обновляем в режиме предприятия;
- запускаем xdd;
- запускаем bdd;
- собираем артефакты для наших "отчетных" плагинов;
- выгружаем ошибки ЖР с момента старта сборки (как отдельный артефакт)
- отправляем сообщения на почту указанным адресатам и на канал в маттермост
Vladimir Litvinenko; +1 Ответить
4. Vladimir Litvinenko 2365 17.03.20 12:28 Сейчас в теме
(2) Спасибо за обратную связь!

чуть ли не подробнее, чем в известной и не очень бесплатной книжке

Мне бы не хотелось устраивать конкуренцию платных и бесплатных материалов )) Я проходил курс, по которому потом была написана эта книга в 2017 году и думаю неправильно было бы просто дублировать информацию из него. Поэтому стараюсь писать об опыте, полученном после этого. В первую очередь об автоматизации построения инфраструктуры для CI и тестирования с уклоном в переносимость между разными серверами. И о мало освещенных в других источниках особенностях применения Jenkins.

Материалы, о которых Вы говорите тоже рекомендую к изучению. Там основы работы Докер разбирались. Но у них несколько иная направленность.

У меня была идея развить тему для тестирования больших типовых конфигураций. Точнее выполняемых в них доработок, потому что по практике сталкиваюсь только с такой задачей. С самописками всегда всё проще, там можно и напрямую через git работать без каких-либо проблем.


Интересна параметризация скриптов дженкинса. В статье это рассмотрено в виде отдельного модуля. А что если у меня 3 базы, каждую хочу обновлять из разных хранилищ или разных входящих cf?

Я сам такого не делал в полноценном виде )) Для каждого проекта был свой CI-контур.

В качестве решения могу предложить такой подход. Можно скопировать репозиторий (сделать для нового проекта новый репозиторий), сделать отдельные настройки узлов, включая их имена, разворачивать отдельные машинки (сборочные узлы). И у вас будет новый контур для отдельного проекта. Для каждого проекта либо выделить отдельную физическую машинку (обычной рабочей станции или ноутбука по-мощнее будет достаточно), либо организовать то же самое на мощном сервере и разворачивать на ней все виртуалки. На едином сервере Jenkins сделать для отдельных проектов отдельные каталоги. В этом случае с одного сервера Jenkins можно управлять разными проектами.

Например у меня сейчас так организован механизм для разработки "боевого" CI для рабочего проекта и проетка для этих публикаций. Они могут управляться через один сервер Jenkins. В настройках репозитория указывается, из каких папок задач Jenkins архивировать и разворачивать настройки. Это было рассмотрено в прошлой публикации в блоке "Архивация и включение в состав репозитория настроек узлов и задач"

Альтернатива - посмотреть в сторону Докер и хостовой операционной системы на Linux, а не на Windows (на Windows контейнеры тоже есть, но большие и неудобные). В этом случае возможна контейнирезация самого Jenkins. Но мне это тоже только предстоит изучить.

Хотелось бы увидеть примеры и больше описания по каждой секции: stage, post и т.д. Зачем нужны секции, последовательность обработки их и т.д.


Ок, понял. Постараюсь дополнить этой информацией эту публикацию, так как она соответствует рассматриваемой здесь теме. На отдельную публикацию рассмотрение этого вопроса не тянет, но здесь можно сделать дополнение. Попробую ещё ссылки на видео найти. Помню где-то видел хорошее описание этого вопроса.


Хотелось бы увидеть сквозной пример для задачи деплоя.


Да, это планировал опубликовать. Если пайплайн будет сначала опубликован на Гитхабе подойдёт?
Все необходимые для этого методы уже в репозитории. В модуле DBManage есть методы deleteConnectionsViaRas , forbidScheduledJobsViaRas, dropSQLand1CDatabaseIfExists. Остаётся только передать им параметры, считываемые из настроек - переменных окружения из модуля SetEnvironmentVars. И последовательно вызвать.

Можно применить и альтернативу и работать через библиотеки OneScript. Я их сейчас не применяю только потому, что программировать механизмы показалось проще и логичнее пользуясь непосредственно поддерживаемым Jenkins языком программирования. Groovy довольно гибкая и понятная штука и с Java дружит. Но по крайней мере на начальном этапе знакомства с Jenkins имеет смысл применять OneScript и писать код на 1С.
5. Dach 296 17.03.20 12:49 Сейчас в теме
(4) Да, публикация на гитхабе пайплайна подойдет.

Насчет применения механизмов в дженкинс или вызовов библиотек onescript - а мне вот как раз наоборот, больше нравится второй вариант. Опять-таки по причине того, что я могу иметь одну и ту же функцию для конкретного шага, но при этом настройки считываются из ассоциированного с шагом json. Сквозной пример наверное лучше в виде отдельной публикации оформить
6. Vladimir Litvinenko 2365 17.03.20 13:14 Сейчас в теме
(5)
Насчет применения механизмов в дженкинс или вызовов библиотек onescript - а мне вот как раз наоборот, больше нравится второй вариант.

Да, это более универсальное решение для специалистов 1С. И это позволит при необходимости проще переехать на другой CI-сервер. Например на Gitlab CI. Я когда-то все механизмы так делал ещё из расчёта, что так проще передавать знания коллегам. Но за неимением других специалистов, которые рядом занимались бы разработкой инфраструктуры и пайплайнов для CI перешел к Groovy и максимально редким вызовам bash ))

Но тут опять же такой момент, что работа через OneScript не рассмотрена сейчас только ленивым )) Не хотелось бы заниматься копипастой и фактически дублировать материал. Не люблю копипасту - итак слишком много на Инфостарте )) Подход с "программированием" в Jenkins вместо вызова скриптов мало где разбирается. Кроме того от процедур и функций гораздо проще получать результат обработки, чем общаться со внешними скриптами посредством stdin/stdout, временных файлов или кодов возврата.

квозной пример наверное лучше в виде отдельной публикации оформить

Вот думаю, что она зайдёт только тем, кто уже хорошо знает Vanessa Automation или Vanessa ADD и при этом работает с ERP/КА/УТ.

То есть получается дисбаланс. До этого тема разжёвывается для начинающих, а потом резкий переход к коду без скриншотов )) Записывать видео к сожалению не имею времени и возможности.

Посмотрим, может быть будет достаточно комментариев к коду ) Потом уже можно будет обернуть в публикацию.
11. Vladimir Litvinenko 2365 17.03.20 23:01 Сейчас в теме
(5) Добавил раздел "Элементы дакларативного пайплайна" с более подробным описанием отдельных составляющих Jenkisfile:

https://infostart.ru/public/1210995/#declarative_pipeline_elements
7. awk 717 17.03.20 14:56 Сейчас в теме
(4)
Интересна параметризация скриптов дженкинса. В статье это рассмотрено в виде отдельного модуля. А что если у меня 3 базы, каждую хочу обновлять из разных хранилищ или разных входящих cf?

Я сам такого не делал в полноценном виде )) Для каждого проекта был свой CI-контур.

В качестве решения могу предложить такой подход.


Я реализовал проще... Разбил все на три части:

1. Проекты с исходниками, тестами и т.п. - результат CF
2. Проект с стандартными дженкинсфайлами - для обновлений - 1 джоб для обновлений (параметоризированный)
3. Джобы триггеры, которые запускают джоб из п.2 с параметрами
Vladimir Litvinenko; +1 Ответить
9. Kosstikk 86 17.03.20 17:22 Сейчас в теме
Значительно усложняется отладка кода. Любое исправление в коде пайплайна требует сделать коммит в репозиторий и отправку его на git-сервер. Только после этого Jenkins сможет получить новую версию кода. Это приводит к следующим эффектам:

Любое даже самое незначительное исправление в процессе отладки порождает лишний коммит в репозиторий. Таким ветка, в которой ведется разработка, замусоривается и в ней становится сложно ориентироваться.
Часто можно внести изменение в код, но забыть сделать отправку на git-сервер. В этом случае запуск задачи с целью отладки окажется выполнен зря. Это может отнять много времени.


git add . && git commit -m "отладка" --amend && git push -f


либо плагин для Vscoda, "Jenkins Jack"
Vladimir Litvinenko; awk; +2 Ответить
10. Vladimir Litvinenko 2365 17.03.20 19:07 Сейчас в теме
(9) О, кстати, хороший приём, спасибо. Точно лучше чем, с ребейзом возиться )) Только ветку на Гитлабе надо незащищенной сделать, чтобы push --force работал.

Я правда из Visual Studio Code при отладке пайплайнов коммиты делаю. Не уверен, что там можно удобно настроить выполнение такой команды в одно нажатие. Но наверное каким-то макросом можно.

Ещё один вариант - временно указать в задаче Jenkins получение изменений из "локального" репозитория - прямо с жесткого диска. Делать коммиты локально, вообще без пуша. Потом можно сделать git reset --mixed на метку и уже потом коммит с пушем. Но это из той же оперы что и ребейз. Попробую лучше Ваш подход.
14. Kosstikk 86 19.03.20 17:14 Сейчас в теме
(10) ctrl + ~, закладка TERMINAL в Vscode. Mожно через ctrl+shift+p ввести 'default shell' и указать bash, при работе в Windows.
Оставьте свое сообщение
Вопросы с вознаграждением