Условно 10 человек в команде, совместное хранилище, каждый захватывает свой объект для реализации активностей.
Допустим программист Петя захватил Модуль1, внес в него свои изменения и как это бывает на практике затянулось принятие по причинам не зависящим от Пети.
В этот период у программиста Вася срочная задачка и очень нужно внести изменения в Модуль1. Вася пишет Пете. Петр сознателен и помогает коллеге и отпускает Модуль1.
У Васи все хорошо, он сдает задачу и через определенное время возвращает Модуль1 Пете.
Минусы у Пети. Нужно где-то сохранить свои доработки по задаче в отдельной базе или файле конфигурации. При необходимости вернуться сталкиваемся с проблемой как понять, что именно эта дельта была изменена.
База непрерывно меняется, может релиз новый прилететь, а Пете нужно оперативно вернуть все изменения и продолжить работу по активности.

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

(227) Не только читал и пользовал, в 1С это не надо. едт блювотна.

(224) Вы думаете, это просто?

(230) Достаточно легко
Вопрос пары дней

(231) А вот профессионалы говорят, что ощущения смешанные. Есть плюсы и минусы.

(232) Ни разу не было описано веского случая в пользу гит или тестирования - т.е. просто игрушки для "чудил".

(233) Есть плюсы, что в гите можно редактировать один модуль сразу нескольким людям. Но если долго не мёржить, то начинаются неприятные конфликты, которые автоматически не разрешаются.

Все плюшки эклипса — тоже плюс.

Сонар.

Но есть и минусы. Тормоза, выгрузки-загрузки, rebase...

(234) В других языках это плюс в 1с это убоость. Про редактирование общего модуля писали выше. Та кили иначе кто то первый.

в git lfs добавили блокировки файлов для желающих
хотя имхо это ненужная хрень убивающая идею децентрализованной системы

еще раз:

1. GIT - подходит когда пилят огромного монстра большой толпой и релизят редко (раз в месяц), для оперативной работы GIT вообще не подходит, по сколько сборка CF очень долгая и эффективность МЕЛКИХ доработок падает почти до нуля

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

3. ETD - сделана исключительно для мобильного приложения (ну и немножко для самой 1с, для типовых конф), а для 99% компаний простых она не нужна...

(237) 1. Нет. Для мелких доработок тоже подходит. "Сборка cf" долгая только первый раз.
2. Когда разработчиков много или пилят один огромный модуль с хранилищем наступает упс.
3. Имхо EDT в глаза не видели. Имхо как и МП/МК ибо для их разработки EDT не нужна.

И Конфигуратор и EDT это всего навсего два разных инструмента
Как и Хранилище и GIT всего два разных инструмента

И в некоторых случаях лучше одно, в некоторых другое

Было бы идеально если в Конфигуратор добавили работу с GIT
А в EDT работу с хранилищем напрямую

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

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

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

(236) "
236 - 31.03.23 - 22:40
в git lfs добавили блокировки файлов для желающих" идут по пути 1с, скоро изобретут обновление .

(242) Я работаю, веду к примеру 5+ задач. В гите для каждой у меня отдельная ветка, которая к завершению соединяется с основной и я точно знаю, какие изменения у меня по задаче произошли.
В 1С мне потребуется создать пять отдельных конфигураций, для корректного понимания, что я напрограммировал в контексте отдельной задачи.

(244) >>>веду к примеру 5+ задач.

у тебя 5 мышек? как ты ведешь сразу все 5 задач? по моему это бред....

кто мешает взять 1 задачку и ее сделать от начала и до конца, положить ее в хранилище и только потом приступать ко второй задачи?

(245)  Ок. Ты сделал и дальше не можешь ее отправить в продакт, так как заказчику нужно подумать. Или данные для реализации нужно исправить и тоже ждешь. И т.п. Реально разрешает руководство сидеть без дела это время?

(246) для этого есть тестовый контур, ты спокойно кладешь на тестирование и все...

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

Или ты берешь в работу полуфабрикаты которые неизвестно когда включат в продакт? в этом случае ты плохой управленец ибо тратишь ресурсы на заведомо провальные задачи.

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

(248) если задача на паузе ее не нужно начинать делать

(247) дада
а потом ручками переносишь из тестового в прод...

плавали знаем
гит же просто в одном репозитории держит ветки задач-фич, и если что сливаешь с мастером-релизом

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

(251) если при тестировании не выловили хитрых багов это не значит, что надо что-то останавливать и кстати это означает, что доработка выполнена и обязана быть помещена в продакшен и ее уже не нужно отслеживать в списке актуальных задач, все проблемы которые возникают после приемки - это НОВЫЕ задачи, и решать их нужно в порядке устанавливаемым РП, например не обязательно отдавать баг тому, кто разрабатывал этот функционал а можно отдать другому, и по этому "я веду 10 параллельных разработок" для меня не понятно.

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

Ну а полный стек задач - это удел руководителей....

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

(252) не передергивай
перед помещением в релиз(прод) есть период тестирования и возможно доработок
и он бывает весьма длительным и прерывистым на ожидание аналитик/клиента-заказчика
чтобы не было простоя переключаются на другую задачу

(253) на фикси такого не бывает... даже в конторах с бешенной бюрократией такие вопросы решаются быстро (обычно административно а не технически, типа накатывайте, но пока в меню не добавляйте)

(254) причем тут фикси?
речь про большую разработку (даже по одному проекту для одного клиента-заказчика) с кучей аналитиков-разработчиков
где задач множество

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

И да.
Самый-самый изврат и недостаток хранилища конфигурации по сравнению с GIT

Это что нельзя туда произвольные файлы закидывать

Например внешние обработки!

(254) бывает и не такое

(200) Аж прям любопытно стало. хранилище - к нему подключено 4 информационные базы 4 аффилированных компаний на базе БП 3.0. Работают 5 моих программистов и 4 программиста заказчика. За год с 01.04.2022 по 31.03.2023 внесли 569 изменений в хранилище.
Включая ежемесячное обновление БП на текущий релиз.

(196) Я не очень понимаю зачем мне 20 раз в день сравнивать изменения годовалой давности.
Но иногда действительно возникает потребность сравнить что было год назад и сейчас.
один из наиболее проблемных модулей - УчетТоваров - я вот сейчас используя выборочное сравнение модуля получил сравнение текущего состояния модуля с ним же годовой давности - это у меня заняло 5-8 секунд.

ЧЯДНТ?

З.Ы. Может вы просто двойным щелчком пользуетесь (там тогда целиком версия сравнивается - и это действительно по 30-40 минут занимает) - вместо контекстного меню с выборочным сравнением модуля?

(259) Я не про отдельный объект же пишу. Мне нужно оперативно понять ВСЕ изменения по активности в рамках задачки. В Гите удобно, в 1С нет.

(260) я конечно не эксперт, но что ты там оперативно начал понимать, если у тебя 10 прогов, которые выдают 1200-1400 часов в месяц, или 24-28к часов в год? Вот просто интересно

(261) сорян, не на то умножил.

14,5к-16к в год часов разработки

(261)(262) Я про удобство пишу. При чем здесь количество программистов?

(263) тз в (0) подразумевает 10 человек.

Чо ты там смотришь по 20 раз на дню? Может и мне надо, хотя я так лично ничего не придумат, либо в базе 50 часов разработки лежит за год и тебе надо проанализировать что-то, но вероятность такого слбытия 0, а

(263) он имеет в виду размер изменений в год
(260) удобство понятие относительное, видимо ты привык к гиту и НЕ привык к хранилищу.
вопрос удобства в данном случае не стоит рассматривать, нужно рассматривать объективные параметры, функционал, скорость и т.д.

А как в гноилище мерджить, о какой совместной разрабоке вы тут говорите?

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

(260)[В Гите удобно, в 1С нет.]
мы в курсе
ведение крупные проектов в Хранилище требует определенных усилий, технологии тебе описали многократно, смысл дальнейшего жевания соплей в топике какой ?

(260) так выгружай в гит исходники 1С и там смотри

у коллег (котлинщики) наблюдаю такую тему, что в команде 10+ разрабов, прекрасно живут в гите, code review, все дела.
когда пора деплоить задачку, в мерж реквесте должно быть n одобрений от коллег в код ревью, задача оттестирована, подлиты все последние коммиты из мастер-ветки.
разве что задачки надо делить на подзадачки, чтобы полпроекта не переписывать в одном мерж реквесте и коллегам не было больно это смотреть.
по сравнению с хоронилищем - все гораздо легче, особенно если умеешь в гит в командной строке.
работал в хоронилище с лохматых годов, с 2009го кажется.
кто бы что ни говорил тут, оно отваливается, это нередкий баг.
какие-то доработки теряются, редкий баг, но он есть.
удобство в стиле конфигуратора - выгрузки cf, чтобы что-то сравнивать, "ой, а отпусти-ка корень, мне тут справочник/обработку надо добавить".
это типа глючный SVN с одним возможным клиентом, на который 1С накладывает сверху трех-XL-ный.
естественно, все к нему привыкли уже и процессы отлажены, а с git'ом в 1С надо сношаться.

(270)
> кто бы что ни говорил тут, оно отваливается, это нередкий баг.
> какие-то доработки теряются, редкий баг, но он есть.
Давно работаю с хранилищем с большими объеми конф и коммитов, не сталкивался с такими проблемами

(270) > все гораздо легче, особенно если умеешь в гит в командной строке.
а какие сложности если из IDE?

(271) значит у нас его не умели готовить ))
(272) никаких, у меня скорее всего просто привычка - когда переходил из 1С на другой язык, пришлось учить работу в терминале, прочитал 2 книжки - коммандная строка Linux и git для профессионалов. в книжке вся работа с гитом из командной строки была.

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

(274) то, что вы описали - это последствия решений 1С при проектировании платформы и формата хранения данных в cf.
кто ж им мешал сразу удобную работу с git в конфигураторе? в совершенном коде кстати было уже озвучено, что "самые дорогие ошибки в ПО - это ошибки проектирования". это мы и видим на практике. сколько лет уже не могут нормально сделать EDT + git?

(275) я подозреваю, что гита ещё не было, когда вышла платформа

(276) Ты абсолютно прав
Сервис для совместной разработки и хостинга ИТ-проектов Github был основан в апреле 2008 года программистами Крисом Ванстрасом (Chris Wanstrath), Томом Престон-Вернером (Thomas Preston-Werner) и Пи Джей Хайеттом (PJ Hyett).

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

Хехе, я пришел на месяц раньше в отрасль

(277) Это Сервис на основе системы контроля версий. А сама система контроля в 2005 выпущена. Под лицензией GNU

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

(218) Как с языка снял. Много народу пытаются пропихнуть GIT там где он совершенно не нужен.  также часто вместе с этим внедряют бесполезный SonarCube +Jira. Это для меня сразу показатель особой одаренности.

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

Чтобы это все админить уходят ресурсы одного человека.

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

(280) А SonarCube и Jira чем провинились?

(280) автотесты тоже на помойку, бухша тётя Клава сама оборотку сверит после обновления и перепроведения.

(282) не видел ни одного теста который это делает

(280) Еще забыл.

Также есть уникальные люди которые внедряют СППР , но не понимают что это очень узкоспециализрованное решение которое нужно на 1 из 100 проектов

(283) а ты каким таск-трекером пользуешься?

(283) к (284)

(285)Комментарием в коде

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

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

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

(290) Разработчик зашел в модуль сразу видит комментарии, зачем ему искать их где то в GITе ?

(290) + в хранилище при помещении тоже комменты  можно добавлять

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

Еслы бы работал во франче то была бы копия с комментами номеров задач или задача в которой описаны используемые процедуры - трудно сказать как удобней.

(291) Это бест-практика из мира для взрослых: когда коммит помечается таском из трекера. Ну типа, аналитики в конфлюэнсе подробно расписал какое-то ЧТЗ, нарезал его тонко. В жире он создает таски и маппит на какие-то пункт в кофлюэнсе. Разраб берет таск, кодит, коммитит и метит - это коммит по этому таску. И там дальше у тебя в какой-то веб-морде сразу видно - вот коммит, вот пруф на таск в жиру, оттуда в конф. И так можно быстро подымать контекст, кто когда почему для кого - что-то комитил.

(294) Это понятно. Но по факту я могу также взять номер задачи из комменнта и найти в системе учета задач по номеру задачи всю информацию ,что мне нужно по задаче

(294) Зачем это всё, если ЧТЗ можно комментом в самом модуле написать?

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

(296) см. 295

(297) Тут большинство сидят в отделах до 10ти. А ты описываешь 0.001% Программистов с дикой текучкой где этот самый контекст нужен. Хотя чем олн там поможет не ясно - увидел косяк увидел что закосячил Вася 2 года назад - что с этой информацией делать?

А теперь привиди - какойто тест из своей "зэбест практик" который завалился.

(298) да, это практика когда много народа на проекте навалено. Когда вас два землекопа, вы сами себе и постановщики и аналитики и т.д., то вы даже не настроите все это, это уже оверскил. Тут вроде про то - зачем это надо.

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

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

(301) А из комментов этого разве не видно ?

Кроме того все равно придется лезть в конфигуратор в большинстве случаев , так как падать может в одном месте. А причина падения кода -вообще в другом месте.

(280) я разрабатываю сейчас на голанге, там есть свой линтер, называется golangci-lint, он сканирует уязвимости, куски кода с большой цикломатической сложностью. очень крутой инструмент.
если запустить со строгим конфигом - много чего показать может, хотя есть ложные срабатывания.
гораздо удобнее, чем типовой процесс разработки в конфигураторе. уж поверьте мне, 1С разработчику с 10+ лет опыта с разработкой сложных нетиповых конфигураций (куда не каждого 1Сника еще и позвали из-за плохого знания клиент-серверного взаимодействия).
(302) кек. коммент можно пейсать, а можно и нет.
причем более того, можно историю глянуть что с этим комментарием делали.
у нас в конторе, где очень много программистов, если в коммите нету номера задачки, этот коммит не принимается в gitlab'е, который является origin'ом для git'а в проекте.
дело в обязательности, любой инструмент нахой не нужен, если нет силы заставляющей его использовать.

(302) Т.е.для одной строки кода у тебя здесь будет три комментария? И потом ещё для последующих доработок

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

(306) для ликбеза рекомендую погуглить техники тестирования. Например граничные значения, классы эквивалентности. То что ты не видел такого, говорит лишь о масштабе систем, с которыми ты работал

(307) Клоунов с инфостарта собери и гуглите сколько влезет - может чего полезного сделайте.

Какой масштаб у ерп ут или зп? какой масштаб у доработок? Я сужу о полезности инструмента по изложенному и личному опыту. Пример ты тоже не привел что говорит о моей правоте.

(304) Понятно, у нас в конторе разработчики простое пишут комментарии. Все работает как по маслу

(308) >Какой масштаб у ерп ут или зп?

Ты не знаешь что при разработке типовых уже давно используется EDT и Git?

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

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

(308) а для тебя конфигурация это и есть система? Клоуны с инфостарта это люди трудами которых ты пользуешься. Некоторые из них ушли работать в фирму 1с

(313) 99% текста про гит и тестирование - полная куета, я этим не пользуюсь в рамках 1С.

(314) можешь пояснить, кого интересует - чем ты пользуешься в рамках 1С, а чем - нет?

сейчас на проекте собралась очередь из трех на один модуль, хранилище...

(316) случайно не МодификацияКонфигурацииПереопределяемый ? :)

(316) Юзайте https://infostart.ru/1c/articles/1443756/

(316) каждому раз-рабу по собственному пофигуратору, копии базы и собственному хренилищу :)

(318) +1

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

(320) Кажется, СППР уменьшает количество возни https://its.1c.ru/db/sppr2doc#content:35:hdoc

(321) да, при условии что вся контора сидит на СППР.

(61) все написанное корректно
Всегда можно договорится или подождать пока метаданные заняты другими
Иначе тестирование не работает. Оно и так тяжело осуществимо. А если задачи пересекаются, то это практически невозможно.
Уж не знаю что такое эдакое нужно активно пилить в 10 прогеров.

(320) такое можно автоматизировать скриптами с использованием онескрипт или типа того, обновлятор 1с, и т.п.

(319)
дык на ERP по другому не получается
но вместо отдельных хранилищ - индивидуальные ОМ

(325) для колхозников-чо такое ОМ?

(326) ОМ - общий модуль жы

(325) да-да
индивидуальные по фамилие или по задаче?