Введение в CI для 1С

27.12.17

Разработка - Математика и алгоритмы

Значение роли тестирования при разработке ПО трудно переоценить, его применение позволяет повысить надёжность продукта и улучшить качество кода. Для продуктов для платформы 1С:Предприятие существует ряд инструментов для проведения тестирования, в том числе и от самого вендора. Но, также появились открытые инструменты, реализующие мировые практики проведения тестирования (проверки продукта), поддерживаемые сообществом. В этой статье описаны базовые принципы, которые необходимо понимать перед началом применения этих инструментов.

Предисловие

В последнее время в среде разработчиков всё чаще стали встречаться термины TDD (Test Driven Development), BDD (Behavior Driven Development), CI (Continuous Integration), git и всё это в контексте тестирования 1С-конфигураций. Мало кто из разработчиков 1С представляет, а тем более, понимает, что это такое, зачем это нужно, как это использовать и как с этим жить. Особую актуальность эти технологии приобрели с выходом нового инструмента от 1С: EDT (Enterprise Development Tools), в котором 1С решила отказаться от использования хранилища конфигурации в пользу git.

С момента, когда я узнал о существовании альтернативных способов разработки 1С-конфигураций, тестирования и хранения кода, передо мной начала возникать масса вопросов, наверное, главными из которых были "почему?" и "как?". Например:

  • Почему нужно использовать другую систему хранения кода?
  • Почему выбран именно git в качестве системы хранения кода?
  • Как git и CI помогут тестировать решение?
  • Как организовать процесс разработки так, чтобы можно было применять данные технологии на практике?
  • и т. д.

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

В данной статье я опишу, откуда возникла потребность в CI и как можно осуществлять тестирование конфигураций 1С имеющимися средствами. Здесь я намеренно не буду описывать существующие инструменты проведения тестирования конфигураций, цель данной статьи: дать общее представление о механизмах, используемых в CI.

Благодарности

Хочу выразить благодарность участникам gitter-каналов oscript-library, vanessa-behavior, vanessa-runner, а также Андрееву Михаилу.

Отдельную благодарность выражаю Евгению Сосне за неоценимую помощь в практическом освоении инструментов CI.

Проблема

История развития методов разработки конфигураций 1С достаточно долгая, с самого начала практики разработки конфигураций прикладными разработчиками и до наших дней эти методы претерпели немало изменений. Изначально разработка конфигураций не предполагала коллективного участия, затем сложность конфигураций росла и потребовалось решать проблемы взаимодействия нескольких разработчиков. В результате чего появилось хранилище конфигурации. Итогом этого стало появление возможности создавать сложные решения, содержащие в себе многие тысячи строк кода. Их развитие стало нести определённые риски для уже реализованных частей продукта: доработки одних частей конфигурации могли "сломать" исправно работающие механизмы в других частях конфигурации. С другой стороны, степень доверия к 1С:Предприятию постоянно увеличивалось отчего 1С начала проникать в сферы деятельности компаний, требующие постоянной доступности предоставляемого сервиса. Критичность качества конфигураций и процесса обновления старых версий конфигураций на новые возросли пропорционально критичности решаемых при помощи 1С задач. Поэтому возникла задача обеспечения более качественной разработки и тестирования как самого продукта, так и процесса обновления эксплуатируемых баз данных.

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

Решение

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

Это, в принципе, годное решение, но несёт в себе ряд недостатков:

  1. Разработчики со временем забывают, что делают тестирующие обработки, а сами тестирующие обработки со временем устаревают. В итоге тестирование проводится неполно или некорректно.
  2. Запуск обработок требует отдельных усилий разработчика, непосредственно не связанных с созданием ПО, что сами разработчики встречают без особого энтузиазма. В итоге, без надлежащего контроля этот процесс имеет немалые шансы отмереть. Тестирование будет проводиться, в лучшем случае, перед обновлением и выявлять проблемы достаточно поздно, когда разработчик уже успешно забудет контекст задачи "поломавшей" продукт, если такую задачу вообще можно будет выявить.

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

Давайте пока остановимся и попытаемся сформулировать основные требования к процессу тестирования:

  1. Тестирование должно производиться только тогда, когда разработчик произвёл логически законченные изменения кода, а не в произвольный момент, когда разработчику очевидно, что код в его текущем состоянии и так провалит тесты.
  2. Тестирование должно производиться автоматически, без участия разработчика, возможно даже в нерабочее время. Причём разработчику совершенно необязательно следить за результатами тестов, ему достаточно получать уведомления только при наличии не прошедших (упавших) тестов, причём, желательно, вызванных только его изменениями.
  3. Должна быть возможность проводить тестирование под управлением разных ОС и разных версий платформы 1С:Предприятие.

Теперь попытаемся понять, как можно удовлетворить вышеописанные требования в реалиях разработки.

Определение момента осуществления тестирования

Так как мы говорим о современной разработке средствами 1С, то предполагаем, что в процессе разработки используется хранилище конфигурации. Моментом начала тестирования может служить факт помещения кода в хранилище, других событий готовности кода к тестированию у платформы нет. Альтернативой может выступать только ручное "указание" разработчика на необходимость начала тестирования, но мы для себя определили, что процесс тестирования должен стартовать без его участия.

Отсюда следует, что для того, чтобы тестирование выявляло ошибки как можно раньше, разработчику необходимо как можно чаще помещать изменения в хранилище. Наверное? лишним будет напоминать, что помещаемый в хранилище код должен быть законченным и рабочим, по крайней мере по мнению самого разработчика, ведь результатом тут же могут воспользоваться его коллеги.

Порядок проведения тестирования

Теперь надо определиться с алгоритмом тестирования. На данный момент мы имеем:

  • Конфигурацию в хранилище;
  • Обработки, тестирующие нашу конфигурацию.

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

Затем нужно получить тестовую базу, которую будем тестировать. Это, опять же, можно сделать при помощи запуска конфигуратора с ключом LoadCfg, которой в качестве параметра указать только что полученный файл конфигурации.

Также можно просто создать базу данных, подключенную к хранилищу и проводить тестирование на ней.

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

Наконец, можно запускать тесты. Запуск тестов можно выполнять также штатным способом, используя запуск 1С:Предприятия с ключом Execute.

Результаты тестирования обработка может записывать в какой-нибудь файл, который впоследствии можно анализировать и, в результате, выполнять определённые действия, например рассылать почтовые уведомления.

Запуск тестирования

Далее нужно понять, как автоматически стартовать сам процесс тестирования.

Самый простой и очевидный способ: попробовать создать сценарий (bat/sh) и запускать его по расписанию. Для этого можно использовать cron, планировщик задач windows или какое-либо другое средство запуска задач по расписанию. Этот способ имеет ряд недостатков в виде недостаточной визуализации результатов работы запускаемых скриптов, сложности администрирования и обеспечения работы и взаимодействия скриптов на разных компьютерах сети.

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

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

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

Jenkins

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

По сути jenkins представляет собой достаточно продвинутый шедуллер запуска задач на любых доступных компьютерах. Возможность управления задачами на разных компьютерах сети в jenkins реализовано при помощи следующей архитектуры: В сети выделяется компьютер, на который устанавливается управляющий сервер jenkins. Этот компьютер называется главным, или мастер-узлом (master-node), всё управление jenkins'ом осуществляется при помощи web-интерфейса, предоставляемого этим сервером. Далее, на любой компьютер сети может быть установлена отдельная служба jenkins, который сделает этот компьютер дочерним узлом (slave-node). Эта служба необходима для того, чтобы jenkins мог выполнять код на этом компьютере.

В общем случае, задача, созданная на jenkins'е не привязана к какому-либо конкретному узлу и может быть выполнена на любом доступном узле. При помощи меток узлов в задаче можно сократить количество доступных для выполнения задачи узлов. Мало того, возможно выполнение разных частей одной задачи на разных узлах.

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

Сборка

Итак, располагая имеющейся информацией, уже можно осуществить сборку и тестирование продукта по определённому ранее алгоритму:

  1. На компьютере, где развернута платформа 1С:Предприятие нужно развернуть дочерний узел jenkins, задать ему метку, обозначающую наличие на узле платформы 1С определённой версии.
  2. Создать задачу, в которой указать, что она должна выполняться на узле с необходимой версией платформы. В задаче выполнить запуск конфигуратора с операциями:
    • создания пустой базы данных;
    • сохранения конфигурации из хранилища в файл;
    • запуск обработки, производящей первичное заполнение базы данными;
    • запуск обработки, производящей тестирование конфигурации;
    • анализа результатов тестирования и установки статуса сборки;
    • при желании здесь же можно осуществлять формирование комплектов поставки, развертывание релиза на рабочей базе и другие необходимые действия.

Задание меток у узлов и их указание в задачах необходимо по причине того, что задача может быть выполнена на любом узле jenkins, в том числе и том, где платформа 1С не установлена.

Каталог с хранилищем конфигурации должен быть доступен по сети или хранилище должно предоставляться сервером хранилища конфигурации. Запуск задания можно осуществлять по факту изменения файла базы хранилища конфигурации.

Обработки, выполняющие заполнение базы данными и тестирование можно выложить на общедоступный ресурс сети и брать их оттуда. Анализ результатов можно проводить любым доступным вам способом. Главное помнить, что "правильного" решения не существует, каждый случай уникальный, а архитектура решения для каждого случая разрабатывается своя.

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

Итоги

Описанный здесь процесс сборки и тестирования продукта можно использовать на практике и сейчас, однако есть уже готовые средства, которые существенно облегчают техническую реализацию этого процесса. В любом случае, дальнейшее описание процесса CI, будет основываться на описанных здесь базовых принципах. В следующих статьях я опишу используемые инструменты для тестирования продуктов на базе 1С:Предприятие, расскажу про использование git в процессе разработки и остановлюсь чуть подробнее на автоматизации процесса посредством jenkins.

Ссылки

Первая часть: Введение в CI для 1С

Вторая часть: Использование git при разработке на 1С

CI Continuous Integration Тестирование Автоматизация

См. также

Математика и алгоритмы Программист Платформа 1C v8.2 Конфигурации 1cv8 Россия Абонемент ($m)

На написание данной работы меня вдохновила работа @glassman «Переход на ClickHouse для анализа метрик». Автор анализирует большой объем данных, много миллионов строк, и убедительно доказывает, что ClickHouse справляется лучше PostgreSQL. Я же покажу как можно сократить объем данных в 49.9 раз при этом: 1. Сохранить значения локальных экстремумов 2. Отклонения от реальных значений имеют наперед заданную допустимую погрешность.

1 стартмани

30.01.2024    2729    stopa85    12    

36

Математика и алгоритмы Бесплатно (free)

Разработка алгоритма, построенного на модели симплекс-метода, для нахождения оптимального раскроя.

19.10.2023    6618    user1959478    50    

36

Математика и алгоритмы Разное Платформа 1С v8.3 Конфигурации 1cv8 Россия Абонемент ($m)

Расширение (+ обработка) представляют собою математический тренажер. Ваш ребенок сможет проверить свои знание на математические вычисление до 100.

2 стартмани

29.09.2023    2659    maksa2005    8    

25

Математика и алгоритмы Инструментарий разработчика Программист Платформа 1С v8.3 Мобильная платформа Россия Абонемент ($m)

Что ж... лучше поздно, чем никогда. Подсистема 1С для работы с регулярными выражениями: разбор выражения, проверка на соответствие шаблону, поиск вхождений в тексте.

1 стартмани

09.06.2023    10162    7    SpaceOfMyHead    18    

61

Математика и алгоритмы Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Три задачи - три идеи - три решения. Мало кода, много смысла. Мини-статья.

03.04.2023    3935    RustIG    9    

25

Механизмы платформы 1С Математика и алгоритмы Программист Платформа 1С v8.3 Россия Бесплатно (free)

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

23.11.2022    3039    gzharkoj    14    

24

Математика и алгоритмы Программист Платформа 1С v8.3 Россия Абонемент ($m)

Обычно под распределением понимают определение сумм пропорционально коэффициентам. Предлагаю включить сюда также распределение по порядку (FIFO, LIFO) и повысить уровень размерности до 2-х. 1-ое означает, что распределение может быть не только пропорциональным, но и по порядку, а 2-ое - это вариант реализации матричного распределения: по строкам и столбцам. Возможно вас заинтересует также необычное решение этой задачи через создание DSL на базе реализации текучего интерфейса

1 стартмани

21.03.2022    8869    7    kalyaka    11    

44
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. TODD22 19 22.11.17 11:02 Сейчас в теме
"Сквозной пример" был бы интересен.

с выходом нового инструмента от 1С: EDT (Enterprise Development Tools)

А что уже можно использовать в ежедневной работе? Сам только бетку какого то старого релиза смотрел. Но где то читал что для повседневной работы пока мало пригодно из за каких то не доработок. Например у меня типовая конфигурация ERP могу уже в EDT с ней работать или ещё проблемы есть?
2. real_MaxA 253 22.11.17 11:12 Сейчас в теме
"Сквозной пример" был бы интересен.


Какой-то пример планируется в следующих частях.

А что уже можно использовать в ежедневной работе? Сам только бетку какого то старого релиза смотрел. Но где то читал что для повседневной работы пока мало пригодно из за каких то не доработок. Например у меня типовая конфигурация ERP могу уже в EDT с ней работать или ещё проблемы есть?


По мне так, EDT использовать нельзя будет ещё года полтора, в лучшем случае, если это вообще будет возможно. Поэтому старая технология с хранилищем ещё долго будет актуальной. Да и не сможет EDT совсем вытеснить конфигуратор, как, например, до сих пор можно встретить живую 7.7, несмотря на выход всей линейки 8-ки.
3. TODD22 19 22.11.17 11:45 Сейчас в теме
(2)Вот про EDT я это и слышал. Что работать на ней пока нельзя.
4. real_MaxA 253 22.11.17 12:17 Сейчас в теме
(3)Так это "пока" рано или поздно, я надеюсь, закончится.
5. Infactum 317 22.11.17 12:29 Сейчас в теме
Что ни статьи про CI на IS - либо вода, либо hello world.
Как насчет серьезного примера?
Пара docker контейнеров (jenkins master + linux slave для тестов под linux) + нода для windows тестов.
jenkins file для демонстрации git pull + build + BDD + TDD + deploy master при успехе?
Отчеты в формате allure показать.
В общем все то, о чем уже неоднократно писали и рассказывали на IS Event.
Если вдруг такой bootstrap уже есть, то поделитесь ссылкой на github.
kote; ABudnikov; +2 Ответить
6. real_MaxA 253 22.11.17 12:36 Сейчас в теме
(5)Пока я не планирую серьёзных примеров.
Я сейчас пытаюсь провести ликбез для людей совсем не знакомых с CI.
7. nicxxx 255 22.11.17 12:42 Сейчас в теме
(5)
Как насчет серьезного примера?

Серьезный пример здесь за 12900 руб. продают
Evil Beaver; +1 Ответить
8. Infactum 317 22.11.17 12:57 Сейчас в теме
(7)
Если вы про это и это, то они несколько дороже. Вот только не надо путать примеры и полноценное обучение.
Просто регулярной вижу, что ИС пытаются продвигать как сообщество профессионалов, но статьи почему-то дальше уровня "Для тех кто ничего не знает про СКД/Запросы/CI/<подставь своё>" в подавляющем большинстве случае не уходят.
Мне эта информация не нужна, просто автору предложил для будущих статей.
Evil Beaver; +1 Ответить
10. real_MaxA 253 22.11.17 13:03 Сейчас в теме
(8) Я бы и сам не отказался от серьёзного примера :)
Как я сказал в статье, я это описываю для тех, кто вообще ничего не знает про CI и смежные технологии. Все вокруг только и делают, что о них говорят и при этом предполагают, что окружающие понимают, о чём идёт речь, а это далеко не так.
Здесь я хочу закрыть этот разрыв. Пусть специалисты говорят то, что говорят, а неспециалисты, теперь, будут их хотя бы понимать.
Evil Beaver; +1 Ответить
11. Evil Beaver 8197 22.11.17 13:30 Сейчас в теме
(10) На самом деле, количество всегда перерастает в качество. Чем меньше в 1С-мире людей для которых слова "git pull + build + BDD + TDD + deploy master при успехе" звучат, как заклинание призыва сотоны, тем скорее появятся статьи для уровня выше.
Kosstikk; pbabincev; brr; Berckk; Vladimir Litvinenko; farraf; +6 Ответить
12. KAV2 156 31.01.18 07:22 Сейчас в теме
(5) Ну благодаря этой статье я по крайней мере понял чем Jenkins функциональнее встроенного в Windows планировщика задач, а то ведь не понятно, зачем Jenkins когда уже все есть из коробки.
9. nicxxx 255 22.11.17 13:02 Сейчас в теме
Убрали вариант "за 12900 с поддержкой от SilverBulleters", я проходил именно такой.
13. HAMMER_59 252 01.02.18 06:30 Сейчас в теме
Занятная статья про тестирование:
1. Создайте обработку заполнения чистой базы.
2. Создайте обработки для тестирования базы.

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

3. Ну а самое сложное - запуск тестирования, и тут вам поможет jenkins.
Вот именно с реализацией 3 пункта, прямо такие сложности, вот именно в нем у всех проблемы.
14. ImHunter 327 01.02.18 07:25 Сейчас в теме
(13) Собственно, а какие проблемы с п.3?
Я тут не голословен. Недавно поднял линию сборки для измененной конфигурации.
Тестирование пока не прикрутил - еще нет тестовых обработок.
16. KAV2 156 02.02.18 12:29 Сейчас в теме
(14) Очевидно это сарказм автора сообщения, хотели сказать что как раз запуск тестирования это довольно простая задача в сравнении с созданием тестовых обработок. Я как раз поэтому и полагаю что CI лучше делать на самом 1С где можно тестовые обработки прикручивать естесственным и простым образом.
17. ImHunter 327 02.02.18 14:44 Сейчас в теме
(16) Да хз. Красиво подготовить Jenkins под 1С - тоже еще та задача. К примеру, пришлось дописать Деплойку, написать на groovy библиотеки общего и специализированного пользования. Потом как-нить выложу.
По сравнению с этим, мне намного проще было дальше конфой заниматься, но только в идеологии TDD. И рождать при этом тестовые обработки для xddTestRunner. Тут тоже опыт есть какой-никакой.
15. real_MaxA 253 01.02.18 10:23 Сейчас в теме
(13) Статья не про "Как?", а про "Зачем?" и "Что это такое?".
18. headMade 144 09.02.18 17:46 Сейчас в теме
подскажите может есть какая-либо инструкция по установке и настройке jenkinsа и allur .
Где и что скачать.
Как настроить?
19. real_MaxA 253 12.02.18 13:35 Сейчас в теме
(18) Я прошу прощения за резкость, но http://lmgtfy.com/?q=%D1%83%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0+jen­kins

С инструкциями по аллюру сложнее, т. к. его установка совсем простая. В настройках jenkins (Global Tool Configuration), в самом низу, подключается нужная версия аллюра.

Чтобы аллюр "сработал" при сборке, нужно, чтобы при сборке сформировался файл специального формата с результатами тестов (xUnitFor1C это умеет), а в сценарии сборки добавить генерацию отчёта allure по данным файла с результатами тестов.

Всё это вполне можно найти на просторах Сети.
headMade; artbear; +2 Ответить
20. real_MaxA 253 12.02.18 13:44 Сейчас в теме
(19) Вот по аллюру документация (прямо в их гнезде): https://docs.qameta.io/allure/#_jenkins
21. ImHunter 327 13.02.18 16:15 Сейчас в теме
Небольшой анонс.
Пишу и попутно внедряю библиотеки для Jenkins. К примеру, написана обертка для Деплойки.
Позволяет писать скрипт в подобном стиле:
    stage("Init deployka"){
        
        dep = initDeployka(PATH_TO_DEPLOYKA, PATH_TO_SERVICE_EPF)
            .setDb('server1c:4041', 'buh_db', 'Администратор', 'пароль')
            .setRAS('ras server', 'ras utility')
            .setRepo('repo path', 'repo-us', 'repo-pwd')
    }
    
    stage('Update'){
         dep.killSessions(true, dep.newSessionFilter().addAppClient().addAppDesigner())
         dep.updateConfigFromRepo()
         dep.launchUserInterface()
    }
Показать

Пока выкладываю сырые доки. Потом (через 2-3-4 нед) куда-нить на Гит выложу. Ну и может небольшую статью.
Прикрепленные файлы:
DeploykaHelper.zip
artbear; Evil Beaver; +2 Ответить
22. Silverbulleters 13.02.18 17:19 Сейчас в теме
23. user1123127 04.01.19 12:37 Сейчас в теме
Я уже писала в комментариях к одной из частей этой статьи, но повторюсь здесь тоже. Мне еще понравилась статья Что такое CI & CD и как она работает? Ссылка https://linuxtrainingcenter.com/stati/chto-takoe-ci-cd-i-kak-ona-rabotaet/. Очень доступно описан процесс CI & CD. Может кому-то пригодится :)
Оставьте свое сообщение