yukon
Юрий Гончарук

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

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

(5)

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

0-0 Есть какой-то способ запустить произвольный код в конфигурации не запуская клиента? СОМ-коннектор не предлагать.

Конференция отличная! Много докладов из которых наша команда будет брать опыт!

(16) Приезжайте на IE. 2023. Будет доклад по опыту нашей команды: «Интеграционные Unit-тесты в 1С. Как тесты на обмены улучшили жизнь пользователям, разработчикам и бухгалтерии. Практическое применение. Пример разработки правил обмена сразу с тестом.»

(3) Да можно вызывать и клиентские и серверные методы, и я могу даже сказать зачем. см. доклад "Тесты в расширениях" - там как раз подробно про это.

(11) Приходите на IE2023 - наша команда будет делать доклады и по тестам и по сборкам.

(9)

Цитата
Иногда разработчики прохлопывают незакрытые транзакции.

Для этого у на есть анализ кода и замечания от SonarQube - в нем это грубая ошибка, которая по нашим регламентам не может быть пропущена в релиз.

Цитата
Моет я что то упустила, но если стартует первоначальное заполнение она не исполняет обработчики только если они маркированы для первого старта.

Мы принудительно запускаем все обработчики обновления через параметр БСП.

Цитата
А тестовых данных в базах не содержится?

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

Т.о. мы и в локальных копиях разработчиков, и в условиях CI/CD всегда имеем возможность инициализировать базу нужными нам данными. Причем важно, что они одинаковые для всех.

Цитата
о каком исправительном релизе идёт речь

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

Цитата
только мы не используем Дженкинс, обошлись гитлабом

Инструмент CI/CD тут не суть важен - нам просто нужно выполнить определенную последовательность команд. Собственно специфики Дженкинса у нас мало. Мы стараемся по максимуму использовать возможности vanessa-runner, а где его не хватает у нас есть собственные скрипты на OneScript. В самом Дженкинсе логику мы не реализуем - его задача выполнять последовательность команд.

(7) В Дженкинсе база всегда новая, т.е. при тестировании отрабатывают все обработчики обновлений.

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

Исправительную сборку в релиз тоже легко выкатить. Если например последняя сборка была 1.0.8.5, то следующая будет минимум 1.0.8.6 - счетчик сборок гарантированно возрастает. Т.е. ваш текущий процесс - посмотрел номер релизной сборки, +1, пуш - остается в силе.

(4) Номер сборки актуален только для релизных артефактов. Для разработчиков эта информация не нужна - они всегда работают с состоянием кода в ветке разработки. Т.е. для "модельных баз" берете проект AS IS без модификаций.

В конфигурации проставлена версия "1.0.7.0". С этой версий и работают разработчики. После отправки проекта в релиз (через MR в релиз-ветку) владелец проекта тут же делает коммит с повышением версии - "1.0.8.0" в мастер-ветку.

В релизной же ветке последний "0" заменяется на номер сборки. В готовящейся версии Vanessa-Runner этот функционал тоже реализован. Т.о. нумерация релизных артефактов вполне может быть:
* 1.0.7.17769 - релиз
* 1.0.7.17770 - выпуск исправления.
* 1.0.8.17771 - новый релиз
и т.д.

PS. Продублировал в ВК, оттуда не приходят уведомления о комментариях к просто статье.

(2) Да, можно, в т.ч. и из Дженкинса проставлять теги. На момент написания доклада формирование релизов и в гитлабе был один из вариантов реализации хранения релизных артефактов.

Сейчас мы для себя отказались от этого и используем только артефакты сборок Дженкинса с определенной глубиной хранения (сейчас это 20 релизов), а для публичных проектов, или если реально нужно хранить всю историю релизов - этот момент, конечно нужно автоматизировать и хранить релизы в гитлабе/гитхабе.