Всем привет
Поделитесь, в каких базах как вы ведете разработку по задачам, в пустых, в тестовых - наполненных данными?
Какая подключена к рабочему хранилищу?
Варианты, для примера:
- Личная тестовая база подключена к рабочему хранилищу и разные задачи ведутся в ней, возможно и одновременно.
- Тестовая база не подключена к рабочему хранилищу. Для каждой задачи есть отдельная пустая база. Для работы с хранилищем есть отдельная пустая база. Периодически тестовая база обновляется из хранилища через cf.
- Для каждой задачи есть отдельная тестовая база. Для работы с хранилищем есть отдельная пустая база
- Другие варианты. Может быть многое автоматизировано.
Интересно, кто к чему пришел с опытом
Как решаете вопрос временных затрат при переносе разработки между базами, в случае больших конфигураций.

Разумеется в пустых. Мы же до одури любим сами заводить 100500 справочников и документов...

"Для каждой задачи есть отдельная тестовая база" - дебилизм.

(1) > Мы же до одури любим сами заводить 100500 справочников и документов.
читаем внимательно - речь про разработку, а не про тестирование

(2) А что, для разработки не нужны 5025 справочников, чтобы было чем заполнять создаваемые документы и выводить в разрабатываемые отчёты?

(3) ты не поверишь, но нет, для разработки не нужны

(4) Нет, не поверю.

(4) Как к вам устроится? Я тоже хочу страдать подобной хренью.

(5) и я не поверю.

(7) И я не поверю.

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

В хранилище 3 базы размеры в них 60 ГБ 105 ГБ и 250 ГБ.
3 прогера старых прогеров тоже не удалиили с хранилищи.
Для хранилища часто беру копию и переподключаю от своего имени пользователя.
Почти каждый раз надо разрабатывать именно на свежих данных.
Разные доработки внедряются в разные периоды.
Разработка в пустой базе это нонсенс! Ни разу так не делал.
Разве что срочно какой то отчет подправить кому то по шабашке когда нет реально базы
а есть конфа или релиз.

(0) Есть разработочный контур - все разработочные базы с данными и тестовая база для итогового тестирования, и боевой контур - рабочие базы и база для сборки с данными для проверки переноса сложных доработок.

автор смешной, подписка однозначно

(4) Да вы, батенька, мазохист.
Конечно же вся разработка в тестовых базах с данными. И конечно же никаких хранилищ.

(0) Прод конечно к хранилищу не подключен.   У каждого разработчика своя дев база,   подключенная к хранилищу, из которого делается поставка. Некоторые под отдельные длительные задачи создают свои локальные хранилища.

(11) что такое итоговое тестирование в вашем случае?

(13) > никаких хранилищ
это как?

(16) на кой оно? Чтобы было?

(16) Ты еще наверно не знаешь, но есть прекрасный чудный мир разработки свободный от хранилищ, и где в тестовых базах есть данные. Всего лишь нужно освободиться от наручников, которыми тебя к батарее приковали.

(18) т.е. у вас с вашими программистами вообще нет хранилищ?

Да. Представляешь, так тоже можно

(20) можно то можно
делаю вывод, что либо контора у вас маленькая и отдел ваш тоже, либо цена ошибки низка у вас

А как хранилище от ошибок спасает?

А сколько ты уже работаешь на этом проклятом заводе?

(22) ну как минимум хранилище дает возможность захвата до разработки, меньшая вероятность что второй разработчик не затрет разработку первого
да и как без истории, кто когда что закоммитил - слабо представляю себе работу без этого

(22) хранилище можно использовать просто при работе в одного
это даст много плюсов
если знаком с идеями гита то тут вопросов не должно возникнуть

(24) а что коменты в коде менее кошерные чем в хранилище?

(25) кроме гемора и лишних телодвижений нет никаких плюсов

>- Для каждой задачи есть отдельная тестовая база.
Вот это я понимаю, истинное версионирование!

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

(26) ты про какие коменты?

(30) Которые вменяемые программисты в команде оставляют в тексте
типа
// ДенисЧ заявка 12345 01.08.2021
...
// --ДенисЧ заявка 12345

(31) я лично считаю подобные коменты архаизмом который мешает чтению, устаревают
еще в какой то момент появляется наложение этих коментов от разных программистов
версионирование в хранилище решает все эти вопросы

(28) да, это в идеальном мире
мне интересно кто насколько близок к этому идеалу

(32) так вроде бы и нет этих вопросов. Вопрос надуманный и решение из серии чтобы оправдать факт существование.

(34) у вас нет версионирования, и нет всех плюшек от этого
может быть они вам и не нужны, но версионирование по норме неплохо для любых файлов, вплоть до документов

(32) А, в хранилище ты тоже комментарии к коммитам не оставляешь?
Может, ты ещё и поворотники на перекрёстках не включаешь?

(36) в хранилище как раз коменты обязательны

(37) А зачем вы тему заводили? Вам уже 10 раз сказали, что ваш подход говно. Пора бы уже смириться, а вы все равно свое говно в массы проталкиваете. Оно кроме вас никому не нужно

(35) Ну у меня была пару случаев когда версионность была нужна. Ну с учетом сколько времени тратиться на поддержание версионности (захват-коммит), то я на несколько порядков быстрее восстановлю по памяти потерянные участки кода, чем общее время затраченное на поддержание версионности.

Вот сколько раз она была тебе прям нужна? и сколько она сэкономила в сравнении с временем на поддержание (сделать отдельную ветку на поиграть, захват, подтвердить, откатить)

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

(39) > Вот сколько раз она была тебе прям нужна?
как говорится Админы делятся на тех кто не делает бэкапы, и тех кто уже делает

(41) А программисты - на тех, кто оставляет комментарии в хранилище и тех, кто не тратит час времени на сравнение версий в хранилищах для поиска того уб.....ка, который не комментирует код.

(40) > делать хранилище под каждую задачу
я не писал здесь про такое

(42) Чтобы не заниматься такой фигнёй, придумали git

вообще тема хранилища меня мало занимает, просто народ как то зацепился, а так то мне там все +- понятно
больше интересно как разработчики поддерживают порядок при паралельном ведении нескольких задач, которые используют одни и те же объекты

(42) Сколько я ни встречал комментов разрабов в коде, вот ни разу не легче было разобраться.

(44) причем получать ответы на эти вопросы можно и в случае с 1с, используя выгрузку хранилища в гит

(46) +1

(44) Ага. И тратить полтора часа на выгрузку конфигурации в него. А потом - ещё полтора на сбор готового релиза.

(46) Это проблемы твои и тех, кто комментирует.
В таком варианте - и по гиту с хренилищем будет не разобраться.

(49) Какие полтора часа? Зачем их тратить, если можно автоматизировать выгрузку?

(46) а ты когда видишь такой коммент - иди к этому разрабу, и разрабатывай его и свои навыки коммуникации. После этого комменты очень быстро становятся короткие и информативные.

(51) Автомат не занимает ни секунды. Я в это верю, как верю в Создателя нашего Летающего Макаронного Монстра и Сына Его Спагеттю, пришедшего, чтобы искупить грехи наши в кастрюле с кипятком.

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

(53) Ну да, если нет знаний, остаётся только верить.

Отказался от хранилища на работе(2 программиста). Обновляю путем "скинь на почту, что там обновить надо из твоего cf".
У каждого своя копия рабочей, время от времени обновляет.

Работал на внедрении УТ 11 с хранилищем, 4 программиста, воспоминания сплошь отвратительные. Кривое, глючное, неудобное, медленное и ненадежное гуамно.

(45) Ты озвучь что там у тебя на работе. Сколько разрабов на какую конфу? Может вы там на двоих одну БП 2 поделить не можете

(57) все мои последние места работы были с разрабами исчисляемыми десятками, и я не представляю как можно работать без хранилища
и не смогу понять организацию работы отдела как "скинь на почту, что там обновить надо из твоего cf", даже если там будет 3 программиста

(58) У нас там доработок раз-два и обчелся. Плюс к тому программист младший, ему ничего серьезного не даю.
При большом количестве программистом, увы, без хранилища никак. Приходится есть и плакать.

(58) Понятно. Десятки программистов программировали, программировали, да так и не выпрограммировали.

(58) > все мои последние места работы были с разрабами исчисляемыми десятками
Но вопрос об организации работы тебя заинтересовал только сейчас, ага. Сотнями, чо уж там, тысячами.

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

(62) А может пора ТС посоветовать перейти на EDT?

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

(45) Решай организационно.

Варианты:
1. Если разраб №1 пилит какой-то справочник в рамках одной задачи, а разрабу №2 этот справочник нужно допилить в рамках другой задачи - пусть разраб №1 пилит этот справочник и в рамках второй задачи.
2. Ситуация та же, как и в п.1. Решение: разраб №2 ждет, пока закончит разраб №1 (в это время занимается другими объектами).

Из личного опыта:

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

Еще вариант: все личные тестовые базы и база прода подключена к хранилищу. Работы ведутся в тестовой базе параллельно. В прод выкладываются после согласования с ответственным за релиз (с приведением списка измененных объектов).

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

(58) Десятки разрабов? Что вы там пилите? Отраслевое решение?
Возможно вам действительно стоит посмотреть в сторону EDT.

(63) А вдруг у него там обычные формы?
Да и вообще, судя по теме, ему советы не нужны.

(59) почему нужно плакать? может быть нужно научиться готовить хранилище?

(70) Ну вот - я же говорил, что ты не за рекомендациями сюда пришел =)

(71) обрати внимание на (45)

(45) "больше интересно как разработчики поддерживают порядок при паралельном ведении нескольких задач, которые используют одни и те же объекты"
Не совсем точно выразился. Правильно будет так:
Больше интересно как разработчик поддерживает порядок, когда он делает несколько задач, которые используют одни и те же объекты

(73) одну задачу сделал, протестил, залил в хранилище, вторую делаешь

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

Или поднимать отдельное хранилище для расширения. Но тогда надо постоянно вспоминать - какая задача где находится. Тот же самый эффект.

(74) в идеале конечно так, но бывают моменты ожиданий в задачах измеряемые в днях
если на каждую задачу своя база то вопросов нет, но воникают временные сложности если конфигурация размерами сравнимыми с ерп

(73) > когда он делает несколько задач
Ну дык он их все равно всегда делает последовательно. Нет никаких проблем.
То, что они на нем одновременно "числятся" вообще никакой роли не играет.

(76) > моменты ожиданий в задачах
А вот это называется "планирование релиза". И к хранилищам и куче баз имеет весьма опосредование отношение. Они - всего лишь инструмент реализации.

(66) На прошлой работе подключили разраб хранилище к Проду. Ну я и напродил туда. Мне то что? Это вы че то там себе придумали, вот и разбирайтесь теперь

(77) (78) гладко стелешь) ты еще посоветуй организовать процессы чтобы все было по срокам и по качеству

(80) А тебе не дают этого сделать?

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

(81) ты уводишь в то оффтот по управлению проектами, это не моя компетенция сори, не смогу поддержать тему

(82) смысл не подключать боевую к хранилищу? Если у вас erp то обновлять боевую через загрузить из cf хранилища? Cf воообще более 2гб не получить ниже 8.3.15

(84) можно кстати обновляться из хранилища без подключения, через командную строку такое можно

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

Правда, были минусы для аналитиков - их тестовые данные для проверки задачи все слетали.

(4) Вы сразу, без отладки и проверки пишете код который всегда и везде работает? И вас никто за это не натягивает?

(0)в наполненных данными и достаточно свежих, для каждой задачи отдельная база
приемка работ РП на отдельной базе с безусловно текущими данными
в хранилище только после приемки

(87) а что отладка только на живых данных?
Если есть тесты то можно и на пустой.
И даже проще будет. В живой базе поди еще и найди нужный случай

(89) Можно и на мёртвых. А на пустой тесты - это куча моков, тебе всё равно данные нужны. Не проще ли взять готовый набор?

(90) иинимальный набор данных ты сам готовишь в тестах

Готовые наборы хороши для отчетов

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

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

(88) у вас инфраструктура для этого есть с автоматическими развертками, обновлениями?
или в полуручном режиме?

(95) в полуручном, технология автоматизации понятна, руки не доходят

(93) в тему, как раз в ERP свой механизм закрытия горного передела две недели пилю, хорошо, что РСВ всего два часа занимает на "живых" данных =)

(0) копии рабочей если на сервере, ну или выгрузку, небольшие доработки можно и стационарно в демонстрационной базе делать.

(75) Если класть расширения в гит, всё будет хорошо.

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

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

(0) Ну, у нас основные базы на 400Гб и на 60Гб. И в моменте обычно 2 десятка разработчиков работают с кодом. Естественно, не делаем копии на каждого. Решили тем, что делаем срез данных за месяц и получились адекватные по объему тестовые базы разработчиков. Еще сделали обработку по обезличке и теперь даже СБ не подкопается. При это есть полные тестовые базы: для ИТ тестирования (она подключена к хранилищу DEV) и для пользовательского тестирования (подключена к хранилищу MASTER).

Но 99% 1С-ников ни хранилища не нужны (хотя даже личную разработку вести без храна - для меня дикость), ни вопрос с тестовыми базами. Так они делают мелкие фиксы типовых у простого коммента в коде, в целом, достаточно.

А в целом, хотим в EDT и Git. Организовать полноценный автоматизированный бранчинг с автоматической разверткой как разработческих баз, так и баз под пользовательское тестирование. И сливать все в MASTER после прохождения приемочных тестов и автотестов, имея после этого готовую к внедрению сборку.

(101) расшифруй плиз второй абзац
я понял только то что в скобках

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

(101) а, речь не про ваших 1сников, а вообще
не знаю, я хранилище начал юзать когда начал разработку в 8.0 - какая то версия платформы тестовая гуляла по сети
правда я разрабатывал свою конфигу, не с типовой работал

(103) а версионирование кода?
Не не слышал

(105) Не не слышал, работаю один, у юзеров есть доступ к тестовой базе, если все устраивает, переношу настройки в рабочую базу.

Хранилище еще хорошо тем что случайно нельзя код изменить.
А то можно открыть модуль посмотреть и случайно нажать чего-нибудь

(105) Хехе. Для красоты решения и оптимизации алгоритмов мы вообще вынесем часть кода в справочник и будем исполнять его через Выполнить.

Версионирование он захотел =)

В справочнике то версионирование на раз два включается

(108) это называется привет от консолидации

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

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

(112) хрень какая то, юзеры юзают тестовую, если все норм, переносим в рабочую.

(113) что ты все на юзеров киваешь, они что тебе покрытие кода делаю тестами
о другом речь

(112) Программисты в крупных конторах часто не имеют доступа на прод. И это правильно.

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

(32) А обновления на новые релизы от 1С ты когда-нибудь делал?

(117) делал,правда давно
А в чем проблема там?

У нас два контура. Есть тестовые, которые подключены к тому же хранилищу, что и прод. Это для внесения срочных изменений и исправления критических ошибок (база нетиповая). И есть еще контуры "длительной" разработки, у которых свое хранилище, автотесты и т.п.
Не понимаю, почему народ так не любит подключать прод к хранилищу. У меня опыт подобной работы 14 лет. Базы до 500 Гб.
Главное, чтобы к этому хранилищу подключались только самые опытные разработчики.

Разработка на пустой базе - извращение. Я бы с такой работы ушел.

(56) Повторюсь, опыт работы с хранилищем - с тех пор, как оно в 1С 8 появилось.
Вы просто какие-то низкоуровневые.
Одно замечание: файловое хранилище НЕ ЮЗАТЬ. Только сервер хранилища и только через tcp/ip. Иначе море глюков.

У нас с хранилищем больше двух десятков разработчиков работает. Полет нормальный.

Еще мы написали свою софтину, которая перехватывает все обращения к хранилищу и запрещает помещение в хранилище изменений без ссылки на задачу в Jira.

(123) Опенсорц?

(124) Нет.

(125) Зря

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

я так понял, что у народа не возникает проблемы смешения кода по разным задачам в одной конфиге

(128) то бишь когда кладут недоделанную задачу и что-то перестает работать?

К хранилищу подключены рабочая и 2 тестовых (по количеству конфигурастов;)
тестовые не пустые, это обычно копии рабочей разной степени давности, обычно не старше месяца.

(120) Да, на пустой как косяк отловить..

(129) есть несколько задач в разработке
какие то задачи могут приостанавливаться на день или больше, в ожидании ответов или по другим причинам
т.е. есть незавершенный программный код по нескольким задачам

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

обычно такой код выключается через регистр сведений.
Главное чтоб сам код не падал

(133) не, я не про внедрение недоделанного в прод, а про контроль и хранение разработческого кода
Допустим приостановилась задача на неделю/пару недель. Если задача разрабатывается в отдельной базе, то она лежит себе и никому не мешает. К ней легко вернуться и посмотреть что разработано было
как аналог веток гита

(134) ну так если код не падает - он так же лежит и никого не трогает. зато потом не будет проблем внедрить этот код, когда основная конфа ушла далеко вперед

(101) это московская контора у вас?

(135) может и падает, если не дошел до тестирования, хотябы модульного

(134) ну так не клади в хранилище, оставь работу в тестовой

(137) имеется ввиду падает на компиляции

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

(139)в общем я не сторонник внедрения нерабочего кода, даже выключенного

(140) давно этим не занимался, но разве трехсторонее обновление не решает эти вопросы? Новая конфа поставщика, старая, конфа разработки

Правда я там выше имел ввиду коменты с ФИО разраба

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

(143) вопрос сравнения кода различающийся пробельными символами решается внешними сравнилками типа p4 helix

И я не против комментов пояснений, я против комментов с ФИО и датой

(145) Ну при сопровождении систем и доработках при работающей системе это тоже иногда имеет значение, особенно дата.

(146) это решает скв

комментарии в коде

https://sun9-27.userapi.com/impf/h3Fi7Cj22EhH2LDt-g6vea2MgIZbniFzYD0PvA/-DfdTXorTW8.jpg?size=604x340&quality=96&sign=a3766f472c3fc2c48a2bffe585361d28&type=album

> Ну при сопровождении систем и доработках при работающей системе это тоже иногда имеет значение, особенно дата.

Номер заявки в системе учета и все - остальное все должно быть в системе учета, кто, когда и с кем.

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

(150) и никто не знает когда нужно остановиться, и выпилить всё это

//--- Иванов 2021.01.02 По указанию от главбуха
а = ПолучениеЗначения2();
////+++ Петров 2020.01.02 сказали переделать
///а = ПолучениеЗначения();

(151) Мы тут недавно выяснили причину, по которой в некоторых редких случаях не работает одна штука...
И нашли изменения, затрагивающие, датированные 2016м годом ))

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

(151)

Реальный случай. Имена изменены, все совпадения случайны

//Иванов 01-01-2018 Задача 124
ПроверитьПодразделение();

//Петров 01-03-2021 Задача 245
ПроверитьПодразделение_2(); //Небольшие доработки не стал лезть в чужой код

//Сидоров 12-07-2021  Задача 456. Условие задачи полностью покрывают первые две проверки, но
//если я укажу на это, мне не заплатят даже за анализ, поэтому
ПроверитьПодразделение_3();

(153) а ещё весело работать в копии, в которой данные для безопасности превращены в жесть типа УИД-а: тяжело тестировать товары и контрагентов вида

ea0f982e-056a-41ff-8543-d2ba1202ba9f
ecaa883d-9b74-49ec-bbb5-5b9bc6c48e25
b2d338db-4542-45ab-99bc-dfb3ab6d7870

(155) хз у меня такого не было ^^

(152) Неудачники...

(153) Пустая база нужна чтобы при тестировании быстро сгенерировать необходимый и достаточный набор тестовых данных, на которых задача принимается в продуктив.

Ладно комментарии в коде. На той неделе коллега рассказал, товарищ попросил помочь с 1С, фрилансер у них 5 !!! лет работал. Новый чтоли документ создан был, в общем там такое веселье
https://ibb.co/Hgvw5s8
https://ibb.co/gwmtqc4
https://ibb.co/GVJG0Pd

(14) >> Прод конечно к хранилищу не подключен.   У каждого разработчика своя дев база,   подключенная к хранилищу, из которого делается поставка. Некоторые под отдельные длительные задачи создают свои локальные хранилища.

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

(159) Главное не делать никаких комментариев, в связи с чем все это, почему такие условия с такими датами :)
Получается код, который страшно трогать :)

(158) да да, забить данные в константах и регистрах сведений данные организации, повторить набор видов основных и дополнительных видов расчетов, настроить вытеснение у них всех как в рабочей базе, набить штук 15 разных документов начисления и удержаний.

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

(160) История хранится в локальном гитлабе.

(162) Так это будет автомат делать, не человек же.

(165) А автомат кто учить будет?

(0) По теме: используются два вида баз для разработки:
1. Модельные -  это пустые, в которых смоделированы контрольные примеры, минимально наполнены справочники. Иногда из делаеют из демо-баз, но я предпочитаю из пустых. Модельная база, или ее ответвления, используются для многих задач.
2. Копии рабочих баз. В них плюс что это тестирование на реальных данных, с учетом полной нагрузки и с различными случаями, которые реально встречаются, а минус - они со временем становятся большими.

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

(159) вот так устроишься в контору и в такое попадешь не дай бог

(168) А не после тебя это осталось? )))

(169) всякое бывало по малолетству, но именно такого шлака вроде не было

(166) Ну его один раз научить надо всего лишь.

(159) это еще норм... я писал в другой теме, на удаленке прогер писал им вот так

о.Организация = с.орг
о.Контрагент = с.к
о.ом = с.ом;
даже не помню что значит "ом".. вроде не физика была...
И это все без комментариев, без пометок даже //+ //-

О.комментарий = с.ко1+","+с.ко2; это тоже была нормой. И как смешное не звучало, он получал больше 150к рублей в месяц за такое и на удаленке еще ...

а еще бесят когда оставляют кучу кода за комменченого... когда листаешь а у тебя страниц 3-4, а4 листов, тупо зеленые.. причем стоит дата и там 2016 год ... на вопрос зачем.. "лень удалять".

(102) Ну, уже все объяснили.

(136) Ага, в последних трех конторах была серьезная разработка и во всех примерно такая схема.

(152) Я недавно при раскопках дошел до 2015 года. Нашел не до конца реализованный, но внедренный функционал, посрался с пользователями по поводу того, что они в глаза еблись все эти годы и не понимали, как это работало. И пришлось откатывать эти недоработки 5-летней давности. Но с Git было бы сделать легче. Это, кстати, пример в тему к (135).

(153) Все же, рекомендую попробовать хранилище даже для себя. Потом уже сложно будет понять, как работать без него.

(158) Это для простых катит. В текущей системе одни НСИ и мастер данные будешь полдня набивать для работы. Поэтом и делаем урезанные копии для разработчиков, которые весят в 20 раз меньше боевой, но содержат все основные данные для тестирования.

Коллеги, спасибо за мнения