Основная публикация: http://www.silverbulleters.org/minimalnaya-edinitsa-metadannogo-1s-nachalo/
В мире программирования, чаще всего все не так, как в других языках, это дает как преимущества, так и недостатки, которые замечаешь по сравнению с другими языками. Одним из недостатков в 1С является организация коллективной разработки одной конфигурации, в ней остро встает вопрос по определению минимальной единицы метаданных, которую может поменять в один «коммит» разработчик. Что…
Минимальная единица метаданного 1С - начало
3 Симпатий
Не очень понимаю суть проблемы. Бросаете кнопки на форму - код генерируется сам, меняете кнопки - код тоже меняется?
В этом?
CLI-приложение не написать что ли на 1ass?
Оно же веб, т.е. клиент-сервеное? Или нет?
Нет, не это.
При коллективной работе у тебя есть возможность только заблокировать объект для изменения другими разработчиками в хранилище, но когда начинается образовываться очередь объекту у тебя два выхода или поместить еще не рабочий код в хранилище или сохранить себе на диск, и отпустить объект в девственно чистом виде, дабы другие смогли его изменять.
[quote=“Zel_PC_03, post:2, topic:143”]
CLI-приложение не написать что ли на 1ass?
[/quote] нет, честный cli не написать, не умеет читать аргументы 1с , точнее умеет, но в коде тебе этого не даст.
И заодно - фича-реквест:
расшифровывайте пожалуйста ВСЕ аббревиатуры в статьях!
<abbr title="конфигурация "Управление торговлей", редакция 11">УТ11</abbr>
1 Симпатия
feature-per-branch:
- загрузил стабильный код (pull - подтянул изменения)
- создал ветку
- работаешь с dev-хранилищем (можно персональным - на своей личной виртуалке), сохраняешь в папку
- “вроде работает” - опять подгружаешь (pull), сливаешь (merge),
- выгружаешь (push) код своей фичи в общую dev-ветку
в хранилище помещаешь код, который работает у тебя
поместил в хранилище на TEST (QA, PreLive, PreProduction, Staging) - запускаются тесты (по хуку)
если тесты не пройдены - твои изменения откатываются, создаётся ветка для решения проблемы неработоспособного кода (issue-branch или как он там называется)
если тесты пройдены - код копируется в master-branch и, соответственно,
из хранилища конфигураций тестового 1ass-сервера в хранилище сервера боевого (LIVE, PRODUCTION)
одинэсная специфика только в том, чтобы копировать код между хранилищами, на мой дилетантский взгляд (я могу быть не прав)
Фича которую ты пилишь может быть хоть совсем не рабочей, пока ты её пилишь.
О допиленности фичи говорит факт того, что она успешно влилась из фича-бранча в общий дев-бранч (главную стволовую ветвь разработки) и прошла тесты.
Из Dev в Test (QA) код дёргается автоматически - или по хуку (post-merge hook, post-push hook) после каждого обновления (слияния) или по таймеру (если тестов много, а серверов/инстансов мало) или очереди (освобождение/порождение/запуск).
Также автоматически он откатывается на работающую (предыдущую) версию - пока не пройдёт тесты.
В больших проектах релизами т.е. перетеканиями набора фич (feature-branch) и багфиксов (bugfix-branch) в master-ветку (слияниями с ней - merge) ведают PM’ы (руководители проектов), TeamLead’ы (начальники отделов) и архитекторы.
Там уже используются менее распространённые команды git для повышения наглядности/красивости истории разработок (дерева с ветками).
З.Ы. Я не учу никого, а повторяю общепринятые банальности.
Я так понимаю, основная проблема - бинарный проприетарный формат внутреннего хранения метаданных конфигурации, вернее низкая скорость его распаковки?
Решить её увеличением мощности вычислительных ресурсов мы можем?
Насколько это адекватный (дорогой) путь решения?
Пока спасает только SSD и RamDrive для работы с кэшем.
Сейчас идет рефакторинг v83unpack и еще одного продукта - но процесс НЕ быстрый.
Что касается банальностей - тут ты прав, мы всё это знаем.
НО для 1С приходится каждый участок процесса и каждую команду… так сказать адаптировать с учетом особенностей платформы и самих разработчиков.
А если код не работает, но надо. Вот срочный hotfix необходимо выпустить, а код реально не работает или точнее работает но не так как надо, т.е. вроде как синтаксический анализ проходит, но в тоже время знаешь, что необходимо исправлять и исправлять. Все говорят: этого желательно не допускать, но бывает и такое.
[quote=“Zel_PC_03, post:5, topic:143”]
копировать код между хранилищами
[/quote] да, при этом никакой автоматизации нет и не предвидится, но с нюансами. Допустим у тебя не 2 хранилища, а 3 хранилища: production, testing, dev , путь dev -> testing -> production можно и руками делать, знай себе захватывай корень рекурсивно и объединяй полностью, но вот только когда начинается hotfix из production в testing, а testing уже обновлен из dev и тут начинается чехарда, даже вручную это довольно таки сложно сделать.
Ну или допустим когда у тебя в testing тоже подкорректировали, что-то и теперь надо это или вернуть в dev или же еще не до конца откорректировали и из dev надо получить другие обновления.
И еще проблема в хранилище 1с это обновление своей фичи ветки (хранилища) из dev, так же есть сравнение/объединение где куча измененных объектов и не помнишь, что я менял у себя и что же именно поменяли в dev.
Ничего и никогда не меняется ни в testing ни в production.
Если что-то работает на PreLive/PreProduction/staging сервере, но не работает на боевом - значит тестовый сервер плохой или тесты плохие.
А вот про хранилище конфигураций, захват, слияние, откаты мне очень интересно было бы узнать подробно и с примерами.
Может, распаковку конфигурации можно как-то вынести на супермощный сервер?!
Последний пример: УПП 1.3 мастеру смены понадобилось печать табеля по своему подразделению, прав на различные регистры “РабочееВремяСотрудников”, “Графики” и т.д. у него нет. Разработчик после отбора в запросе доступных сотрудников делает простое “УстановитьПривелигированныйРежим(Истина)” и запрос прекрасно отрабатывает, только вот на testing на с серверном 1с, а разработчик в файловой базе, оказывается что не устанавливается привелигированный режим и тут же на тестовой базе в отладке проверяем, редактируем и получаем готовый результат, который так же будет работать и у разработчика в файловой базе.
В production меняем, если срочный hotfix необходим - не всегда получается все тесты сделать хорошими, у меня пока нет еще 100% покрытия кода тестами.
Это тепичный пример “bad practice”, т.е. криворукости и безгамотности разработчика. Я бы таких выводил к оврагу, разувал и расстреливал.
Потому что в “14 ошибках 1ass-разработчика, за которые его нужно увольнять” от spec8 - “работает на файловой, не работает на SQL-ной” стоит первым пунктом.
Даже если это недостаток самой платформы “by design” - програмизд должен такой случай (test case) обязательно предусмотреть. (обложить/покрыть тестами)
а зачем нужен
Правка --> Дополнительно (Alt+Shift+Enter) --> Командный интерфейс
в конфигураторе?
Далее будет полноценный Git Flow?
Тогда у нас будет настоящая Мэри Поппинс 
Файловый вариант разработки, имхо, имеет право на жизнь.
Все предусмотреть невозможно, как-бы для этого и делаем тестовый сервер, тесты (чаще ведь проверяешь самый правильный сценарий, а неправильные оставляешь на “когда будет свободно время”, если конечно не самолеты делаешь).
p.s.: я не хотел-бы, что-бы меня поставили к стенке за плохой код, написанный после бессонной ночи из-за температурящего ребенка. Имхо, надо проще к этому относиться, толерантней что-ли.
Нет, git-flow это частный случай использования ветвления.