Данная статья скорее является заметкой и отчетом об успешном использовании нового механизма реструктуризации баз данных 1С. Актуально для больших баз данных.
Иногда случаются ситуации, когда в некую таблицу 1С (будь то справочник, регистр сведений или накопления) - необходимо добавить новое поле (реквизит, измерение, ресурс). В обычной ситуации, когда строк в таблице самой БД немного - платформа спокойно справляется с этой задачей. Но что делать, если строк накопилось за время ведения учета 1 млн? А если 10 млн? 100 млн? Более 300 млн? Если Вы не хотите ждать N-ое количество суток в ожидании, когда же закончится реструктуризация, или изобретать другие способы - статья для Вас. Основная идея заключается в том, что соответствие имен метаданных объектов конфигурации 1С (а также их ссылочных взаимосвязей между собой) и имен физических таблиц и колонок в самой БД - эта информация хранится в служебных таблицах этой же БД.
В некоторых информационных системах используются внешние источники данных. И, порой, возникает необходимость записи в таблицу внешнего источника неких значений.
Допустим, имеется большая таблица значений, получаемая расчетным способом в 1С. Необходимо записать строки таблицы значений во внешний источник.
Классический способ решения - использование ADO, обход строк таблицы в цикле и построчный INSERT с помощью конструкции INSERT INTO "+NameTable+" (ColumnName) values("+SetValue+")"
То есть, на каждую строку мы производим физическую запись в СУБД, заставляем работать носитель данных (жесткий диск например). Предлагаю способ, как ускорить этот процесс и записать всю ТЗ разом, пакетно.
В процессе автоматизации документооборота организации возникла задача хранить сканы бумажных документов (первичных) в базе 1С Документооборот КОРП. Статья рассказывает о варианте решения.
С выходом продуктов компании 1С на управляемых формах в типовых конфигурациях появилась очень удобная возможность встраивать в информационную базу внешние обработки и настраивать для них расписание выполнения. Однако, для обычного приложения - таких возможностей нет. Возникла необходимость в типовой БП 2.0 по расписанию запускать некую внешнюю обработку. На поддержке находится несколько баз и выполнять доработку конфигураций очень не хотелось ввиду увеличения впоследствии времени на обновление. В статье приведен пример, как обойти описанное ограничение.
Как мы все знаем, управленческий учет имеет задачи, зачастую отличные от бухгалтерского. В частности, движения денежных средств порой необходимо рассматривать в других разрезах. Конкретно - возникла задача иметь возможность анализа движений денежных средств по КБК. Как реализовать связь КБК с аналитикой бухгалтерского учета и организовать движения по ним без доработки конфигурации? Ответ в приведенной ниже статье. Статья написана применительно к БП 3.0, однако описанные механизмы можно применить фактически к любой конфигурации.
По поводу стандартных команд объекта - как раз довод в пользу создать объект в основной конфигурации, через её сравнение-объединение с "лысой". А вот формы этого объекта, макеты и реквизиты - да, можно уже в основном расширении (если применять эту технологию). Это касается хранимых сущностей. Всякие обработки и тд - можно спокойно добавлять в расширение сразу
Да, я понял, о чем речь. Ну об этом и говорю. Бранч-разраб второго PR и код-ревьюер, который этот PR принимает в мастер - должны это все увидеть. Поэтому, я например, всегда перед финальной просьбой о принятии моего PR еще визуально просматривал ВСЕ файлы (в том числе и xml) на предмет того, точно ли там только мои изменения...
Когда с хранилищем работаешь - таких лишних затрат мозготоплива и времени там нет.
(12)
Ну даже если и проблема при мерже. Какой-то один PR все равно будет первым. И тогда второму разрабу придётся самому разрулить конфликт перед финальной просьбой принять его PR. Это и есть часть того самого оверхэда, о котором я столько букв уже написал. И тут ещё нужна внимательность как со стороны код-ревьюера, так и со стороны бранч-разраба, так как не всегда такие проблемы в интерфейсе MR или PR отображаются как конфликты
(9)
Типовые формы так или иначе пилить надо только кодом. Хоть гит, хоть хранилище. На нетиповых рулить административно, не давать 2 разных задачи по одной и той же форме 2-м разным разрабам в одно и тоже время
вы потратите временя на "а тебе ещё нужен ИмяМодуля, я в него хочу процедуру добавить? ой, а я там две процедуры поменял, щас закину в хранилище / сохраню цф себе, откачу модуль потом заново захвачу" или "не могу отдать объект, на него много завязано, а класть в хранилище рано, так как не доделано, а если положу, сломаю другой код".
То, что Вы описываете - все-таки происходит крайне редко при работе через хранилище. Как правило, если кто-то захватил объект, то он его и держит, пока не закончит задачу. Ну а остальные моменты, в том числе конфликты за объекты решаются административно. В конце концов, никто не запрещает расширить нужный объект и вести разработку в расширении и потом перенести, когда он освободится... Из практики - обычно выпускают стандарты, в которых оговаривают порядок захвата и максимальное время удержания (например принцип "долго не держим корень - захватил его- положил свои объекты - отпустил").
(6)
Цитата
При разработке через хранилище не нужно идти обновлять эталонную базу? Или всё тестируется в одной общей базе?
Я имел ввиду, что тут получается следующая ситуация. У каждого разработчика есть своя база для разработки, поднятая на инфраструктуре подрядчика. Но это не отменяет необходимость заказчику тоже иметь свою инфраструктуру, где держать как минимум несколько более-менее полновесных БД, с наличием данных. В том числе и эталонных, приемосдаточных и т.д. Т.е., заказчик платит и подрядчику за более сложную инфраструктуру, так еще и свою тоже должен иметь и поддерживать. А не дешевле ли уж тогда нарастить свои мощности и вести разработку полностью на них?
Ну и применительно к этому примеру, обновление единственной эталонной - узкое место для всех остальных, так как всех надо оповестить в некоторых случаях, что "данные изменились" - пора переподнимать окружение. Но на самом деле, по сравнению с прочими рисками и общим удорожанием - это мелочи.
Кстати, еще из оверхэда.
Хранение исходников в гите и сборка из них конфигураций - тоже риск. Потому что платформа так и не научилась стабильно одинаково выгружать-загружать в/из файлов. Неоднократно сталкивался с ситуациями (на разных релизах), когда выгрузил в файлы, загрузил из них же и, например - потерял некоторые обработчики элементов формы.
Или так называемые "фантомные" изменения в файлах при выгрузке (обычно это на файлах ролей проявлялось). Это прям был бич того проекта. Вроде все делаешь правильно, по технологии - скачал свежий cfe из релизов, накатил на свою ИБ, выполнил разработку, перед пушем в ветку еще раз накатил cfe из мастера, на всякий случай сравнил-объединил по финалу - видишь в интерактиве только свои изменения. Пушишь в ветку, оформляешь PR и видишь в списке изменений относительно мастера не только свои, но еще и изменения на файлах ролей (какие-то теги внутри xml добавлены или удалены).
На самом деле лично мне самому очень нравится и концепция git и те возможности, которые дает gitflow.
Но применительно к 1С, а конкретно к крупным проектам - это все оказывается на деле существенно дороже классической разработки при том, что преимущества от gitflow не перекрывают это удорожание. Например на том проекте (а он был прям реально крупный) - крайне редко я встречал ситуации, когда 2 разработчика одновременно пилили один и тот же объект/модуль. Все основные конфликты всегда - на корне, то есть на файле описания метаданных. Из-за всего описанного оверхэда среднестатистический разработчик в такой среде тратит на 30-35% больше времени, чем если бы он делал все тоже самое, но через хранилище. Прибавьте сюда облака, штат спецов и трудозатраты на погружение-обучение новых разработчиков.
P.S. Кстати, статья немного устарела и на текущий момент github закрыл доступ к своим корп-фичам и корп-разработке для организаций из РФ. Поэтому нам в какой-то момент пришлось переезжать на собственный gitlab, который опять-таки - в облаке Яндекс.
Ну и по опыту, команда до 12-15 разработчиков может более-менее спокойно уживаться в одном хранилище без сильных конфликтов за объекты (а если таковые и возникают - то решаются административным регламентом).
Итого (имхо, повторюсь): gitflow в 1С - круто, стильно, модно, молодежно, но прям сильно дорого.
P.P.S Все сказанное не отменяет того факта, что команда BIT.ERP - одна из самых сильных на рынке. Качественно выше, чем большинство их проектных офисов. В том числе и сама инфраструктура и методология, мне например очень нравилось, что у них везде сквозная kerberos-авторизация, во всех сервисах. И удобный проектный мессенджер, импортозамещенный аналог Slack -
Также очень сильные аналитики и консультанты, костяк разработчиков тоже. Работать в такой команде - одно удовольствие, вспоминаю с теплом.
(0) работал у вас на одном из проектов в качестве субподрядчика по описанной схеме.
Для разработчика все круто и удобно, схема работы по факту gitflow, но применительно к 1С очень много оверхэда.
С чем столкнулся лично:
- высокий порог вхождения в проект на этой схеме, особенно для тех сотрудников, кто никогда не работал с git, EDT и проч. У меня была коллега-девушка по той же схеме субподряда, поначалу приходилось много натаскивать ее и помогать;
- множество раз приходилось таскать cfe туда-сюда и дообновлять свою конфу со своей фича-бранчей, перед тем как пушить изменения в ветку, чтобы оформить корректный пулл-реквест. Потому что пока пилишь свою фичу - мастер успевает тебя обогнать. Как-то раз в течении дня три раз подряд пришлось этим заниматься, потому что пока я тащил свежий cfe из мастера в свою конфу - там принимали новый PR, проходила сборка и мастер снова меня обгонял. Проблему лично я для себя частично решил так: развернул локальный репо, через интерфейс гит-хаба нажимал кнопку обновления ветки (она доступна тогда, когда нет конфликтов между изменениями в ветке и мастером), затем спулливал в локальный репо эту ветку, из нее собирал cfe и накатывал на свою конфу (таким образом сохраняя и свои изменения и свежие из мастера). Но все это работает, только если можно без конфликтов в свою ветку подтащить изменения из мастера, той самой кнопкой в интерфейсе гит-хаба (ну или командой pull master ---> branch, которую она по факту и вызывает)
- вся команда работают через конфигуратор, но файлы в репо зачем-то хранятся в формате EDT. Зачем? Чтобы еще побольше оверхэда было? Чтобы собирать cfe из такой ветки - пришлось ставить EDT нужной версии и в него втыкать плагин ;
- отдельный геморрой - это когда все-таки нельзя сделать доработку через все эти "хитрости" (по мне - так это не "хитрости", а "костыли" - называйте уж вещи своими именами) с расширениями, например проиндексировать типовой реквизит или измерение в любой таблице (справочник, РН, РС и т.д.). Всю боль описывать не буду, но у меня как-то раз ушло на это 1.5 (sic!!!) рабочих дня, хотя обычно это делается за 10 минут;
- вы хвастаетесь своими "удобными" ВМ, которые поднимаете для каждого разработчика, но по факту внутри ВМ стоит linux, на котором в конфигураторе работать ооочень неудобно (тормоза, глюки и некоторые баги, кто работал так - знает). Поэтому по факту абсолютно вся команда работает на своих локальных тачках, а на ВМ таскает только cfe-шки, чтобы была возможность через заявку запушить конфу в свою ветку по итогу разработки фичи;
- учитывая необходимость разрабатывать на изолированном окружении - по факту ИБ для разработки очень маленькая и в ней банально невозможно качественно провести разработку под какую-то хайлоад-задачу. Да и не только под хайлоад, а и под прикладные задачи, требующие наличия настроек и специальных данных. В процессе разработки такой задачи все равно приходится тащить свои изменения на одну из "нормальных" и "больших" тестовых баз, расположенных на сервере конечного заказчика и там проводит тестирование и приемо-сдаточные работы. Таких баз не так много, за них вечная конкуренция и кроме того, при их обновлении - приходится постоянно сравнивать-объединять, чтобы не затереть чужие доработки;
- эти вечные сравнения-объединения после каждого "догоняния" мастера и такие же сравнения-объединения при помещении своих изменений в "нормальную" БД - несут дополнительный риск в виде человеческого фактора (когда кто-то что-то не до конца поместил и т.д.);
- по некоторым задачам, после их выполнения, например после добавления предопределенных элементов или каких-то данных, которые должны быть у всех (нетиповые добавленные настройки, например) - необходимо также еще сходить и обновить эталонную базу, чтобы все новые подъемы свежих "окружений" уже получили БД с наличием этих данных. На обновление эталонной ИБ есть целый регламент и в один и тот же момент времени это может сделать только один человек, который должен зайти под специальным пользователем на хост, где она хранится, внести все изменения и потом через заявку запушить ее в S3.
- тот факт, что абсолютно все метаданные (новые реквизиты, измерения, таблицы и т.д.) - добавляются через расширения - оооочень спорный. Неоднократно сталкивался на разных проектах с тем, что расширения могут "отваливаться" от прода прямо в процессе боевой работы, что чревато крашами БД, потерей данных и простоями. Многие категорически отказываются использовать расширения так, как это делаете вы у себя и применяют их только для программного изменения форм и поведения алгоритмов, а все данные (реквизиты и т.д.) - хранят только в основной конфе. К слову сказать, на том проекте, где я принимал участие - таких ситуаций у вас не было, в целом все работало. Так что надежность расширений повысилась, но тем не менее.
P.S. Как-то раз я сел и примерно подсчитал, насколько для конечного заказчика разработка по такой схеме будет дороже, чем через классические хранилища и подъем собственной инфраструктуры на своих мощностях. Получилось примерно 35-40% при прочих равных. А ведь еще надо учесть, что вся ваша инфраструктура расположена на арендованных облаках + у вас целый штат девопсеров, которые все это поддерживают и поднимают, когда оно падает (а оно таки иногда падает, что ВМ разрабов, что сборочные линии). Так что по факту там все 50%, а не 35%.
P.P.S Лично у меня сложилось впечатление, что вы шли примерно таким путем: "А давайте разрабатывать так, как это делают в больших командах, gitflow и все дела? А давайте! Давайте хранить исходники в гит-сервере и давайте хранить их в формате EDT, мы ведь через него будем с фича-бранчами работать, он же умеет это из коробки? А давайте!". А потом начались "нюансы" - оказалось что и основную конфу таких проектов как ERP хранить в гите очень дорого и что разрабатывать на самом EDT для большинства "обычных" 1С-ников (которые и являются ядром любой проектной команды) - тоже непросто, их учить надо и погружать во все нюансы такой разработки.
Итого, что имеем на выходе. Разработка через gitflow, плюсы: код-ревью, статический анализ кода перед принятием PR. Тут да, не поспорить, качество кода в таком проекте будет выше, чем при использовании классических хранилищ. Запуск тестов "на ветке" перед приемкой PR - тоже несомненный плюс (но уже не такой весомый, так как и в классических хранилищах тесты можно запускать хоть по расписанию, хоть по событию появления новой версии в хранилище). Ну и на этом, пожалуй, все (если смотреть с точки зрения конечного заказчика). Минусы, геморрой и оверхэд - все описал выше. Да, для разработчика все это круто, погрузиться в "современный мир" и т.д. и т.п. Но... сама платформа устроена так, что работать с большими конфигурациями через гит - удовольствие то еще... Для небольших - да, плюсы начинают перевешивать, причем существенно.
Все написанное - исключительно ИМХО. Решил, что раз уж вышла такая статья, то надо дать фидбэк как того человека, который в этой среде как следует поварился. В целом, лично мне, после привыкания (у меня это было примерно 2 недели, но только потому, что я ранее уже со всем инструментарием был знаком) - было комфортно так разрабатывать, а благодаря стат. анализу и код-ревью - я лично стал писать почище и ближе к стандартам, чем до вхождения на проект. То есть, в плюсы еще можно записать тот факт, что компетенции команды растут в процессе такой разработки.
"Например, мы определили, что долг контрагента актуален 3 минуты. В течение трех минут, если будут одинаковые запросы (по составу значений параметров), шина не будет обращаться к системам, а будет возвращать то, что она сохранила."
Можете подробнее раскрыть этот пункт? Этот именно ваша шина (2is) умеет это из коробки и логика таймаута кэша запроса хранится где-то в ней? Или это все автоматом работает и если приходит полностью идентичный запрос, то она сама выдает ответ, который где-то хранится эти 3 минуты?
Тоже провел тесты. Однострочный код при запуске в файловой базе, без отладки - все-таки немного, но быстрее.
Что при запуске в консоли кода, что при непосредственно в обработках
(15) а какой объем логов ТЖ за 1 час при тех настройках, что сделаны? в моменты пиковых нагрузок, в середине дня например
"Если получилась такая ситуация, что 1С хочет удалить папку с завершившимся процессом, а Promtail читает из неё логи, то она не сможет этого сделать, пока не будет перезапущен Promtail. Поэтому необходимо добавить задание в планировщик, которое будет раз в сутки перезапускать службу Promtail'а, чтобы очищать эти папки."
и вот это не особо понятно:
- во-первых, он что - "держит" все папки, из которых что-то читал (даже если вотпрямщас не читает оттуда)?
- во-вторых - как перезапуск его службы помогает - папки сами удаляются что ли?
