Всем доброго дня!
Саб наверное совсем не в тему, но не знал как иначе это все описать)
Имею самописную базу, которую дописываю для заказчика
Я единственный разработчик
Раньше просто делал обновление и накатывал на рабочую базу
Теперь заказчик хочет сам тестировать новый функционал на тестовой базе, до переноса на рабочую
Соответственно одновременно может быть несколько параллельных задач и хочется иметь возможность накатить на рабочую базу только одну из выполненных задач, не перенося то, что сделано по второй задаче, пока она не закончена
Подскажите, как организовать работу в такой ситуации?
Думал сделать 2 разработческие базы и связать с тестовой и рабочей через хранилище конфигурации. Но это какая-то ерунда, мне кажется)
Как вообще организована работа в крупных компаниях, особенно когда две разные задачи могут менять модуль одного и того же объекта.

Функциональные опции спасут отца русской демократии

Хранилище, номер задачи в каждом коммите и каждой правке кода, соглашения об оформлении изменений в коде. Формы не менять, всё делать кодом.

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

(1) я правильно понимаю, что в коде прописывать - если опция подключена, то делать так. Если не подключена, то по старому?
вроде как вариант

Но что-то слабо верится, что сама 1с так и делает
Или они git'ом каким-нибудь пользуются?

(2) перечитал еще раз) комментарии в коде тоже рассматривал, но как-то велик риск своими кривыми руками что-то не то написать

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

(7) красивый костыль)

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

Может задам вопрос так
Как пишут типовые конфигурации в фирме 1С?)

варианты могут быт разные
один из - несколько хранилищ

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

(10) гит же. ветки, сборки мержди, вот это всё)

(12) На ИТС есть документация к СППР. Но лучше (13)

Есть только два варианта.
Либо классическая работа через Git с использованием EDT.
Либо создание отдельного хранилища к каждому техническому проекту с отдельной базой для разработки и тестирования. Продуктив может быть подключен к своему отдельному хранилищу (для хранения истории изменений объектов). Подробнее на ИТС https://its.1c.ru/db/v8std#content:2149184358:hdoc

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

(15) в продуктив еще и не то пихают...
аналог ФО на справочниках видел (живет)
константу "Тестовый функционал" видел (умерло)
копия базы для тестирования пользователями, сроки переноса в боевую, сравнение/объединение - классика (живет)
хранилище с выборочным обновлением (живет если разработчиков на базу немного)
Git… ну там свои заморочки

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

(0) вот посмотри "тематические ветки" https://git-scm.com/book/ru/v2/Ветвление-в-Git-Работа-с-ветками

(0) В 8-ке это можно частично делать через расширения, отдельные под каждую задачу, затем переносить в основную конфу.

Другой слегка тупой вариант это копии метаданных с префиксами в одной базе.
Например есть Справочник1, Справочник2 и Документ1.
Допустим Справочник1 использует Справочник2 а Документ1 оба справочника.

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

Но как все это дело автоматизировать для облегчения жизни, особенно слияния когда пз1_Документ1 закончили и переносим все из него в просто Документ1 а затем надо оттуда измененное перенести в пз2_Документ1 для дальнейшей доработки хз.

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

(18)+ Будут некие проблемы если Документ1 используется еще где то, по идее надо для проверок функционала пз1_Документ1 еще и копии тех метаданных делать со ссылками на пз1_Документ1 вместо просто Документ1.
И это должно проверяться и делаться автоматом поиском по конфе и по метаданным и по коду.

Ну или предусмотреть замену на лету везде где используется Документ1 на пз1_Документ1 для тестов а затем назад.

В 1с сразу в рабочую не бахают, как устроено - описано в книге вопросы эксплуатации крупных систем

(9) А почему и кто, как ты думаешь, начал ваять интеграции 1С с git задолго до появления EDT и даже до появления штатной выгрузки конфы в файлы?

(18) > слегка тупой вариант это копии метаданных с префиксами в одной базе.

Это не просто тупой вариант, а бред. Такое может работать только в том случае, когда твои модифицируемые объекты метаданных нигде более не используются. Что само по себе огромная редкость для современных конфигураций. Например, почти любой документ как минимум является регистратором нескольких регистров и типообразующим в определяемых типах. И это ещё если не вспомнить про БСП с её справочниками объектов метаданных и всеми прочими подсистемами, и различные другие библиотеки, куда может так или иначе входить документ.

Эта ахинея могла работать на клюшках и древних снеговиках, где не было никаких библиотек, и многие объекты действительно были относительно изолированы.

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

да на тестовой не будет истории.
А оно надо?

(0) ИМХО, голова распухнет поддерживать несколько веток одной конфигурации.

(25) с нормальными механизмами - как раз не распухнет

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

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

https://proglib.io/p/git-github-gitflow/

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

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

Или менять там ссылки/имена используемого на лету программно автоматически а не ручками.

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