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

(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 раз меньше боевой, но содержат все основные данные для тестирования.

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