Минимальная единица метаданного 1С - начало


#1

Основная публикация: http://www.silverbulleters.org/minimalnaya-edinitsa-metadannogo-1s-nachalo/
В мире программирования, чаще всего все не так, как в других языках, это дает как преимущества, так и недостатки, которые замечаешь по сравнению с другими языками. Одним из недостатков в 1С является организация коллективной разработки одной конфигурации, в ней остро встает вопрос по определению минимальной единицы метаданных, которую может поменять в один «коммит» разработчик. Что…


#2

Не очень понимаю суть проблемы. Бросаете кнопки на форму - код генерируется сам, меняете кнопки - код тоже меняется?
В этом?

CLI-приложение не написать что ли на 1ass?

Оно же веб, т.е. клиент-сервеное? Или нет?


#3

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

[quote=“Zel_PC_03, post:2, topic:143”]
CLI-приложение не написать что ли на 1ass?
[/quote] нет, честный cli не написать, не умеет читать аргументы 1с , точнее умеет, но в коде тебе этого не даст.


#4

И заодно - фича-реквест:
расшифровывайте пожалуйста ВСЕ аббревиатуры в статьях!

	<abbr title="конфигурация &quot;Управление торговлей&quot;, редакция 11">УТ11</abbr>

#5

feature-per-branch:

  1. загрузил стабильный код (pull - подтянул изменения)
  2. создал ветку
  3. работаешь с dev-хранилищем (можно персональным - на своей личной виртуалке), сохраняешь в папку
  4. “вроде работает” - опять подгружаешь (pull), сливаешь (merge),
  5. выгружаешь (push) код своей фичи в общую dev-ветку

в хранилище помещаешь код, который работает у тебя

поместил в хранилище на TEST (QA, PreLive, PreProduction, Staging) - запускаются тесты (по хуку)

если тесты не пройдены - твои изменения откатываются, создаётся ветка для решения проблемы неработоспособного кода (issue-branch или как он там называется)

если тесты пройдены - код копируется в master-branch и, соответственно,
из хранилища конфигураций тестового 1ass-сервера в хранилище сервера боевого (LIVE, PRODUCTION)

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


#6

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

О допиленности фичи говорит факт того, что она успешно влилась из фича-бранча в общий дев-бранч (главную стволовую ветвь разработки) и прошла тесты.

Из Dev в Test (QA) код дёргается автоматически - или по хуку (post-merge hook, post-push hook) после каждого обновления (слияния) или по таймеру (если тестов много, а серверов/инстансов мало) или очереди (освобождение/порождение/запуск).

Также автоматически он откатывается на работающую (предыдущую) версию - пока не пройдёт тесты.

В больших проектах релизами т.е. перетеканиями набора фич (feature-branch) и багфиксов (bugfix-branch) в master-ветку (слияниями с ней - merge) ведают PM’ы (руководители проектов), TeamLead’ы (начальники отделов) и архитекторы.

Там уже используются менее распространённые команды git для повышения наглядности/красивости истории разработок (дерева с ветками).

З.Ы. Я не учу никого, а повторяю общепринятые банальности.


#7

Я так понимаю, основная проблема - бинарный проприетарный формат внутреннего хранения метаданных конфигурации, вернее низкая скорость его распаковки?

Решить её увеличением мощности вычислительных ресурсов мы можем?

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


#8

Пока спасает только SSD и RamDrive для работы с кэшем.
Сейчас идет рефакторинг v83unpack и еще одного продукта - но процесс НЕ быстрый.

Что касается банальностей - тут ты прав, мы всё это знаем.
НО для 1С приходится каждый участок процесса и каждую команду… так сказать адаптировать с учетом особенностей платформы и самих разработчиков.


#9

А если код не работает, но надо. Вот срочный 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.


#10

Ничего и никогда не меняется ни в testing ни в production.

Если что-то работает на PreLive/PreProduction/staging сервере, но не работает на боевом - значит тестовый сервер плохой или тесты плохие.

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


#11

Может, распаковку конфигурации можно как-то вынести на супермощный сервер?!


#12

Последний пример: УПП 1.3 мастеру смены понадобилось печать табеля по своему подразделению, прав на различные регистры “РабочееВремяСотрудников”, “Графики” и т.д. у него нет. Разработчик после отбора в запросе доступных сотрудников делает простое “УстановитьПривелигированныйРежим(Истина)” и запрос прекрасно отрабатывает, только вот на testing на с серверном 1с, а разработчик в файловой базе, оказывается что не устанавливается привелигированный режим и тут же на тестовой базе в отладке проверяем, редактируем и получаем готовый результат, который так же будет работать и у разработчика в файловой базе.

В production меняем, если срочный hotfix необходим - не всегда получается все тесты сделать хорошими, у меня пока нет еще 100% покрытия кода тестами.


#13

Это тепичный пример “bad practice”, т.е. криворукости и безгамотности разработчика. Я бы таких выводил к оврагу, разувал и расстреливал.

Потому что в “14 ошибках 1ass-разработчика, за которые его нужно увольнять” от spec8 - “работает на файловой, не работает на SQL-ной” стоит первым пунктом.

Даже если это недостаток самой платформы “by design” - програмизд должен такой случай (test case) обязательно предусмотреть. (обложить/покрыть тестами)


#14

а зачем нужен

Правка --> Дополнительно (Alt+Shift+Enter) --> Командный интерфейс

в конфигураторе?


#15

Далее будет полноценный Git Flow?


#16

Тогда у нас будет настоящая Мэри Поппинс :wink:

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

p.s.: я не хотел-бы, что-бы меня поставили к стенке за плохой код, написанный после бессонной ночи из-за температурящего ребенка. Имхо, надо проще к этому относиться, толерантней что-ли.


#17

Нет, git-flow это частный случай использования ветвления.