Здравствуйте. Есть одна большая база УПП, в которой необходимо настроить работу нескольким специалистам. Работа в УПП ведется с незапамятных времен. Развернуть dt на локальном ПК нет возможности, т.к. в развернутом виде база весит 100+ГБ и работает очень медленно. Выгружать сам cf-файл без данных, зачастую, неудобно и ненаглядно, т.к. необходимо запускать отладку. Подскажите, пожалуйста, как в подобных случаях организовать коллективную разработку? Есть ли какая-то возможность настроить хранилище конфигурации более оптимально? Заранее спасибо за ответ!

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

Интеграция сценарного тестирования в процесс разработки
Многопоточный CI-контур для 1С c Packer, Vagrant и Jenkins. Часть 1. Описание системы и обзор инструментария
1С on demand – скажи "нет" постоянным билд-агентам
Не клади яйца в одну корзину. Как удовлетворить всех клиентов и не превратить конфигурацию в помойку
WEB-интерфейсы как механизм сбора и контроля данных в розничной сети. Инструменты и наработки

6. FetisovAN 15.10.19 16:48 Сейчас в теме

(3) Можно базы подключать к разным агентам ... Рабочая базе висит на своем без отладки. Базы разработчиков на своем - с отладкой. и Все подключены к одному хранилищу.

Хотя ИМХО правильная работа чтобы база рабочая не была подключена к хранилищу. Кто то один из разработчиков затягивает себе все изменения, тестирует и передает админам СФ полный базы для заливки в рабочую. Без всяких СравнитьОбъеденить - просто загрузить.

12. buganov 200 16.10.19 17:09 Сейчас в теме

(11) по-моему такое невозможно. Да и даже пофантазировать если, то можно представить, когда конфигурация у локальной и продуктовой баз будут абсолютно разные.
Отладку на рабочих базах держат для крайних случаев, когда тестеры или тестовые сценарии пропустили косяк в релиз и его нужно оперативно найти.
В таком случае алгоритм следующий:
Багфикс на тестовой базе - помещение в общее хранилище - (тестовая | основная ) база

2. buganov 200 15.10.19 13:12 Сейчас в теме

Хранилище это только конфигурация с маркерами захвата. Не важно, база пустая или 10Тб.
Разворачиваете хранилище на шаре, подключаете базы разработчиков и тестеров, а так же продуктовые. Перед обновлением продуктовой базы получаете рекурсивно корень.
П.С. 100+Гб это не большая база
Если нужно сделать базы разработчиков, то почему не использовать для этого средства SQL? Быстрее, проще и почти гаратированно без проблем

3. Drivingblind 228 15.10.19 14:07 Сейчас в теме

(2)

Разворачиваете хранилище на шаре, подключаете базы разработчиков и тестеров, а так же продуктовые. Перед обновлением продуктовой базы получаете рекурсивно корень.
П.С. 100+Гб это не большая база

Спасибо за информацию. Как быть с отладкой?

4. user-programmist 4 15.10.19 14:36 Сейчас в теме

(3) Добрый день. Непонятен вопрос. Для того, чтобы работать с хранилищем вы заходите в конфигуратор продуктовой / рабочей базы и выбираете пункт меню создание хранилища, который в выбранной вами папке создаёт образ исходной конфигурации. Там же создаёте пользователей для работы с хранилищем для своих программистов. Затем создаёте каждому разработчику свою базу и в конфигураторе каждой из них подключаетесь к продуктовой базе. Перед внесением промежуточных изменений им надо будет захватить объект из хранилища на редактирование(своего рода блокировка на изменения), а затем поместить его обратно. С отладкой никаких проблем нет, поскольку каждый производит её в своей базе. После чего вы получаете все изменения из хранилища в конфигурации продуктовой базы.

7. FetisovAN 15.10.19 16:50 Сейчас в теме

(4) на больших базах боевых отладку не включают .. я думаю вопрос товарища был в том, можно ли вешать базы на разные "серверы 1С" - ответ можно.

8. buganov 200 15.10.19 19:36 Сейчас в теме

(7) У нас отладка на продуктах стоит и ничего, живут нормально. База из разряда ультрабольшая

9. FetisovAN 16.10.19 09:06 Сейчас в теме

(8) не знаю что у вас там за база, какая конфа, сколько пользователей, какая степень доработки ... Я последние 4 года мучаюсь на упп 1.3 разной степени уработанности. Отладка всё таки очень здорово производительность съедает :(

10. buganov 200 16.10.19 11:54 Сейчас в теме

(9)10Тб УТ 11.0 исписанная вдоль и поперек. Активных пользователей порядка 150 + столько же роботов, которые генерят нагрузку большую, чем живые люди. Отладка стоит на постоянке.
Вы уверены, что дело в отладке, а не в коде? Проводили тестирование с и без флага отладки?
Скажу так. Мы проводили эксперименты, которые не показали изменений. Мерили с помощью апдекс + счетчики оборудования.

5. buganov 200 15.10.19 14:44 Сейчас в теме

(3)флаг дебаг у агента сервера включаете и будет отладка

11. Drivingblind 228 16.10.19 13:10 Сейчас в теме

(5)

(3)флаг дебаг у агента сервера включаете и будет отладка

Можно ли с одной (локальной) БД запускать отладку сеанса на основной БД? Хочется сделать что-то наподобие групповой отладки

12. buganov 200 16.10.19 17:09 Сейчас в теме

(11) по-моему такое невозможно. Да и даже пофантазировать если, то можно представить, когда конфигурация у локальной и продуктовой баз будут абсолютно разные.
Отладку на рабочих базах держат для крайних случаев, когда тестеры или тестовые сценарии пропустили косяк в релиз и его нужно оперативно найти.
В таком случае алгоритм следующий:
Багфикс на тестовой базе - помещение в общее хранилище - (тестовая | основная ) база

6. FetisovAN 15.10.19 16:48 Сейчас в теме

(3) Можно базы подключать к разным агентам ... Рабочая базе висит на своем без отладки. Базы разработчиков на своем - с отладкой. и Все подключены к одному хранилищу.

Хотя ИМХО правильная работа чтобы база рабочая не была подключена к хранилищу. Кто то один из разработчиков затягивает себе все изменения, тестирует и передает админам СФ полный базы для заливки в рабочую. Без всяких СравнитьОбъеденить - просто загрузить.

13. buganov 200 17.10.19 05:05 Сейчас в теме

(6)в идеале на другом сервере, чтобы влияние нагрузки на базах разработчиков/тестеров не оказывалось на продуктив

14. FetisovAN 17.10.19 11:13 Сейчас в теме

(13) Так и работаем :)

15. Xershi 1484 17.10.19 11:24 Сейчас в теме

(6) при таком подходе теряются все плюсы хранилища.
Но если вам так удобно, почему нет.

16. FetisovAN 17.10.19 11:37 Сейчас в теме

(15) а не кто не говорит что это удобно :) это разделение ответственности на программистов и админов. Я сам не люблю в конфигуратор рабочей базы ходить. Так как отладка на боевой базе отключена, мне там и делать нечего ... в крайнем случаи я могу запросить свежую копию базы, развернуть её на сервере разработки с отладкой всё посмотреть.

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

У самих сейчас рабочая база подключена к хранилищу и изменения просто затягиваются :)

17. buganov 200 17.10.19 12:09 Сейчас в теме

(16) у Вас, возможно, работа базы не 24/7?

18. FetisovAN 17.10.19 14:17 Сейчас в теме

(17) слава богу - нет :)

19. HAMAZ 7 06.12.19 11:14 Сейчас в теме

Наша схема групповой разработки: Боевой сервер с боевой и тестовой (после апдейтов) бд подключены к боевому хранилищу. Разработчики работают на своем сервере с индивидуальными базами с разработческим хранилищем. Когда нужно обновлять боевую базу - выгружаем CF, мерджим и обновляем боевое хранилище, проверяем на тестовой базе, если все устраивает - обновляем из хранилища боевую базу.
Данные для отладки наработок на индивидуальных БД выгружаем-загружаем при помощи всем известной обработки "ВыгрузкаЗагрузкаДанныхXML".
Подводный камень хранилища: в некоторых малоизученных случаях хранилище начинает жутко тормозить - что-то происходит с внутренними идентификаторами и захват-размещение делаются ужасно долго из-за того, что поиск объектов идет по имени. Эта проблема лечится пересозданием хранилища из поставки и внесением доработок.